Ubuntu HowTo: How can I tunnel whole system through HTTP proxy?

Original Source Link

I currently use Ubuntu 20.04. I need to use proxy to connect to internet. I have configure every program is use proxy because most software don’t respect the http_proxy environment variable. I have tried to set proxy in Settings but most software don’t care it. Is there any way to whole system through proxy? Is there any way to make a interface which will tunnel all request to HTTP proxy?

Please try to elaborate a bit please.
As I reads this you could setup a HAProxy acting opposite than usual in TCP mode, connecting to the actual proxy in your network. HAProxy honours and respects the proxy_protocol so it could do this seamlessly. Other possibility is to set up a local Squid Proxy catching everything and forwarding it to the other proxy.

Both of these solutions can work as invisible and you would not need to configure anything in any apps. However a setup like that is not default.

Tagged : / /

Ubuntu HowTo: netplan gre tunnel+quagga

Original Source Link

After installing new router with ubuntu 18.04 on it i’m got a problem with working ospf via gre tunnel to my older routers.
All configured simular, but from new router i got ospf state Init/DROther. Older routers (without netplan) dont see any neighbor.
Tunnels work fine with static routing.

I found solution and fix problem manually. I found that netplan make tunnel with ‘ttl inherit’ (on other routers ttl 255).

tunnel1: gre/ip remote 1.1.1.1 local 2.2.2.2 ttl inherit

After ip tunnel change tunnel1 ttl 255 command execution ospf starts to work.

How can I add to netplan ttl and pointopoint parameters to tunnel intarface?
How to set commands like below to netplan file?

ifconfig tunnel1 pointopoint 10.2.2.1
ip tunnel change tunnel1 ttl 255

