Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

network diagram

[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
share|improve this question
add comment

1 Answer

A couple of questions to clarify, basically, you want the openvpn clients to have access to what the openvpn server does, mainly the target ssh server subnet (10.10.0.1). Correct?

Does the openvpn server have access to everything it should? If so, I believe it's simply a matter of routing, telling the openvpn client, that anything going to 10.10.0.1/24 routes through 10.8.0.1.

If I'm missing something please let me know.

If not, you can just tell openvpn to route for gateways behind it as well, and push those routes to the client.

push "route 10.10.0.0 255.255.255.0"

Make sure you let the 10.10.0.0 boxes know the route back to the clients. Also, don't forget to allow ip forwarding

share|improve this answer
    
Ok, we're heading in the right direction. For one thing, I was missing the "push" config on my server. I'll give that a shot. –  Sam Martin Mar 5 '13 at 17:02
    
Sounds good, let us know if it worked. –  rfelsburg Mar 5 '13 at 17:14
    
Running "telnet 10.10.0.9 8080" from the client causes tcpdump to spit out a line on the OpenVPN server, but nothing seems to be hitting the target machine. The same command run from the OpenVPN server itself does hit the target machine (and works properly). On the client, though, it's an immediate "connection refused". Regular outbound traffic from the client works properly through the OpenVPN box, though, just not to hosts behind the server-side tunnel. –  Sam Martin Mar 5 '13 at 17:55
    
Make sure you've poked a hole in the firewall in the forwarding chain for that traffic. –  rfelsburg Mar 5 '13 at 17:57
    
I added some iptables output from the OpenVPN box (currently a local VM for testing, but the same setup as I'll be using, sans firewall). I'm guessing it's a simple fix, but I know next to nothing about setting up iptables. If there's other output that would be helpful, let me know. Thanks for the help. –  Sam Martin Mar 5 '13 at 18:08
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.