What's new

Redirecting OpenVPN Client Connections to 2nd OpenVPN Router Connection

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Terrabytes

Occasional Visitor
I have two RT-AX86 (RouterA & RouterB) running Merlin. RouterA is running OpenVPN server and RouterB is connected as OpenVPN client. RouterB also has OpenVPN server running. I would like for OpenVPN clients that connect to RouterB to be able to access resources on RouterA - SubnetA.

Subnets
  • RouterA - SubnetA - 192.168.10.0/24 | OpenVPN subnet 10.10.0.0/24
  • RouterB - SubnetB - 192.168.20.0/24 | OpenVPN subnet 10.20.0.0/24
Facts
  • RouterB and systems on SubnetB can reach RouterA and systems on SubnetA
  • OpenVPN clients connecting to RouterB can reach RouterB and systems on SubnetB
  • RouterA and RouterB have unique certs created for each
  • OpenVPN clients have unique certs for RouterA and RouterB
I believe that I need to setup routes to direct OpenVPN clients (10.20.0.x) on RouterB to redirect request to SubnetA (192.168.10.0/24). Please advise if I missed any details. Would someone please be able to assist. Your assistance is greatly appreciated. Thanks
 
What's NOT clear is how RouterA is configured wrt RouterB when it comes to the VPN. Is this a site-to-site configuration (i.e., bi-directional access, where each side can initiate connections to the other)? In such a configuration, the OpenVPN server on RouterA would be using the Manage Client-Specific Options section to inform it of the 192.168.20.0/24 network behind the OpenVPN client on RouterB. And the tunnel would NOT be NAT'd. If it's NOT site-to-site, then presumably you've NAT'd the tunnel on the OpenVPN client of RouterA.

It matters because it changes slightly how you handle the traffic from 10.20.0.0/24 that's destined to 192.168.10.0/24 over the tunnel. If it's site-to-site, you would add 10.20.0.0/24 to the Manage Client-Specific Options section on the OpenVPN server of RouterA. If it's NOT site-to-site, then you can rely on the fact that the tunnel is NAT'd.

You would also need to add the following directive to the custom config field of the OpenVPN server on RouterB.

Code:
push "route 192.168.10.0 255.255.255.0"

And assuming you do NOT have Both specified for the "Client will use VPN to access" option on the OpenVPN server, add the following firewall rule on RouterB (using a firewall-start script).

Code:
iptables -I FORWARD -i tun2+ -d 192.168.10.0/24 -j ACCEPT

In short, how precisely you have these OpenVPN servers configured makes a difference.
 
Appreciate your reply I have read enough threads here to know that you are extremely knowledgeable on this topic. You have forgotten more things about Networking than I might ever know.

Your posting made me think if I needed bi-directional vs uni-directional connections. At first I thought I could get away with with uni-directional but after reflecting on it I believe I need to set it up as bi-directional (which it is currently not). The long term plan is a hub and spoke model. Primary router with connections from 2 or 3 other routers. Primary should have bi-directional connections with other routers only. OpenVPN clients with connections to other routers should be able to reach resources on primary router subnet.

I like breaking things down in increments.
  1. Get bi-directional connection working between RouterA and RouterB
  2. Get OpenVPN clients on RouterB access to resources on RouterA subnet
  3. Get bi-directional connection working between RouterA and RouterC
I would appreciate your help with 1 and possibly 2 and I hope I can resolve 3 and beyond on my own. See current configs below. Does it matter if it is TCP vs UDP?

Again your help is appreciated.
 

Attachments

  • RouterA-OpenVPN.png
    RouterA-OpenVPN.png
    105.8 KB · Views: 85
  • RouterB-Client.png
    RouterB-Client.png
    78.1 KB · Views: 83
As I said, for bidirectional (site-to-site) access, you would typically NOT NAT the tunnel on the OpenVPN client side, and would instead configure Manage Client-Specific Options on the OpenVPN server side to minimally identify the IP network of the OpenVPN client to the server (192.168.2.0/24). Since you also want the IP network of the OpenVPN server on RouterB to be known to the OpenVPN server of RouterA (10.20.0.0/24), you would include it as well. Which protocol you use (TCP or UDP) has no bearing on any of this.
 
Thank you good sir. More importantly for providing the explanation. Now I am better able to understand what is going on in the back end. Still allot to learn but little by little.
  1. Successful - Get bi-directional connection working between RouterA and RouterB
  2. Successful - Get OpenVPN clients on RouterB access to resources on RouterA subnet
  3. Pending - Get bi-directional connection working between RouterA and RouterC
I realize now that I need to create another OpenVPN server on RouterA just for site to site connections. The existing OpenVPN server on RouterA will be used for individual OpenVPN clients that I don't want to manage via common name. Is that a sound solution or would you advise otherwise?

PS For others reading this thread complete all configuration on primary router first and others after. Was making configuration changes on both at the same time and had issues. Disabling OpenVPN server and client service and re-enabling them in the correct order resolved the issue.
 
I realize now that I need to create another OpenVPN server on RouterA just for site to site connections. The existing OpenVPN server on RouterA will be used for individual OpenVPN clients that I don't want to manage via common name. Is that a sound solution or would you advise otherwise?