netplan currently lacks the ability to configure the ttl / hoplimit of a tunnel. This issue has been brought up in its issue tracker (bug #1846783), however its developers seem to have not paid attention to this.

Meanwhile you can configure the tunnel using connection managers that support setting this field such as systemd-networkd and NetworkManager, or try to run a script that calls ip tunnel after the tunnel has been brought up by netplan.

You might also be interested in the workaround described in the original feature request for supporting IP tunnels in bug #1799487, or elsewhere on this site

Tagged : /

Server Bug Fix: SSH tunnel without sshd in the middle

Original Source Link

I have 3 machines A, B and C. I can ssh from B to A and also from B to C. B will not accept any incoming connections. There is no direct connection between A and C possible.
Is there a way to ssh from A to C and from C to A reusing the ssh connections I created from B?

+---+  SSH +---+  SSH  +---+
| A | <--- | B | ----> | C |
+---+      +---+       +---+

If the existing ssh connections from B are like this:

ssh -R 2201:localhost:2202 A
ssh -L 2202:localhost:22 C

You can connect from A to C with:

ssh localhost -p 2201

It is possible to do the same with the RemoteForward and LocalForward config directives.

Tagged : /

Making Game: Openvpn L2/tap losing packets

Original Source Link

[EDIT] This seems to be an OpenVPN bug – bridging with the server-side of the openvpn tap tunnel results in lost ARP packets, but bridging with the client side (of any client connected to the vpn) works perfectly. I’ve worked around the bug by bridging with a client instead of the server. The bug reporting process is quite a bit of work so it will be some time before I can write it all up to submit to the Openvpn project.

I’m observing Openvpn consistently dropping certain packets…

Scenario:

I set up a wide area Layer-2 network (using OpenVPN) to support Minecraft pocket-edition (MCPE) players (just family) to see each other in the network friends list and play together. There are three remote endpoints, all in different locations, and a central openvpn server. Each remote endpoint broadcasts Wi-Fi bridged to the Openvpn tap interface. This works great and players can see each other.

Recently I wanted to add an additional Wi-Fi endpoint locally, here at the server location. So I Added an ethernet port to the bridge and attached a Wi-Fi bridge to get Layer-2 connectivity to the existing openvpn bridge. At a glance this appears to work well; clients can get to the internet and L2 traffic looks normal.

However when players on a remote client endpoint try to play against those connected to the local wi-fi bridge, players can’t see each other.

The local Wi-Fi bridges to the SERVER end of the openvpn tunnel, and this seems to be a factor, but this is unexpected.

After many hours of troubleshooting I’ve narrowed the problem down to one peciluar fact – Wi-Fi bridged to the server’s openvpn tap interface (named tapmc) are not able to play against players on the other side of the VPN.

In other words if any two players are on the same Wi-Fi or on a client openvpn Wi-Fi endpoint, they can see eachother no matter how far away. BUT players connected to the Wi-Fi that’s bridged to the SERVER-side openvpn tap interface run into problems – they cannot see players on the client side of the tunnel, and remote players can’t see them.

To see each other, the game sends out a UDP broadcast packet every 1-2 seconds to port 19132 (ipv4). All players on the network receive these broadcasts, and if their game is the server then their game responds with a unicast packet to the requestor. This unicast response packet contains game information, so the player who is searching for active games on the network will see them show up in their friends list so they can join the game.

Attached is an analysis of a small period of time where packets are being lost. Packets go in one side of the tap tunnel, and don’t come out the other side. I’ve captured the packets by running tcpdump against each side of the tunnel, on the openvpn tap interface itself, so there are no bridges in the path, although the interfaces are each members of a bridge.

Annotated tcpdump "side by side" (both sides of the openvpn tap tunnel)

What I see is that PLAYER2, while searching for games on the network sends the search broadcast, which is received by PLAYER1’s game, which wants to respond with a unicast game-info packet but first needs to resolve the MAC address of PLAYER2, so it sends an ARP who-has. the who-has packet, and all subsequent retransmits of it, are received and responded to by PLAYER1 but those responses are NOT transmitted across the Openvpn tunnel to PLAYER1. Thus the L2 ARP resolution never succeeds, and the unicast game-info packet is never sent, and PLAYER2 never sees PLAYER1.

Also lost across the tunnel is the second copy of the game search broadcast packet, however this is not as detrimental to the process because the first of the two copies is transmitted successfully. But why only one?

Openvpn Server configuration

server 192.168.251.0 255.255.255.0
verb 3
key ***
ca ***
cert ***
dh ***
tls-auth ***
key-direction 0
keepalive 10 60
persist-key
persist-tun
client-to-client
proto udp
port ***
dev tapmc
status ***
ifconfig-pool-persist ***
user nobody
group nobody

Openvpn Client configuration

client
nobind
dev tapmc
remote-cert-tls server
remote ***    
<key>
***
</key>    
<cert>
***
</cert>    
<ca>
***
</ca>
<tls-auth>
***
</tls-auth>
key-direction 1
#redirect-gateway def1

Openvpn versions: server: 2.4.8-1, clients: 2.4.7-1

This turned out to be a bug in OpenVPN

Tagged : / /

Linux HowTo: SSH reverse tunnel intermediate host

Original Source Link

I have a scenario of 3 machines (A, B, C) all on different locations. All of them are behind NAT, where only B can be accessed from the outside world through forwarded port 12345 on the router on site B.

A = Laptop (WIN 10)

B = Raspi (Raspbian 9 Strech)

C = Raspi (Raspbian 10 Buster)

What I have managed so far:

I can ssh A => B (putty, through forwarded port 12345) – no big deal

I can ssh C => B (ssh -N -R 2222:localhost:22 [email protected] -p 12345) – reverse ssh tunnel, setup with crontab to run automatically.

I can ssh B => C (ssh -p 2222 localhost)

I can ssh A => B => C (putty to B, then from there “ssh -p 2222 localhost” and I get to C)

What I really want is:

ssh A => C (putty)

I want to access other devices in network C (from A), like file systems of the devices in network C etc.

Any help would be greatly appreciated.

If I were you I would consider using a VPN such as OpenVPN to connected your three devices. You write that device B, while behind a NAT, has port forwarding to the outside world. I would use the same port forwarding but instead forward port 12345 to 1194 for VPN; or simply forward port 1194 on your router to device B. Then B would run a openvpn server, and both A and C would be VPN clients. You could set the VPN client up on C to auto start the VPN connections when it connects to it’s local network.

Then when you are using your laptop (A), you can start the VPN client and then C will simply be another host on your VPN network.

This is not exactly an A => C connection, but it would be a robust way to interconnect these networks.

Tagged : / /

Making Game: SSH reverse tunnel intermediate host

Original Source Link

I have a scenario of 3 machines (A, B, C) all on different locations. All of them are behind NAT, where only B can be accessed from the outside world through forwarded port 12345 on the router on site B.

A = Laptop (WIN 10)

B = Raspi (Raspbian 9 Strech)

C = Raspi (Raspbian 10 Buster)

What I have managed so far:

I can ssh A => B (putty, through forwarded port 12345) – no big deal

I can ssh C => B (ssh -N -R 2222:localhost:22 [email protected] -p 12345) – reverse ssh tunnel, setup with crontab to run automatically.

I can ssh B => C (ssh -p 2222 localhost)

I can ssh A => B => C (putty to B, then from there “ssh -p 2222 localhost” and I get to C)

What I really want is:

ssh A => C (putty)

I want to access other devices in network C (from A), like file systems of the devices in network C etc.

Any help would be greatly appreciated.

If I were you I would consider using a VPN such as OpenVPN to connected your three devices. You write that device B, while behind a NAT, has port forwarding to the outside world. I would use the same port forwarding but instead forward port 12345 to 1194 for VPN; or simply forward port 1194 on your router to device B. Then B would run a openvpn server, and both A and C would be VPN clients. You could set the VPN client up on C to auto start the VPN connections when it connects to it’s local network.

Then when you are using your laptop (A), you can start the VPN client and then C will simply be another host on your VPN network.

This is not exactly an A => C connection, but it would be a robust way to interconnect these networks.

Tagged : / /

Server Bug Fix: Packages from tunnel don’t make it to application level

Original Source Link

I have a tunnel to a partener created using racoon. In the last couple of weeks I had serious data losses through this tunnel (but not from any other sources). The start of these data losses coincide with the time when the partner has changed some equipment at their end but they claim that the equipment change did not affect the functionality of the tunnel and the tunnel is always up and that they made pings and my server does not respond to it. Here comes the weirdest part: if I do a tcpdump -n dst 172.16.0.1 (this ip being my server’s local ip) I can see that the UDP packages I expect indeed do arrive they just never make it to the daemon listening for them. Restarting the daemon does not help however restarting racoon does. And if I do nothing, the problem disappears by itself in 15 – 20 minutes. And the problem appears 5 – 12 times every day.

The section of racoon.conf regarding this tunnel looks like:

remote X.X.X.X {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
                lifetime time 86400 sec;
        }
        generate_policy on;
}

