iptables rule(s) to send openvpn traffic from clients over an sshuttle tunnel?
Posted
by
Sam Martin
on Server Fault
See other posts from Server Fault
or by Sam Martin
Published on 2013-03-05T16:46:32Z
Indexed on
2014/08/21
22:22 UTC
Read the original article
Hit count: 276
I have an Ubuntu 12.04 box with OpenVPN. The VPN is working as expected -- clients can connect, browse the Web, etc. The OpenVPN server IP is 10.8.0.1 on tun0.
On that same box, I can use sshuttle to tunnel into another network to access a Web server on 10.10.0.9. sshuttle does its magic using the following iptables commands:
iptables -t nat -N sshuttle-12300
iptables -t nat -F sshuttle-12300
iptables -t nat -I OUTPUT 1 -j sshuttle-12300
iptables -t nat -I PREROUTING 1 -j sshuttle-12300
iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.10.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42
iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp
Is it possible to forward traffic from OpenVPN clients over the sshuttle tunnel to the remote Web server? I'd ultimately like to be able to set up any complicated tunneling on the server, and have relatively "dumb" clients (iPad, etc.) be able to access the remote servers via OpenVPN.
Below is a basic diagram of the scenario:
[Edit: added output from the OpenVPN box]
$ sudo iptables -nL -v -t nat
Chain PREROUTING (policy ACCEPT 1498 packets, 252K bytes)
pkts bytes target prot opt in out source destination
1512 253K sshuttle-12300 all -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT (policy ACCEPT 322 packets, 58984 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 584 packets, 43241 bytes)
pkts bytes target prot opt in out source destination
587 43421 sshuttle-12300 all -- * * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 589 packets, 43595 bytes)
pkts bytes target prot opt in out source destination
1175 76298 MASQUERADE all -- * eth0 10.8.0.0/24 0.0.0.0/0
Chain sshuttle-12300 (2 references)
pkts bytes target prot opt in out source destination
17 1076 REDIRECT tcp -- * * 0.0.0.0/0 10.10.0.0/24 TTL match TTL != 42 redir ports 12300
0 0 RETURN tcp -- * * 0.0.0.0/0 127.0.0.0/8
$ sudo iptables -nL -v -t filter
Chain INPUT (policy ACCEPT 97493 packets, 30M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
131K 109M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1370 89160 ACCEPT all -- * * 10.8.0.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
[Edit 2: more OpenVPN server output]
$ netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
[Edit 3: still more debug output] IP forwarding appears to be enabled correctly on the OpenVPN server:
# find /proc/sys/net/ipv4/conf/ -name forwarding -ls -execdir cat {} \;
18926 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/all/forwarding
1
18954 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/default/forwarding
1
18978 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/eth0/forwarding
1
19003 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/lo/forwarding
1
19028 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/tun0/forwarding
1
Client routing table:
$ netstat -r
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
0/1 10.8.0.5 UGSc 8 48 tun0
default 192.168.1.1 UGSc 2 1652 en1
10.8.0.1/32 10.8.0.5 UGSc 1 0 tun0
10.8.0.5 10.8.0.6 UHr 13 0 tun0
10.10.0/24 10.8.0.5 UGSc 0 0 tun0
<snip>
Traceroute from client:
$ traceroute 10.10.0.9
traceroute to 10.10.0.9 (10.10.0.9), 64 hops max, 52 byte packets
1 10.8.0.1 (10.8.0.1) 5.403 ms 1.173 ms 1.086 ms
2 192.168.1.1 (192.168.1.1) 4.693 ms 2.110 ms 1.990 ms
3 l100.my-verizon-garbage (client-ext-ip) 7.453 ms 7.089 ms 6.248 ms
4 * * *
5 10.10.0.9 (10.10.0.9) 14.915 ms !N * 6.620 ms !N
© Server Fault or respective owner