Posted: Wed Feb 13, 2019 2:36 Post subject: OpenVPN client on dd-wrt 2nd router
I am trying to get a router to act as an OpenVPN client.
It is a Linksys E2500 running DD-WRT v3.0-r33772 mega (11/16/17). I have a Raspberry Pi running PIVPN server at a remote location with a dyndns.org domain. It took forever to get the OpenVPN client to connect, but thanks to other posts here, I finally accomplished that (using an older firmware). In the pivpn server, I see the dd-wrt router connection reported as connected. I use the same pivpn server to connect to other android and PC clients, all functioning perfectly, with great speed and functionality.
My network configuration is as listed below:
1. ISP modem
2. Main Router running DD-WRT, 192.168.99.0/24
3. Cable from a LAN port on the main router to the WAN port of the VPN Router
3. VPN Router with subnet of 192.168.101.0/24
4. VPN Router has a fixed IP for the WAN of 99.3, and the main router has a DMZ assigned to that IP.
This configuration worked perfectly when I used a commercial VPN for several years. Although, I never paid much attention to the commands or configuration that was used in the commercial setup. The WAN IP always showed the remote IP in the top right corner and the Status page, WAN tab.
Everything works fine in both subnets without the VPN. When I finally got the VPN connected, I have no internet availability in the VPN subnet. It won't communicate via domain names or IP addresses. Now, after the new VPN connects, I still see the local WAN IP displayed.
The NAT is enabled on the OpenVPN client configuration page.
I've switched between router or a gateway in the Setup, Advanced Routing tab, Operating Mode, no effect it seems.
Here's the top of the openvpn config file.
verify-x509-name server_blahblahblah name
Status, VPN tab reports connected, but no remote address. The status section shows plenty of read and write bytes. The local address shown below is the IP range for devices connected to PIVPN.
Client: CONNECTED SUCCESS
Local Address: 10.8.0.9
19691231 19:00:11 I OpenVPN 2.4.4 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov 16 2017
19691231 19:00:11 I library versions: OpenSSL 1.1.0g 2 Nov 2017 LZO 2.09
19691231 19:00:11 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
19691231 19:00:11 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20190212 20:58:32 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
20190212 20:58:32 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
20190212 20:58:32 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
20190212 20:58:32 NOTE: --mute triggered...
20190212 20:58:32 1 variation(s) on previous 3 message(s) suppressed by --mute
20190212 20:58:32 I TCP/UDP: Preserving recently used remote address: [AF_INET]<resolvedIP-port>
20190212 20:58:32 Socket Buffers: R=[163840->163840] S=[163840->163840]
20190212 20:58:32 W --mtu-disc is not supported on this OS
20190212 20:58:32 I UDP link local: (not bound)
20190212 20:58:32 I UDP link remote: [AF_INET]<resolvedIP-port>
20190212 20:58:32 TLS: Initial packet from [AF_INET]<resolvedIP-port> sid=b63cbca6 21e84d7c
20190212 20:58:32 VERIFY OK: depth=1 CN=ChangeMe
20190212 20:58:32 VERIFY KU OK
20190212 20:58:32 NOTE: --mute triggered...
20190212 20:58:33 5 variation(s) on previous 3 message(s) suppressed by --mute
20190212 20:58:33 W WARNING: 'link-mtu' is used inconsistently local='link-mtu 1570' remote='link-mtu 1569'
20190212 20:58:33 W WARNING: 'comp-lzo' is present in local config but missing in remote config local='comp-lzo'
20190212 20:58:33 Control Channel: TLSv1.2 cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit EC curve: prime256v1
20190212 20:58:33 I [server_J8LYl58uzalUDqUZ] Peer Connection Initiated with [AF_INET]<resolvedIP-port>
20190212 20:58:34 SENT CONTROL [server_J8LYl58uzalUDqUZ]: 'PUSH_REQUEST' (status=1)
20190212 20:58:34 PUSH: Received control message: 'PUSH_REPLY dhcp-option DNS 184.108.40.206 dhcp-option DNS 220.127.116.11 block-outside-dns redirect-gateway def1 route-gateway 10.8.0.1 topology subnet ping 1800 ping-restart 3600 ifconfig 10.8.0.9 255.255.255.0 peer-id 0 cipher AES-256-GCM'
20190212 20:58:34 N Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: block-outside-dns (2.4.4)
20190212 20:58:34 OPTIONS IMPORT: timers and/or timeouts modified
20190212 20:58:34 OPTIONS IMPORT: --ifconfig/up options modified
20190212 20:58:34 OPTIONS IMPORT: route options modified
20190212 20:58:34 NOTE: --mute triggered...
20190212 20:58:34 5 variation(s) on previous 3 message(s) suppressed by --mute
20190212 20:58:34 Data Channel: using negotiated cipher 'AES-256-GCM'
20190212 20:58:34 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20190212 20:58:34 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20190212 20:58:34 I TUN/TAP device tun0 opened
20190212 20:58:34 TUN/TAP TX queue length set to 100
20190212 20:58:34 D do_ifconfig tt->did_ifconfig_ipv6_setup=0
20190212 20:58:34 I /sbin/ifconfig tun0 10.8.0.9 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
20190212 20:58:34 /sbin/route add -net <resolvedremoteIP> netmask 255.255.255.255 gw 192.168.99.1
20190212 20:58:34 /sbin/route add -net 0.0.0.0 netmask 18.104.22.168 gw 10.8.0.1
20190212 20:58:34 /sbin/route add -net 22.214.171.124 netmask 126.96.36.199 gw 10.8.0.1
20190212 20:58:34 I Initialization Sequence Completed
I assume this is some routing issue, hopefully simple but I am very weak in such things. I appreciate any direction.
Joined: 18 Mar 2014 Posts: 3666 Location: Netherlands
Posted: Wed Feb 13, 2019 18:53 Post subject:
If I understand it correctly you have two routers daisy chained (LAN<>WAN), on the second router you have a VPN client to an external VPN server.
If so the secondary router has to be setup as default gateway mode.
Important is that the secondary router, the OpenVPN subnet and the OVPN servers subnet are all different, you have to have 3 different subnets.
The following is probably the source of all your problems.
That one little innocent looking line you added to Additional Config is a VPN wrecker. What that directive does is tell OpenVPN to select an arbitrary network interface name based on the prefix "tun". So it did. It used tun0. But here's the problem.
The dd-wrt OpenVPN client doesn't need that directive. It automatically uses tun1 as its network interface name. And all the firewall rules and routing assume the use of tun1. So by using the dev directive, you basically overrode the network interface name from tun1 to tun0 and broke it. None of the auto-generated firewall rules will work because they refer to tun1, NOT tun0. In the end, you fixed what you broke by adding firewall rules based on tun0.
This is why we tell ppl all the time, including egc's openvpn guides, do NOT over configure the OpenVPN client or server. 9 times out of 10, what you add to the Additional Config field is completely unnecessary. Sometimes you luck out and it's redundant or harmless. But sometimes it breaks things. And the use of the dev directive is a major no-no.
P.S. The dd-wrt developers are partially to blame here. They *should* have used the OpenVPN $dev variable in their firewall script so they picked up the correct network interface name, rather than just hardcoding tun1 into the OpenVPN client. If they had done so, then it wouldn't matter if the user had overridden the network interface name for some reason. The OpenVPN client would still have worked. The use of a hardcode network interface name is just bad design because it creates the opportunity for someone to break the OpenVPN client.
I'll probably report this as a bug (not sure it will ever get addressed though).
I tried to remove the dev tun line from the additional config field, as well as the Firewall commands, but it was unsuccessful, same problem as before, no web pages opened. I didn't do any troubleshooting, just restored the previous config and I'm good.
fwiw... the openvpn client in this case is severely over configured, in the sense that the only way I could get the thing to connect at all was to paste the entirety of the openvpn config file generated by the pivpn into the Additional Config field, including all the certs.
If you're happy w/ the current results, so am I. All I'm saying is that overriding things w/ the Additional Config field is one of the most common mistakes we see. And in all the YEARS I've been working w/ OpenVPN, and on the dd-wrt platform in particular, I've *never* seen a case where the OpenVPN client couldn't be configured normally (by which I mean, NOT dumping the VPN provider's config file into Additional Config). And unless I was configuring the OpenVPN client myself w/ that VPN provider, I can't diagnose what the specific problem/issue may be that's preventing normal usage.
If it ever came to be that I couldn't get it to work normally, I'd probably be more inclined to simply run the OpenVPN client from the command line, w/ my own scripting, and bypass the GUI entirely. After all, if you end up dumping everything into the Additional Config field and build all your own firewall rules, what's the real benefit of use the GUI anyway?!
P.S. Here's another example of where the developers could have done better. Just like Merlin's firmware, they could have provided the option to let the user provide their own OpenVPN config file! IOW, the GUI would do NONE of the configuration except perhaps for the firewall rules. But of course that would have require fixing the bug report I just filed.
Bottom line, the dd-wrt OpenVPN client and server (particularly the former) have some serious problems that need to be addressed.