OpenVPN Client act as Internet gateway

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
dobrosavke
DD-WRT Novice


Joined: 30 Aug 2011
Posts: 6

PostPosted: Fri Jun 07, 2024 12:04    Post subject: OpenVPN Client act as Internet gateway Reply with quote
Greetings all,
I have 2 locations that I need to connect via OpenVPN service in a very specific way.

Both locations are using regular internet connections, no port forwarding, no DMZ.

Location 1 has Netgear R6220 - DD-WRT v51530 router - R1
Location 2 has TPLink Archer A7 v5 - DD-WRT v51530 router - R2

Client 1 ---- R1 ----- Internet ------ R2 ----- Client 2


I have deployed OpenVPN server in the Cloud and used R1 and R2 as clients.
OpenVPN server is running in Tun mode.
Both OpenVPN clients have NAT enabled in OpenVPN GUI setup.

OpenVPN server IP - 172.16.255.1/24
R1 OpenVPN Client1 IP - 172.16.255.100
R2 OpenVPN Client2 IP - 172.16.255.200

R1 LAN is 192.168.1.1/24
R2 LAN is 192.168.50.1/24

Client-to-Client option has been enabled on OpenVPN server R1 LAN can access R2 OpenVPN Client IP also R2 LAN can access R1 OpenVPN Client IP.

We have a 3rd party service in R1 LAN that involves license verification within internal network, meaning devices from R1 LAN access the licensing server, confirm license and access from same public IP which was previously reported by 3rd party service.

Now here comes the tricky part.

I need R2 LAN users to be able to access R1 LAN, managed to complete that by adding routes in ccd folder on OpenVPN server for each client.

I also need R2 LAN users to have public IP same as R1 LAN users and that is what I was not able to accomplish.
Tried all kind of configurations with IPTables and was not successful.

Need help on how to solve this issue.

Thanks all.


Last edited by dobrosavke on Fri Jun 07, 2024 12:54; edited 1 time in total
Sponsor
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 13041
Location: Netherlands

PostPosted: Fri Jun 07, 2024 12:17    Post subject: Reply with quote
I think you need routes to the LAN subnet of the clients from the OpenVPN server side.

For that you have to setup a site-to-site setup with route, iroute and ccd files.

See the OpenVPN Server setup guide, OpenVPN guides are a sticky in this forum.

This is far easier to setup with WireGuard which is also much faster.
So my advice would be to use WireGuard, guides are also a sticky in this forum

_________________
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
dobrosavke
DD-WRT Novice


Joined: 30 Aug 2011
Posts: 6

PostPosted: Fri Jun 07, 2024 12:58    Post subject: Reply with quote
Thanks for the fast reply.

We have NAT enabled on both OpenVPN Clients and default route set for R1 via ccd file on OpenVPN server.

NAT is not being done properly and that is where my stuck is.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 13041
Location: Netherlands

PostPosted: Fri Jun 07, 2024 13:03    Post subject: Reply with quote
For a site to site setup you do not have to enable NAT on the tun interface.

I think that is all covered in the guide.

_________________
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
dobrosavke
DD-WRT Novice


Joined: 30 Aug 2011
Posts: 6

PostPosted: Fri Jun 07, 2024 13:46    Post subject: Reply with quote
Think you missed the point here:
quoted
"
For a site to site setup you do not have to enable NAT on the tun interface.

I think that is all covered in the guide.
"

Site to Site has been configured properly and it works.

We need all users to have same public IP regarding on which site they are in.

Also we have 2 open vpn clients on DD-WRT routers, make a note it is not the same if you have openvpn client or openvpn server running.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 13041
Location: Netherlands

PostPosted: Fri Jun 07, 2024 14:25    Post subject: Reply with quote
So you want R2 clients routed via R1 ?

In that case you have to use PBR on the server.

Basically create routing table with default route via R1
Quote:
ip route add default via "ip-address-of-R1" table 11
ip rule add "lan-subnet-R2" table 11
ip rule add "vpnclient-address-of-R2" table 11


If R2 is only a simple client you can leave NAT enabled in that case you only need the second ip rule

R1 needs to have a route for R2 via the tunnel if you do not NAT the VPN client of R2 if you do you do not need this

_________________
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
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9162

PostPosted: Fri Jun 07, 2024 14:52    Post subject: Reply with quote
dobrosavke wrote:
We need all users to have same public IP regarding on which site they are in.


This makes no sense. The public IP is immutable wrt any given client otherwise routing between that client and the internet would NOT work.

What's missing here is a clear explanation of what the actual problem is. What you've done is NOT describe the problem, but instead provided the *solution* (one you've already determined is appropriate) and now need to know how to implement it. But that leaves the rest of us scratching our heads as to whether any of this even makes sense (so far, no).

What I *suspect* is you're trying to give the *illusion* (perhaps to the licensing server?) that a given client has a certain public IP (perhaps to insure proper configuration, pass security, etc.). And if that's the case, we need to know that in order to provide appropriate help, which may mean taking a completely different approach.

But as described so far, again, this whole notion of a different public IP for a client that is already bound (immutably) to another public IP makes no sense.

_________________
ddwrt-ovpn-split-basic.sh * ddwrt-ovpn-split-advanced.sh * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh (UPDATED!) * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh
dobrosavke
DD-WRT Novice


Joined: 30 Aug 2011
Posts: 6

PostPosted: Fri Jun 07, 2024 16:41    Post subject: Reply with quote
Hello apologies for not being 100% clear.

Network diagrams attached.

Physical diagram on how is all connected.

Logical diagram with example IPs.

User1 and User2 access licensing machine without issues.

User1 and User2 need to have their Internet routed through VPN server back to Netgear R6220 further on WAN interface on Netgear R6220. So when they check ipchicken.com for example they should get a public IP of ISP directly connected to Netgear R6220.

Client to Client is enabled on VPN server thus 172.16.255.100 can reach 172.16.255.200 directly without additional routing.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9162

PostPosted: Sat Jun 08, 2024 2:05    Post subject: Reply with quote
Well given those diagrams, it seems safe to assume that each router (TP-Link and Netgear) are NOT being routed through the VPN server in the cloud for internet access purposes, but ONLY for the purposes of providing local access between their respective local networks. I mention this because obviously each client of either the TP-Link or Netgear routers would in fact report the same public IP from say ipchicken.com provided they were routed through the VPN server for internet purposes. At least technically this would solve the problem based solely on your narrow description of the problem. But as I indicated before, you really haven't expressed *why* this needs to be the case.

The other (and perhaps better) solution is to run the OpenVPN server on the Netgear side of the configuration and make it the default gateway for the TP-Link side of the configuration. This automatically takes care of the routing issues. The only reason you're in the current predicament is because you have the OpenVPN server configured remotely from the Netgear router. I'm sure you have some rationale for using the cloud rather than the Netgear, but again, it's not clear what that is.

If you insist on using the cloud for the OpenVPN server, then as @egc suggests, you'll have to implement policy based routing on the OpenVPN server and route all internet bound traffic from the TP-Link through the Netgear's tunnel. I suppose it can be done, but it's a bit convoluted, esp. when compared to simply routing those same clients directly through an OpenVPN server on the Netgear.

_________________
ddwrt-ovpn-split-basic.sh * ddwrt-ovpn-split-advanced.sh * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh (UPDATED!) * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh
dobrosavke
DD-WRT Novice


Joined: 30 Aug 2011
Posts: 6

PostPosted: Mon Jun 10, 2024 13:01    Post subject: Reply with quote
Quote
"Well given those diagrams, it seems safe to assume that each router (TP-Link and Netgear) are NOT being routed through the VPN server in the cloud for internet access purposes, but ONLY for the purposes of providing local access between their respective local networks. I mention this because obviously each client of either the TP-Link or Netgear routers would in fact report the same public IP from say ipchicken.com provided they were routed through the VPN server for internet purposes. At least technically this would solve the problem based solely on your narrow description of the problem. But as I indicated before, you really haven't expressed *why* this needs to be the case."

As mentioned in previous post we have 3rd party licensing server sitting in the network.


Quote
"The other (and perhaps better) solution is to run the OpenVPN server on the Netgear side of the configuration and make it the default gateway for the TP-Link side of the configuration. This automatically takes care of the routing issues. The only reason you're in the current predicament is because you have the OpenVPN server configured remotely from the Netgear router. I'm sure you have some rationale for using the cloud rather than the Netgear, but again, it's not clear what that is."

We do not have any kind of port forwarding, DMZ or Public IP optins on Netgear side. That has been mentioned in the 1st post. Please read all the details so you can help me better Very Happy

Quote
"If you insist on using the cloud for the OpenVPN server, then as @egc suggests, you'll have to implement policy based routing on the OpenVPN server and route all internet bound traffic from the TP-Link through the Netgear's tunnel. I suppose it can be done, but it's a bit convoluted, esp. when compared to simply routing those same clients directly through an OpenVPN server on the Netgear."

We have enabled client to client option on OpenVPN server in cloud and routers are reachable through tunnel and site to site connection works. Just need help in enabling NAT rules for incoming traffic on Netgears Tunnel interface. That was all explained in previous posts.


Any other additional assistance please?
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 13041
Location: Netherlands

PostPosted: Mon Jun 10, 2024 15:09    Post subject: Reply with quote
Nat rules are described on page 31 of the Server setup guide.

To give you a head start:

Quote:
Take note, your local LAN clients usually have their own firewall only allowing traffic from their own subnet.
So to connect to a client from another subnet you often have to tweak the local clients firewall, i.e. clients on the servers subnet (192.168.6.0) must allow traffic from the clients subnet (192.168.5.0) and the other way around.
A quick an dirty workaround is to NAT traffic coming out of br0:
On the server:
iptables -t nat -I POSTROUTING -o br0 -s 192.168.5.0/24 -j SNAT --to $(nvram get lan_ipaddr)
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j MASQUERADE

On the client:
iptables -t nat -I POSTROUTING -o br0 -s 192.168.6.0/24 -j SNAT --to $(nvram get lan_ipaddr)


Of course you have to adapt the subnet

_________________
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
dobrosavke
DD-WRT Novice


Joined: 30 Aug 2011
Posts: 6

PostPosted: Tue Jun 11, 2024 9:03    Post subject: Reply with quote
Thank you all for your replies.

None of the answers solved the issue.

Started with TCPdump analysis and figured that packets destined for Internet are not reaching out to Netgear.

That narrowed down the problem to OpenVPN server.
Easiest way to understand the issue is that OpenVPN server creates its own routing table which is processed before OS routing table and that is the place where I have to enter default route.

Default route in OpenVPN table has been configured by adding iroute command in Netgear configuration file and that solved all issues with routing and NAT.

Resolved.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 13041
Location: Netherlands

PostPosted: Tue Jun 11, 2024 9:27    Post subject: Reply with quote
I already pointed that out in my first post and also where you could find the instructions Sad

egc wrote:
I think you need routes to the LAN subnet of the clients from the OpenVPN server side.

For that you have to setup a site-to-site setup with route, iroute and ccd files.

See the OpenVPN Server setup guide, OpenVPN guides are a sticky in this forum.


_________________
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
guru431
DD-WRT Novice


Joined: 14 Jun 2024
Posts: 2

PostPosted: Fri Jun 14, 2024 7:30    Post subject: Reply with quote
I have the same problem.

I found the cause - it's all about OpenVPN internal routing through the TUN interface.

Read more here:
https://forums-new.openvpn.net/forum/openvpn-community-versions/routing-and-firewall/103-openvpn-iroute-iproute2-policy-based-routing-and-gateways-on-different-subnets
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 13041
Location: Netherlands

PostPosted: Fri Jun 14, 2024 10:26    Post subject: Reply with quote
and what is the relation with DDWRT?
_________________
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
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum