Hi everyone, I have been a dd-wrt user for many years now and currently my wrt1200ac and wrt1900acs are connected as OpenVPN client/server with PBR and they are working great.
A friend needed a similar setup and he bought two D-Link DIR-882, I have flashed them successfully, set them as wireless access point (but Operating mode Gateway as suggested in the guide as there are internet provider's primary routers).
For both server and client configuration I have followed what is in the OpenVPN setup guide section, I have done it following step by step the whole procedure. The server is running and I can connect three clients, which are two mobile phones and the other router. Here the inconsistent behaviour:
The phones go out to the WAN with the server IP (what I want), but the clients connected to the OpenVPN client router instead are showing the client side WAN IP address.
Here the configurations for both routers
Server:
OpenVPN: Enable
CVE-2019-14899 Mitigation: Disable
Start Type: System
Inbound Firewall on TUN: FALSE
Config as: GUI(server)
Server mode: Router (TUN)
Network: 192.168.2.0
Netmask 255.255.255.0
Port: 1194
Tunnel Protocol: udp4
Encryption Cipher: Not Set
Hash Algorithm: None
First Data Cipher: CHACHA20-POLY1305
Second Data Cipher: AES-128-GCM
Third Data Cipher: AES-256-GCM
Advanced Options: Enable
TLS Cipher: None
Compression: Disabled
Push Client route: Default Gateway (But Maybe this has to be Servers subnet? Client router stop responding when Servers subject is selected. Furthermore why the mobile phones are redirected already?)
Allow Client to Client: Enable
Allow duplicate Clients: Enable
Allow Clients WAN access (internet): Enable
Allow Clients full LAN access: Enable
Tunnel MTU setting: 1400
Tunnel UDP Fragment:
Tunnel UDP MSS-Fix: Disable
Use ECDH instead of DH.PEM: Enable
Additional config: verb 5
I haven't set any firewall rules (unlike my old configuration, as, for what I understood this is not required with the above settings).
Client:
Start OpenVPN Client: Enable
CVE-2019-14899 Mitigation: Disable
Server IP/Name : Port: *****.ddns.net:1194
Set Multiple Servers: Disable
Tunnel Device: TUN
Tunnel Protocol: udp4
Encryption Cipher: CHACHA20-POLY1305
Hash Algorithm: None
First Data Cipher: CHACHA20-POLY1305
Second Data Cipher: AES-128-GCM
Third Data Cipher: AES-256-GCM
User Pass Authentication: Disable
Advanced Options: Enable
TLS Cipher: None
Compression: Disabled
NAT: Enable
Inbound Firewall on TUN: FALSE
Killswitch: TRUE
Watchdog: Disable
Source routing (PBR): Route all sources via VPN
IP Address:
Subnet Mask:
Tunnel MTU setting: 1400
Tunnel UDP Fragment:
Tunnel UDP MSS-Fix: Disable
Verify Server Cert: TRUE
TLS Key choice: TLS Auth
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Tue Jul 05, 2022 10:41 Post subject:
I trust you run a recent build (latest is 49418) ?
The subnets of Server, VPN (which is 192.168.2.0) and Client need to be different, please check that
(that is why a VPN's subnet of 192.168.2.0 might not be an optimal choice)
Does the VPN client router show a connection and traffic?
(Show screenshot of OpenVPN status page)
If the VPN client is running on a WAP (Wireless Access Point)
You need to redirect attached LAN clients to the WAP.
In one of the guides there is instruction for that
FYI. In any bridged configuration (i.e., NO active WAN), the Operating Mode is utterly irrelevant. What that option does is enable or disable NAT over the WAN. Specifically, Gateway enables it, Router disables it. But if there is no WAN to begin with, who cares!
Also, in a bridged configuration, any clients behind that bridged router are NOT going to magically route themselves through its VPN. All you have in the current situation is a standalone device that happens to have a VPN connection, but only useful for its own purposes. It's no different than some PC doing the same thing. In order for any other devices on the rest of the network to use that OpenVPN client, they need to have their default gateway changed to the LAN ip of that router.
Hi, thank you very much for your replies. I solved, both routers are out of the main routers subnet now and traffic is going through the tunnel.
This is the current scenario:
Server:
Main router: 192.168.1.1
dd-wrt router: 192.168.2.1
vpn subnet: 192.168.3.0
Client:
Main router 192.168.1.1
dd-wrt router: 192.168.4.1
I have another question please:
Can I with the configuration shown above have a bi-directional tunnel? I would like to run another server on the actual client and another client on the current server, so that my friend can go out on the internet with any IP wherever he is.
What kind of problems could I encounter? I was thinking that maybe the 1194 port should be different, but that's the only thing I figured out could be a problem (I know I could be wrong).
The VPN subnet on the other router would then be 192.168.5.0.
You've lost me w/ all these additional "subnets". I honestly don't understand your solution.
Normally, you keep ALL your devices on the same IP network for a given side, whether that of the OpenVPN server, or OpenVPN client. The only problem is if BOTH sides have the same local IP network (e.g., 192.168.1.x). If either side needs to route directly to the other's IP network, it won't work. They have to be different. It will only work correctly for internet access, when the client's side of the tunnel is NAT'd (so the server side never sees the client's local IP network), and server side never attempts to address the client's local IP network. This is exactly what happens, for example, when using a commercial OpenVPN provider like NordVPN or ExpressVPN. Neither side has a clue what the other is supporting in terms of local IP networks.
But apparently you've created a configuration which supports these additional 192.168.2.x and 192.168.4.x IP networks, while maintaining the 192.168.1.x IP networks on both sides. I just don't see how these additional IP networks actually work within the context of both sides maintaining the same local IP network. Not unless you're telling us each of the routers that participate in the VPN are NOW in a routed configuration (i.e., their WANs are connected to the local IP network of 192.168.1.x on their respective side of the tunnel), while one supports the local IP network of 192.168.2.x, the other 192.168.4.x.
[vpn router (client) - 192.168.4.1](wan)<->(lan)[main router - 192.168.1.x]<-> internet
internet <->[main router - 192.168.1.1](lan)<->(wan)[vpn router (server) - 192.168.2.1]
If that's the case, then this conflicts w/ your original description of at least one of those routers being configured as an AP (i.e., bridged).
To better explain: I have set the client subnet to be 182.168.4.0 as I want to achieve bi-directional VPN, and it’s new VPN subnet would be 192.168.5.0 (but I am not sure this is needed TBH.
Thanks for your help.
To better explain: I have set the client subnet to be 182.168.4.0 as I want to achieve bi-directional VPN, and it’s new VPN subnet would be 192.168.5.0 (but I am not sure this is needed TBH.
Thanks for your help.
I don't follow your logic here.
By default, access is unidirectional, meaning *only* devices behind the OpenVPN client can initiate connections to devices behind the OpenVPN server, or reach the internet. Bidirectional (aka, site-to-site) means devices behind the OpenVPN server can now initiate connections to devices behind the OpenVPN client.
To achieve that requires a specific set of steps, which I believe are detailed in the OpenVPN documentation by @egc. It requires a CCD directory, a file in that directory (based on CN (Common Name) of the connecting client's cert) that contains an iroute directive, etc.
I think bi-directional is wrong in this context. What I meant is that I would like to achieve that if you connect to router “A” you go out with WAN IP of router “B” and if you connect to router “B” you go out with WAN IP of router “A”.
Seeing other clients on subnets is not necessary.
So what you want is to have the VPN default gateway work in either direction.
The most obvious solution is to configure another OpenVPN client and server in the opposite direction. IOW, each side has two tunnels, w/ both an OpenVPN client and OpenVPN server. That is, by definition, bidirectional. It's just that you're relying on completely independent connections (and probably makes more sense in terms of reliability).
Could it be done w/ a *single* OpenVPN connection/tunnel? I'm NOT sure. And it's because this is a client/server (one to many relationship) between the OpenVPN client(s) and the OpenVPN server. You can't just redirect clients on the server side of the tunnel, over that tunnel, w/o being specific as to *which* OpenVPN client is the intended target. That's why there's all the nonsense about the CCD directory, iroute directive, etc. And you've probably have to NAT the tunnel on the server side as well.
Although I haven't tried it, it might be possible to specify the OpenVPN client's local IP network as 0.0.0.0/0 in a site-to-site config, thus convincing the OpenVPN server to treat it as a default gateway. In fact, because there's already a default gateway, you'd actually have to split 0.0.0.0/0 into two parts, 128.0.0.1/1 and 0.0.0.0/1, to act as overrides to the existing default gateway (0.0.0.0/0).
Sorry, I'm thinking all this out in my head. As I said, I haven't attempted this, so I'm just trying to think if there are an *traps* I'm failing to consider.
Yes this is all I need, it is ok that they are on separate tunnels.
I can start a client on what is currently just a server and a server on what is currently just a client. Do you think replicating the above configs will do the job? Maybe just the port has to be different or I can have both servers listening on port 1194?
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Tue Jul 05, 2022 20:53 Post subject:
I would indeed use the setup with OpenVPN Server and OpenVPN Client on both routers
The Client will use PBR and if you add the servers subnet to the PBR then all connections from the server are routed out via the VPN Client.
It really makes it easier to follow the bouncing ball if you have an OVPN server network which is totally different from the others that is why 10.x.x.x networks are often used but actually a better choice (as you are also using an VPN client which often uses 10.x.x.x) is using 172.16-31.x.x.x.
But that is just me I easily get lost when doing elaborate setups
The server setup guide has a paragraph about running an OpenVPN server and client on the same router, no need to use other ports (as the Client is using nobind, meaning it uses en ephemeral listen port) but it does not hurt to use another port then the default 1194 (some even advocate the use of other port numbers as you could be less prone to port probing) _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Ok everything crystal clear, thank you very much.
I’ll reply here once I have the possibility of putting this in place, to let future readers know the outcome.
Regards.
When I used to do this, is was NOT for the purposing of using the remote network as a default gateway, but just to access the remote IP network.
What I'm wondering is if you do this for the purposes of the default gateway, will you create an infinite loop, as each client gets routed back to its own server, forever?
On the server side, you'll probably have to create a static route based on the tunnel's IP network to bind it to the WAN to prevent it.