Router – How to forward traffic to VPN device

openwrtrouterroutingvpn

I have set-up OpenWRT in a virtual machine which acts as a router. It has two network interfaces:

br-lan: connected to vm internal network
eth1: connected to internet through host via NAT

I have also set-up a DamnSmallLinux (DSL) VM which has one network interface:

eth0: connected to vm internal network

This set-up means DSL connects to the internet through OpenWRT.

Now, OpenWRT creates a tun device connected to a VPN:

/*tun device on OpenWRT*/
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.130.3.45  P-t-P:10.128.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:494 errors:0 dropped:0 overruns:0 frame:0
          TX packets:494 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:41496 (40.5 KiB)  TX bytes:41496 (40.5 KiB)

I can test if I am connected to the VPN by pinging the vpn gateway10.128.0.1:

/*Ping VPN on OpenWRT*/
PING 10.128.0.1 (10.128.0.1): 56 data bytes
64 bytes from 10.128.0.1: seq=0 ttl=64 time=12.364 ms
64 bytes from 10.128.0.1: seq=1 ttl=64 time=13.326 ms

By default, DSL cannot ping 10.128.0.1.

If I add the following rule to OpenWRT's firewall, then DSL can ping 10.128.0.1

/*Zone rule for VPN, enables DSL to ping 10.128.0.1*/
config zone                                     
        option input 'ACCEPT'                   
        option forward 'REJECT'                 
        option output 'ACCEPT'                  
        option name 'vpn'                       
        option masq '1'                         
        option network 'VPN'

I now want to route all traffic from DSL through the VPN but I don't know what to do. I have tried adding the following route to the /etc/config/network file on OpenWRT:

/*Directs all traffic to tun0 but VPN does not reply.*/
config route                                   
        option interface 'VPN'                 
        option target '0.0.0.0'                
        option netmask '0.0.0.0'               
        option gateway '10.128.0.1'

When I do a tcpdump of tun0 after adding this route, it does appear indeed that all the traffic is being directed to the VPN, the problem is that I don't get any replies from it.

Does anybody have any idea of how to properly forward all the traffic to the VPN?

Edit

OpenWRT ifconfig:

root@OpenWrt:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr 08:00:27:0E:CF:19  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fd93:d43b:534d::1/60 Scope:Global
          inet6 addr: fe80::a00:27ff:fe0e:cf19/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:130 errors:0 dropped:0 overruns:0 frame:0
          TX packets:139 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:10392 (10.1 KiB)  TX bytes:15306 (14.9 KiB)

