Posted: Sun Jul 29, 2012 2:57 Post subject: Cisco E1550 with OpenVPN client doesn't forward packets
I have a Cisco E1550 with "DD-WRT v24-sp2 (04/07/12) vpn - build 18946M NEWD-2 K2.6 Eko" loaded.
I have successfully configured it in WiFi Repeater mode. The wl0.1 LAN is 192.168.2.0/24 and it is successfully repeating to the WiFi "main" SSID LAN.
I have also successfully set up the OpenVPN client and it successfully connects to an OpenVPN server hosted on a Linux machine. (The openvpn server is 10.8.10.248)
I telnet to the dd-wrt router at 192.168.2.1 and from its internal prompt I can traceroute and ping to a host on the far side of the openvpn tunnel. Traceroute confirms that the route is THROUGH the tunnel. (The destination host is 10.8.10.182, via tunnel terminating at 10.8.10.248)
Now, I connect a wireless client (i.e., via wifi) to the dd-wrt router's advertised wl0.1 SSID. I am vended a DHCP address on the dd-wrt LAN. This new host is 192.168.2.143. It's default route is via 192.168.2.1
I CANNOT ping or traceroute to 10.8.10.182 from this connected wifi client.
In other words, the traffic is not being properly tunneled and/or NATed.
Based on counters on various iptables rules I can see that the traffic is arriving at dd-wrt, and that the routing table is good -- counters on the "log accept" rule are increasing, as well as on the *->tun1 rule. E.g., after 917 failed pings iptables -nvL FOWARD shows:
In order to eliminate any questions about NAT or other layer 3 configurations, I tcpdump the tunnel interface on the openvpn server linux host (i.e., the far end of the tunnel).
When pinging from within dd-wrt prompt, I see the ICMP packets arriving at the far end of the tunnel. However, I do NOT see such packets when the ping originates at the connected wifi client. It seems that these packets are not entering the tunnel at all.
It appears that even though the routing table is correct, and iptables are correct, and the last action on the traffic coming from the wifi client with destination the openvpn tunnel is "ACCEPT", those packets are being silently dropped within the dd-wrt router.
Each of these statements has been verified empirically:
routing table correct: If I remove the 10.8.10.0/24 entry of the routing table, I see iptables counters associated with tun1 stop incrementing.
iptables correct: Per above, I see counters incrementing on rules that end in an ACCEPT action. I have also specifically tried adding a br0->tun1 and tun1->br0 ACCEPT rule, which I see increment, but no change in behavior.
* I've tried this with both "Setup -> Advanced Routing" setting at "Gateway" and "Router" I didn't have time to investigate what difference this made to iptables or other settings. I suspect only that it changes some entry in the nat table.
* I've tried this with both 'push "redirect-gateway def1 bypass-dhcp" ' and without in the client ccd on the linux openvpn server; this seems to only affect the ultimate routing table on the dd-wrt side, but the 10.8.10.0/24 net is always pushed through anyway, so no real effect.
* I've tried emptying the iptables (iptables -F FORWARD), and since that also didn't work despite the "policy ACCEPT" counter incrementing, I also tried adding an "accept all" rule, with no change in behavior
* I have verified that the source address on the incoming unsuccessfully tunneled traffic is indeed 192.168.2.143 by adding an iptables rule that matches that source address, with ACCEPT, and I see that its counters increase.
* To repeat: Traffic originating at the dd-wrt device itself, e.g. "ping" from its prompt, correctly flows over the tunnel.
I'm at a loss as to why the traffic is not being tunneled by openvpn. Any hints would be appreciated. The net mask is a /24 on br0, so I don't think openvpn could be silently discarding due to unknown network (i.e., iroute case).
I rebooted the router and set it back to Gateway mode. I then added the nat entry so many posting talk about, and voila, it seems to work. I'll post a complete cookbook once I've done a little more experimentation.
Believe me, I have spent a lot of time on this (several days), and had definitely tried what's below before, but apparently, something else must have been wrong, because it seems I am now close to a complete solution.
I think the prior problems have something to do with pings from dd-wrt console being sourced at the tunnel endpoint IP while pings from the wifi client had the LAN address on them, and then internally, openvpn was dropping traffic (i.e., iroute related problem). However, I saw none of the usual "dropped packet" logging anywhere so I assumed this wasn't the issue.
It sure would be nice to have tcpdump or some simplified packet inspection facilities as part of the standard builds.
The factor determining whether traffic is properly tunneled is the "Gateway" vs "Router" setting under Settings->Advanced Routing.
Leaving everything else exactly the same, it works when it's Gateway only.
iptables -t nat -nvL
and
iptables -t filter -nvL
do not show differences that would seem to be material (the iptables -t nat -I POSTROUTING -o tun1 -j MASQUERADE line I added to Firewall still takes effect and at same precedence) .
So, if someone with specific knowledge about what else changes when this drop down is moved to "Router" can comment on this, that would be great. For now, my setup works under "Gateway"
WiFi Repeater -> Open VPN Client that uses WiFi to access an Open VPN server on a linux host -> When tunnel is active, via push redirect-gateway directive, all traffic goes out over VPN tunnel.
Also, I used the "Local DNS" entry under "Setup -> Basic Setup -> Router IP" to specify google public DNS 8.8.8.8 and see that it is taking top priority in /tmp/resolv.dnsmasq on the router. WiFi Clients are getting the router's IP as their DNS host.
I'm done implementing my requirements. I will have this router around only for another day or so if any additional testing is requested of me.
Did you setup your vpn via the GUI or through the config file? Most postings I have read has been through the config file. However, have ran across several that suggested that the GUI will take care of everything and you don't have to mess with any of the command line like the iptable or firewall, which is the reason I went strictly GUI.
I used the guy (mostly) but added the critical iptables entry via the Firewall command entry under Administration tab. Unfortunately I sent the device off to its user already and can't easily get the config any more.