sainfo address 172.16.0.0/30 any address 192.168.0.0/16 any {
        pfs_group 2;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
        lifetime time 86400 sec;
}

We’ve been using this tunnel successfully since 2016 and I haven’t touched the daemon for at least 6 months, nor did I do ubuntu updates before the problem appeared, unattended-upgrades is not installed, so I can’t imagine what’s going on, anyone has any ideea?

My server is an Ubuntu-server 16.04.6 LTS. I have tried updating the kernel and everything, which did not help but I can’t do a release-upgrade.

Tagged : /

Making Game: How to setup a SSH Tun Device?

Original Source Link

I am trying to link two Ubuntu 20.04 servers together so that they both share an IP

Server One is a cloud server with its own dedicated IP with DDoS protection and a hardware firewall. Server Two is a much higher performance server, but it is at my home with no dedicated IP and cannot open ports to the internet.

I would like Server One to be able to listen on Server Two’s IP to be able to open things like a web server. It looks like setting up an ssh tun interface is the best method and using the -w option, but I cannot find any information on how to setup something like this.

Right now I am able to accomplish this with SSH forwarding (command below) as a systemd daemon, but I would like to be able to scale this better with the ability to use more ports without having to add a new systemd file.

ssh -N -R 3000:localhost:3000 [email protected]

Tagged : / / / /

Linux HowTo: UDP traffic through SSH tunnel

Original Source Link

The title pretty much sums it up. I would like to send UDP traffic through a SSH tunnel. Specifically, I need to be able to send UDP packets through the tunnel and have the server be able to send them back to me on the other side. I know how to do it for TCP connections. Is this it possible with UDP?

This small guide tells you how to send UDP traffic via SSH using tools that come standard (ssh,nc,mkfifo) with most UNIX-like operating systems.

Performing UDP tunneling through an SSH connection

Step by step
Open a TCP forward port with your SSH connection

On your local machine (local), connect to the distant machine (server) by SSH, with the additional -L option so that SSH with TCP port-forward:

local# ssh -L 6667:localhost:6667 server.foo.com

This will allow TCP connections on the port number 6667 of your local machine to be forwarded to the port number 6667 on server.foo.com through the secure channel.
Setup the TCP to UDP forward on the server

On the server, we open a listener on the TCP port 6667 which will forward data to UDP port 53 of a specified IP. If you want to do DNS forwarding like me, you can take the first nameserver’s IP you will find in /etc/resolv.conf. But first, we need to create a fifo. The fifo is necessary to have two-way communications between the two channels. A simple shell pipe would only communicate left process’ standard output to right process’ standard input.

server# mkfifo /tmp/fifo
server# nc -l -p 6667 < /tmp/fifo | nc -u 192.168.1.1 53 > /tmp/fifo

This will allow TCP traffic on server’s port 6667 to be forwarded to UDP traffic on 192.168.1.1’s port 53, and responses to come back.
Setup the UDP to TCP forward on your machine

Now, we need to do the opposite of what was done upper on the local machine. You need priviledged access to bind the UDP port 53.

local# mkfifo /tmp/fifo
local# sudo nc -l -u -p 53 < /tmp/fifo | nc localhost 6667 > /tmp/fifo

This will allow UDP traffic on local machine’s port 53 to be forwarded to TCP traffic on local machine’s port 6667.
Enjoy your local DNS server 🙂

As you’ve probably guessed it now, when a DNS query will be performed on the local machine, e.g. on local UDP port 53, it will be forwarded to local TCP port 6667, then to server’s TCP port 6667, then to server’s DNS server, UDP port 53 of 192.168.1.1. To enjoy DNS services on your local machine, put the following line as first nameserver in your /etc/resolv.conf:

nameserver 127.0.0.1

This example (I think John’s answer points the the same thing at a different place), describes how to access another machine’s UDP/DNS services over an TCP/SSH connection.

We will forward local UDP/53 traffic to TCP, then TCP traffic with the port-forwarding mechanism of SSH to the other machine, then TCP to UDP/53 on the other end.
Typically, you can do it with openvpn.
But here, we’ll do it with simpler tools, only openssh and netcat.

At the end of that page, is another comment with a reference to ‘socat‘,
The same UDP/DNS access is made with,

Server side: socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53
Client side: socat udp4-listen:53,reuseaddr,fork tcp:localhost:5353

Refer socat examples for more.

SSH (at least OpenSSH) has support for simple VPNs. Using the -w or Tunnel option in the ssh client, you can create a tun device at both ends, which can be used to forward any kind of IP traffic. (See also Tunnel in the manual page of ssh_config(5).) Note that this requires OpenSSH (and probably root privileges) at both ends.

Or you could simply use ssf (which was designed to handle this use case), with a simple command:


Client side:

#>./ssfc -U 53:192.168.1.1:53 server.foo.com

This command redirects local port 53 (dns) to 192.168.1.1 port 53, through a secure tunnel between localhost and server.foo.com.


You will need a ssf server (instead of – or next to – your ssh server):

#>./ssfs