eth0      Link encap:Ethernet  HWaddr 08:00:27:0E:CF:19  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:152 errors:0 dropped:0 overruns:0 frame:0
          TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:14368 (14.0 KiB)  TX bytes:15632 (15.2 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:78:6B:EE  
          inet addr:10.0.3.15  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe78:6bee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:246 errors:0 dropped:0 overruns:0 frame:0
          TX packets:275 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:33158 (32.3 KiB)  TX bytes:32283 (31.5 KiB)

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:65 errors:0 dropped:0 overruns:0 frame:0
          TX packets:65 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:5164 (5.0 KiB)  TX bytes:5164 (5.0 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.130.3.45  P-t-P:10.128.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:57 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:4788 (4.6 KiB)  TX bytes:4788 (4.6 KiB)

Best Answer

The OpenWRT has all the interfaces it needs (and thus the route) to be able to ping the remote gw (10.128.0.1). And it seeme the VPN replies back. good.

Now, on the DSL, you need to add a route : 10.128.0.X/24 (or 10.X/8 ? depends what you have setup on the remote... adjust as needed), with gateway 10.130.3.45 (ie, the OpenWRT, which is the "gateway" you need to go through to reach the 10.128.x network). A lan can only acces another LAN by going through a gateway, using that gateway's LAN ip, as it's the only thing a local machine can access: any ips on its (one or many) LANs. It seems you directly put the remote IP on the DSL, but the DSL doesn't know how to reach it. It probably by default send it to its "default gateway", which could be a internet router or anything, but apparently not the OpenWRT (or at least not the OpenWRT 10.130.3.45 interface, the one which gateways to the 10.X net)

I may have read diagonally.

But in a nutshell:

place yourself in the packet, and act as if you want to reach the destination, hop by hop:
you need to find the "closest" route (or, if none, take the default route) to go to the next hop.
Proceed like this hop by hop (forward, and also backwards), and you'll soon find which of the hop doesn't have the necessary step to reach the next hop (or maybe goes to a wrong hop)

ie:

I'm a ping packet sent from DSL. my source is DSL-ip. My destination is a.b.c.d (10.128.0.1, I guess).
I look at the ROUTE table, and choose the destination that most precisely fit a.b.c.d (ie, between 0.0.0.0/0 (defautl gw) , 10.0.0.0/8 (with gw 10.130.3.45) and a special 10.128.0.x (with gw 10.120.3.45), I chose the latest as it's a more precise fit, ie more "bits" match my destination).
So I take that route, and go to 10.130.3.45. (if my local firewall allows it)
Now I'm a ping packet with source "...." (could change because of SNAT), and destination "....." (could change with DNAT). And I look at the routing table...

You'll of course also need forward iptables to allow you to proceed to the next hop (and with rules that establish connections, allowing thus the reply packets to come back too.

Don't allow both directions, it would open your LAN to anything incoming from the VPN instead of just the established connections!) – Olivier Dulac just now edit

Related Solutions

Openvpn for client/server in same subnet

Your default route metric value is lower than the 10.22.0.0/16 route and it gets routed to the default route. In resolving routes, if more than one route matches destination, the lower metric value route takes precedence.

Either push a default route through VPN or lower metric for 10.22.0.0/16 (increase metric for default route).

It should look like this:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      0.0.0.0          0.0.0.0    192.168.1.254     192.168.1.23    1000
    10.22.0.0      255.255.0.0        10.22.8.1       10.22.8.10     30
    10.22.8.0    255.255.255.0         On-link        10.22.8.10    286
   10.22.8.10  255.255.255.255         On-link        10.22.8.10    286
  10.22.8.255  255.255.255.255         On-link        10.22.8.10    286

Centos 6.2 Fresh ‘Basic Server’ install networking issues

Your routes and configuration look fine.

$: route -n
Destination // Gateway // Genmask // Flags // Metric // Ref // Use // Iface
66.*.*.0       0.0.0.0    255.255.255.248   U   1003      0   0     0  em2
0.0.0.0        66.*.*.1   0.0.0.0           UG     0      0   0     0  em2

The first route, 66.*.*.0/29 with gateway 0.0.0.0 tells your computer to use interface em2 and then make an arp request to find the hardware address of the host you're trying to reach. This is a "connected" route.

The second one is the default route, pointing at your default gateway through em2. If you need to send a packet in another network than 66.*.*.0/29, your computer will make an arp request to find 66.*.*.1 and then send the packets to it.

The only thing in your configuration that could be an issue is the NM_CONTROLLED=yes statement in /etc/sysconfig/network-scripts/ifcfg-em2. This tells the system that this interface is controlled by NetworkManager. This could interfere with your static configuration.

However, even without any default gateway you should be able to ping and ssh from the 66.*.*.0/29 subnet to your machine.

Check layer 1 first, and ensure that the cable is plugged on each side. Use leds on nic and switch, and check if the system sees it correctly:

# mii-tool
eth0: negotiated 1000baseT-FD flow-control, link ok

Then verify if any iptables are dropping the packets. Use iptables -L or iptables-save to check for any rules, and iptables -D <rule> to delete them. Pay attention to the default policy.

Also, on some systems, NetworkManager can configure ufw automatically, and I've had issues with static interface configuration that wasn't seen by NM and hence blocked by ufw.

Best Answer

Related Solutions

Openvpn for client/server in same subnet

Centos 6.2 Fresh ‘Basic Server’ install networking issues

Related Topic