I suppose you could get away w/ a single OpenVPN server on RouterA if you were willing to NAT the tunnel. As I said, normally w/ a site-to-site configuration, you do NOT NAT the tunnel because each OpenVPN client and its particular private IP network is known to the server via Manage Client-Specific Options. But if you wanted to also support OpenVPN clients w/ an unknown private IP network and only used for unidirectional access, having the tunnel NAT'd would server both types of users. It's just not ideal for the site-to-site users.
 
From a resource perspective one OpenVPN sounds like a good solution.
  • OpenVPN clients to RouterA only need unidirectional access
    • NAT the tunnel via the client configurations?
  • Can you elaborate on "not ideal for the site-to-site users"
 
In a site-to-site configuration, each side of the tunnel is fully aware of the IP network(s) that lie on the other side. That's the whole point. Connections can be initiated from either side of the tunnel to a known private IP address. Therefore, NAT is unnecessary.

Contrast that situation to being connected to your favorite OpenVPN provider (e.g., ExpressVPN). Neither you nor the VPN provider have any clue about the private IP network(s) that lie on either side of the tunnel. All you each share in common is the IP network of the tunnel (e.g., 10.8.0.0/24). Therefore, you *MUST* NAT the tunnel w/ the assigned IP on that tunnel in order for the server to route reply packets back to the OpenVPN client, at least for those devices that are behind the OpenVPN client on the local network and using the tunnel.

All that said, it is possible to support both types of OpenVPN clients on the same server, but you're forced to NAT the tunnel for the benefit of those NOT using site-to-site. It's a disadvantage to site-to-site clients because the server can no longer *filter* those clients based on their assigned IP on the remote IP network! IOW, devices on RouterB (192.168.20.x) accessing devices on Router A (192.168.10.x) over the tunnel all appear to be coming from 10.10.0.x (the client's assigned IP on the tunnel) rather than 192.168.20.x! Of course, if you have no need or concern for such filtering, perhaps it doesn't matter. But if you do, then it's a disadvantage to be NAT'ing the tunnel.

As they say, the devil is in the details. Only YOU know exactly what your needs are. I'm just explaining the options, but without much knowledge of which would be best given your needs.
 
Thank you for providing further explanation and knowledge. I wanted to reflect on this overnight. I have concluded that client filtering to access resources (computer, NAS, printers, etc) on other site subnets is needed. So in my particular case an additional OpenVPN server (RouterA) is a better fit.

Additionally if I wanted OpenVPN clients on RouterA access to other site subnets. I would think you could use iptables but my knowledge is limited. What would you advise? Thanks again
 
Follow up question I realized that I have to enable on the OpenVPN server

Client will use VPN to access setting to Both [LAN and Internet]

Otherwise the client won't be able to reach the internet. Thought it was DNS related so disabled on OpenVPN Server

Advertise DNS to clients - No

But that didn't resolve the issue. Tried googling but got no firm answer. Can you please point me in the right direction. Just looking to get routing for internal subnets everything else should be done through the clients. Thanks
 
Follow up question I realized that I have to enable on the OpenVPN server

Client will use VPN to access setting to Both [LAN and Internet]

Otherwise the client won't be able to reach the internet. Thought it was DNS related so disabled on OpenVPN Server

Advertise DNS to clients - No

But that didn't resolve the issue. Tried googling but got no firm answer. Can you please point me in the right direction. Just looking to get routing for internal subnets everything else should be done through the clients. Thanks

I assume were talking about the OpenVPN server on routerB here.

The options LAN only and Both work as follows.

If you specify LAN only, the router automatically pushes the default local IP network to the client, as well as installs the following firewall rule (I'm assuming server #1).

Code:
Chain OVPN (2 references)
pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            192.168.20.0/24

However, if you specify Both, the router installs the following firewall rule, which is NON specific as to destination.

Code:
Chain OVPN (2 references)
pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0

In addition, the router adds the following directive to force clients to access the internet through the OpenVPN server.

Code:
push "redirect-gateway def1"

That's why Both works when you have multiple local IP networks, but at the expense of having the internet accessed through the OpenVPN server. There is no option to force *multiple* local IP networks through the tunnel while excluding internet access.

So you have two ways to solve the problem. Either you specify LAN only and *manually* push those additional IP networks via the custom config field of the OpenVPN server ...

Code:
push "route 192.168.10.0 255.255.255.0"

... along w/ an appropriate firewall rule (installed using a firewall-start script) ...

Code:
iptables -I FORWARD -i tun21 -d 192.168.10.0/24 -j ACCEPT

... OR, specify Both, but configure the OpenVPN clients to reject the redirect-gateway directive in their config file.

Code:
pull-filter ignore "redirect-gateway"

The latter approach is clearly easier to implement, but it's a bit schizophrenic in that you add a directive, only to reject it at the same time. But it will work. The former approach is probably better in the terms of doing things "properly".

As far as the Advertise DNS to clients option, that has no bearing here. If you want those OpenVPN clients to be able to resolve local hostnames, then you should enable that option. That's the only purpose it serves.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top