By the way, both client and server side of ssf work on Windows / Linux / Mac.
This is a userland application, so you don’t need tun/tap or VPN.

To redirect port 53, you will need administrative privileges – regardless of the tool you’re using.

For more info, details, use case, or download: https://securesocketfunneling.github.io/ssf/

I couldn’t get nc to work for SNMP, because SNMP clients keep choosing a new source UDP port, and several can be active at once.

Instead, I’ve written a post describing how to do it with socat in this blog post, using SNMP as an example. Essentially, using two terminals, starting with an overview:

overview

Terminal one:

client$ ssh -L 10000:localhost:10000 server
server$ socat -T10 TCP4-LISTEN:10000,fork UDP4:switch:161

This creates the SSH forwarding of TCP port 10000 and runs socat on the server. Notice how the switch’s IP address is mentioned in the socat command line as “switch”.

Terminal two:

client$ sudo socat UDP4-LISTEN:161,fork TCP4:localhost:10000

That sets up socat on the client. That should do it.

A VPN is a better solution if you have access to an UDP port.

If you only have access to the TCP SSH port, then an SSH tunnel is as good as a VPN, at least for ping and packet backtracking.

on ssh server:

sudo ip tuntap add dev tun7 mode tun user SSHUSER
sudo ip addr add 192.168.7.1/30 dev tun7
sudo iptables -t nat -A PREROUTING -p udp -i eth0 --dport PUBLIC_PORT -j DNAT --to-destination 192.168.7.2:LOCAL_PORT
sudo iptables -t filter -A FORWARD -i eth0 -p udp -d 192.168.7.2 --dport LOCAL_PORT -j ACCEPT
sudo iptables -t filter -A FORWARD -i tun7 -o eth0 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o tun7 -j MASQUERADE
# set "PermitTunnel point-to-point" for user SSHUSER in /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart sshd

on ssh client running udp server:

sudo ip tuntap add dev tun8 mode tun user LOCALUSER
sudo ip addr add 192.168.7.2/30 dev tun8
ssh -v -w 8:7 [email protected]

inspired by comment UDP traffic through SSH tunnel

Tagged : / /

Making Game: UDP traffic through SSH tunnel

Original Source Link

The title pretty much sums it up. I would like to send UDP traffic through a SSH tunnel. Specifically, I need to be able to send UDP packets through the tunnel and have the server be able to send them back to me on the other side. I know how to do it for TCP connections. Is this it possible with UDP?

This small guide tells you how to send UDP traffic via SSH using tools that come standard (ssh,nc,mkfifo) with most UNIX-like operating systems.

Performing UDP tunneling through an SSH connection

Step by step
Open a TCP forward port with your SSH connection

On your local machine (local), connect to the distant machine (server) by SSH, with the additional -L option so that SSH with TCP port-forward:

local# ssh -L 6667:localhost:6667 server.foo.com

This will allow TCP connections on the port number 6667 of your local machine to be forwarded to the port number 6667 on server.foo.com through the secure channel.
Setup the TCP to UDP forward on the server

On the server, we open a listener on the TCP port 6667 which will forward data to UDP port 53 of a specified IP. If you want to do DNS forwarding like me, you can take the first nameserver’s IP you will find in /etc/resolv.conf. But first, we need to create a fifo. The fifo is necessary to have two-way communications between the two channels. A simple shell pipe would only communicate left process’ standard output to right process’ standard input.

server# mkfifo /tmp/fifo
server# nc -l -p 6667 < /tmp/fifo | nc -u 192.168.1.1 53 > /tmp/fifo

This will allow TCP traffic on server’s port 6667 to be forwarded to UDP traffic on 192.168.1.1’s port 53, and responses to come back.
Setup the UDP to TCP forward on your machine

Now, we need to do the opposite of what was done upper on the local machine. You need priviledged access to bind the UDP port 53.

local# mkfifo /tmp/fifo
local# sudo nc -l -u -p 53 < /tmp/fifo | nc localhost 6667 > /tmp/fifo

This will allow UDP traffic on local machine’s port 53 to be forwarded to TCP traffic on local machine’s port 6667.
Enjoy your local DNS server 🙂

As you’ve probably guessed it now, when a DNS query will be performed on the local machine, e.g. on local UDP port 53, it will be forwarded to local TCP port 6667, then to server’s TCP port 6667, then to server’s DNS server, UDP port 53 of 192.168.1.1. To enjoy DNS services on your local machine, put the following line as first nameserver in your /etc/resolv.conf:

nameserver 127.0.0.1

This example (I think John’s answer points the the same thing at a different place), describes how to access another machine’s UDP/DNS services over an TCP/SSH connection.

We will forward local UDP/53 traffic to TCP, then TCP traffic with the port-forwarding mechanism of SSH to the other machine, then TCP to UDP/53 on the other end.
Typically, you can do it with openvpn.
But here, we’ll do it with simpler tools, only openssh and netcat.

At the end of that page, is another comment with a reference to ‘socat‘,
The same UDP/DNS access is made with,

Server side: socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53
Client side: socat udp4-listen:53,reuseaddr,fork tcp:localhost:5353

Refer socat examples for more.

SSH (at least OpenSSH) has support for simple VPNs. Using the -w or Tunnel option in the ssh client, you can create a tun device at both ends, which can be used to forward any kind of IP traffic. (See also Tunnel in the manual page of ssh_config(5).) Note that this requires OpenSSH (and probably root privileges) at both ends.

Or you could simply use ssf (which was designed to handle this use case), with a simple command:


Client side:

#>./ssfc -U 53:192.168.1.1:53 server.foo.com

This command redirects local port 53 (dns) to 192.168.1.1 port 53, through a secure tunnel between localhost and server.foo.com.


You will need a ssf server (instead of – or next to – your ssh server):

#>./ssfs

By the way, both client and server side of ssf work on Windows / Linux / Mac.
This is a userland application, so you don’t need tun/tap or VPN.

To redirect port 53, you will need administrative privileges – regardless of the tool you’re using.

For more info, details, use case, or download: https://securesocketfunneling.github.io/ssf/

I couldn’t get nc to work for SNMP, because SNMP clients keep choosing a new source UDP port, and several can be active at once.

Instead, I’ve written a post describing how to do it with socat in this blog post, using SNMP as an example. Essentially, using two terminals, starting with an overview:

overview

Terminal one:

client$ ssh -L 10000:localhost:10000 server
server$ socat -T10 TCP4-LISTEN:10000,fork UDP4:switch:161

This creates the SSH forwarding of TCP port 10000 and runs socat on the server. Notice how the switch’s IP address is mentioned in the socat command line as “switch”.

Terminal two:

client$ sudo socat UDP4-LISTEN:161,fork TCP4:localhost:10000

That sets up socat on the client. That should do it.

A VPN is a better solution if you have access to an UDP port.

If you only have access to the TCP SSH port, then an SSH tunnel is as good as a VPN, at least for ping and packet backtracking.

on ssh server:

sudo ip tuntap add dev tun7 mode tun user SSHUSER
sudo ip addr add 192.168.7.1/30 dev tun7
sudo iptables -t nat -A PREROUTING -p udp -i eth0 --dport PUBLIC_PORT -j DNAT --to-destination 192.168.7.2:LOCAL_PORT
sudo iptables -t filter -A FORWARD -i eth0 -p udp -d 192.168.7.2 --dport LOCAL_PORT -j ACCEPT
sudo iptables -t filter -A FORWARD -i tun7 -o eth0 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o tun7 -j MASQUERADE
# set "PermitTunnel point-to-point" for user SSHUSER in /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart sshd

on ssh client running udp server:

sudo ip tuntap add dev tun8 mode tun user LOCALUSER
sudo ip addr add 192.168.7.2/30 dev tun8
ssh -v -w 8:7 [email protected]

inspired by comment UDP traffic through SSH tunnel

Tagged : / /