Yes that is a pitfall but I think if you do not let the client NAT, basically like a site to site setup with the static route, it can work.
You only have the VPN subnet in the PBR so that roaming clients which do NAT will be redirected.
I'm NOT worried about the replies back to the OpenVPN client. I worried about the *outbound* request to the internet. Each OpenVPN server is configured to route the internet via the other's default gateway thanks to the colocated OpenVPN client! That sounds circular to me.
Yes that is a pitfall but I think if you do not let the client NAT, basically like a site to site setup with the static route, it can work.
You only have the VPN subnet in the PBR so that roaming clients which do NAT will be redirected.
I'm NOT worried about the replies back to the OpenVPN client. I worried about the *outbound* request to the internet. Each OpenVPN server is configured to route the internet via the other's default gateway thanks to the colocated OpenVPN client! That sounds circular to me.
I suppose PBR may be a mitigating factor. But it is a bit tricky to prevent problems like this.
To complete the thought (for posterity's sake) ...
It all became clearer in the shower (for some reason I do my best thinking there).
Using a single tunnel would be problematic. In order to prevent an infinite loop (or more accurately, let the ttl drop to 0), you can NOT use the redirect-gateway def1 directive. You need PBR to prevent the looping. But PBR is only available on the OpenVPN client side!
I think it's fine to still NAT the tunnel, since you can identify the clients by their IP network on the tunnel, and exclude them in PBR. If you don't, then you're basically forced to configure for site-site to deal w/ the static routing. Seems to me it's just easier to avoid that issue. NOT unless you intend to support site-to-site for other reasons anyway.
Hi all, thanks again for your replies. I have good news, at least for myself
The two VPN tunnels are working like a charm! You were right about the loop, when I connected both sides I couldn't hit any external website, but with PBR I have solved the issue and now all clients connected to router A go out with router B IP and vice versa.
Here is my configuration:
Router A
Main ISP router subnet: 192.168.1.0
Router A DHCP subnet: 192.168.2.0
VPN subnet: 192.168.3.0
PBR: 192.168.2.0/24
Router B
Main ISP router subnet: 192.168.1.0
Router B DHCP subnet: 192.168.4.0
VPN subnet: 192.168.5.0
PBR: 192.168.4.0/24
Apart from IPs and OpenVPN certs, the router are basically one the backup of the other, so, for readers, please use the client/server configuration in the first post for both routers.
Hi all, thanks again for your replies. I have good news, at least for myself
The two VPN tunnels are working like a charm! You were right about the loop, when I connected both sides I couldn't hit any external website, but with PBR I have solved the issue and now all clients connected to router A go out with router B IP and vice versa.
Here is my configuration:
Router A
Main ISP router subnet: 192.168.1.0
Router A DHCP subnet: 192.168.2.0
VPN subnet: 192.168.3.0
PBR: 192.168.2.0/24
Router B
Main ISP router subnet: 192.168.1.0
Router B DHCP subnet: 192.168.4.0
VPN subnet: 192.168.5.0
PBR: 192.168.4.0/24
Apart from IPs and OpenVPN certs, the router are basically one the backup of the other, so, for readers, please use the client/server configuration in the first post for both routers.
BTW, I do NOT recommend ever using the well-known ports for common services, including OpenVPN. That's asking for trouble, as that's the first place hackers look for known vulnerabilities. Even if there are none, they will seek out your router incessantly hoping to find something. Use more obscure ports, like 21338, 11922, etc. If they don't find the well-known ports open, they usually just move on looking for easier targets.
A little correction for the sake of completeness:
I needed to change the PBRs as sending the whole subnets in the tunnel was making both dd-wrt routers unreachable from the WAN (even 192.168.2.1 and 192.168.4.1 where sent into the tunnel).
If you need to send all the 254 hosts in the VPN I guess you can select: "Route Selected Sources via WAN" 192.168.2.1 (your dd-wrt router IP).
In my case I decided to restrict the DHCP range to 64 hosts (as the routers will be used by a maximum of 10 hosts) starting from 192.168.2.64 and 192.168.4.64 respectively and using a these PBRs: