2

This is my ifconfig setup:

eth1      Link encap:Ethernet  HWaddr 54:04:a6:49:99:16  
          inet addr:192.168.0.12  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::5604:a6ff:fe49:9916/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33325389 errors:0 dropped:0 overruns:0 frame:0
          TX packets:19876569 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:38511610122 (38.5 GB)  TX bytes:5030880286 (5.0 GB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1532251 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1532251 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:128544929 (128.5 MB)  TX bytes:128544929 (128.5 MB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:113 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1663663 errors:0 dropped:489668 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:14523 (14.5 KB)  TX bytes:1140762511 (1.1 GB)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.9.0.6  P-t-P:10.9.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1623870 errors:0 dropped:570939 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:828 (828.0 B)  TX bytes:1130753499 (1.1 GB)

wlan0     Link encap:Ethernet  HWaddr 00:21:00:e6:c8:aa  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

So I have this ip routing setup:

default via 192.168.0.1 dev eth1  proto static 
10.8.0.0/24 via 10.8.0.5 dev tun0 
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6 
10.9.0.0/24 via 10.9.0.5 dev tun1 
10.9.0.5 dev tun1  proto kernel  scope link  src 10.9.0.6 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.12  metric 1 
192.168.1.0/24 via 10.8.0.5 dev tun0 

It works as intended. I am able to ping machines through both tunnels (openvpn).

However, when I add

sudo ip route add 0.0.0.0/1 via 10.9.0.5 dev tun1 
sudo ip route add 128.0.0.0/1 via 10.9.0.5 dev tun1 

everything breaks. I can no longer ping machines through either tunnels.

I really don't understand why though. Since I have a "higher prefix" route defined as

10.8.0.0/24 via 10.8.0.5 dev tun0 

why does the new "lower prefix" route prevent me from pinging 10.8.0.1?


For context, I am running an openvpn server to which this client connects and gets assigned the 10.8.0.6 ip. After that it connects to another openvpn server (10.8.0.10) which is connected to the same "original" server (10.8.0.1). The first server essentially just puts me on the same subnet as the second server (second server doesn't have a static ip and can't be port forwarded). The 2 low prefix routes I'm adding are part of a "redirect-gateway" option as I'm attempting to forward all traffic through the second server.


EDIT:

I'm adding all the config files. (I'll omit irrelevant or default settings)

  • main > the main client that is trying to achieve internet traffic routing
  • alpha > the server that puts everyone on the same subnet
  • beta > the server/client that main wants to route it's traffic through. (note, beta doesn't have a static ip and cannot be port forwaded)

alpha server.conf

port 443
proto udp
dev tun
server 10.8.0.0 255.255.255.0
client-to-client
# broadcast beta's subnet
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

beta client.conf (used to connect to alpha server)

client
dev tun
proto udp
remote [alpha IP] 443

beta server.conf (the traffic should be routed through this server)

port 444
proto udp
dev tun
server 10.9.0.0 255.255.255.0
client-to-client
push "redirect-gateway local def1"
push "dhcp-option DNS 8.8.8.8"

main alpha client.conf

client
dev tun
proto udp
remote [alpha IP] 443

main beta client.conf

client
dev tun
proto udp
remote 10.8.0.10 444

EDIT 2:

I attempted to use a reverse SSH tunnel on the alpha server instead of using an intermediately openvpn server, but I had the exact same problem.

I tunneled from beta like this

ssh -Nf -R \*:444:localhost:444 root@[alpha IP] 

And changed the main client.conf to connect to [alpha IP]:444 instead of 10.8.0.10.

The configuration worked perfectly without redirect-gateway, but as soon as redirect-gateway added the 0.0.0.0/1 and 128.0.0.0/1 routes, I couldn't ping anywhere again.

  • Why don't you just let OpenVPN handle setting up the routes? – Michael Hampton Sep 11 '14 at 10:54
  • The routes I'm showing you are the routes set by openvpn. – Nikita240 Sep 11 '14 at 11:02
1

You're routing the external endpoint of your tunnels to the tunnel address. That won't work. If you add specific routes for the tunnel endpoints via eth1 it works.

| improve this answer | |
  • I don't quite understand what you mean. – Nikita240 Sep 7 '14 at 13:11
  • You routing everything (split into two /1's) to your tunnel. Including the outside address of the tunnel. That way, the tunnel breaks. Make sure you route 10.8.0.5 and 10.9.0.5 via eth1, not via one of the tunnel interfaces. – Teun Vink Sep 7 '14 at 13:12
  • 3
    That's not quite right. You need a host route to your VPN server's IP address, the one the client is configured to connect to in order to establish the connection. – Michael Hampton Sep 7 '14 at 14:28
  • 1
    Well,I can't make it any simpler: you cannot route the outer endpoint of the VPN tunnel, to which your side connects, through the VPN tunnel, which is what you're trying to do. The moment you do that, your side tries to route traffic for the VPN endpoint through the VPN endpoint, so the tunnel breaks. As I said before, you need to add explicit host routes for your VPN endpoints via eth1 if you want to route the (rest of) the entire internet through the VPN. – Teun Vink Sep 8 '14 at 12:37
  • 1
    Please add your tunnel config and routing table to the original question then. – Teun Vink Sep 8 '14 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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