Solved issue accessing a LAN device thru OpenVPN Server connected device

[GSpock]

Hi all,
See below:

So, when I am connected on my second router via its OpenVPN Server, I cannot browse/access my device located in the subnet of my main router (192.168.1.x). Access to any device connected to my second router (192.168.98.x) is OK.
What am I missing in order for this to work ?
thanks,
GS

 

[eibgrad]

I assume you want site-to-site access (i.e., access in either direction). You have to configure the Manage Client-Specific Options section of the OpenVPN server and add the network (s) located behind the OpenVPN client, and identify that specific OpenVPN client based on its CN (Common Name) on its client cert (note, you do NOT need to push these routes).

 

[GSpock]

I assume you want site-to-site access (i.e., access in either direction). You have to configure the Manage Client-Specific Options section of the OpenVPN server and add the network (s) located behind the OpenVPN client, and identify that specific OpenVPN client based on its CN (Common Name) on its client cert (note, you do NOT need to push these routes).

Thanks for your answer, I need now to try to understand it ... and how to practically implement this.

I guess the first thing is a to add a "route 192.168.98.0/24 255.255.255.0" and/or "192.168.1.0/24 255.255.255.0" in the custom config .... for the CN I must admit at this point in time I do not get it.
Rgds,
GS

 

[eibgrad]

Thanks for your answer, I need now to try to understand it ... and how to practically implement this.

I guess the first thing is a to add a "route 192.168.98.0/24 255.255.255.0" and/or "192.168.1.0/24 255.255.255.0" in the custom config .... for the CN I must admit at this point in time I do not get it.
Rgds,
GS

NO!

The Manage Client-Specific Options section takes care of all the actual adding of routes, automatically. You just have to tell it what network(s) lie behind the OpenVPN client. But since there can be *multiple* OpenVPN clients connecting to that server, it needs to know to which of those OpenVPN clients those particular networks are applicable. And you tell the OpenVPN server that information by including the client's CN (Common Name) on its cert. That creates the correlation between those networks and that specific OpenVPN client.

All that said, this *assumes* each OpenVPN client has been assigned a unique client cert, w/ a unique CN. If that's NOT the case (i.e., they're all using the same client cert), but you happen to be using username/password as well, then you can add the following directives to the custom config field of the OpenVPN server and use the username instead of the CN.

duplicate-cn
username-as-common-name

I know it can be a bit confusing. But you just have to realize that given the ability for the OpenVPN server to support multiple OpenVPN clients, it needs a means to know which network(s) are to be associated w/ each OpenVPN client. And that's either using the CN, or if they all share the same CN, then the username.

 

[eibgrad]

P.S. Although you didn't specifically mention it, if the OpenVPN client is running Merlin, make sure the Inbound Firewall option is set to *Allow*. By default this is set to "Block", which prevents site-to-site communications (for security reasons). All the other comments I made still apply, but this is another one to consider as well.

Other firmware may have a similar option.

 

[GSpock]

P.S. Although you didn't specifically mention it, if the OpenVPN client is running Merlin, make sure the Inbound Firewall option is set to *Allow*. By default this is set to "Block", which prevents site-to-site communications (for security reasons). All the other comments I made still apply, but this is another one to consider as well.

Other firmware may have a similar option.

... There you lost me ... The client that is connecting to the OpenVPN Server is a windows machine !!! the option you talk about "inbound firewall" is on the OpenVPN Client on the router !!!.

Refering to your previous post, is this what you mean ?

 

[eibgrad]

Ok, I now realize I misunderstood your original post and diagram. For some reason I thought this was a site-to-site config, but I now realize this is just an OpenVPN server that's behind the primary router, and you're trying to reach the primary router's IP network over the VPN.

My bad, let's start over and pretend I never said anything.

In order to reach the primary router's IP network, you have to set the "Client will use VPN to access" option on the OpenVPN server to Both to allow access over its WAN to that other network. Also, you need to push that other network to the OpenVPN client so it knows it resides over the VPN, by adding a route directive to the custom config field of the OpenVPN server.

push "route 192.168.1.0 255.255.255.0"

Just beware, this will only work if the OpenVPN client itself is NOT using the same network (192.168.1.0/24), or else it will never route to 192.168.1.0/24 over the VPN. Each side has to be using different IP networks. I only mention it because 192.168.1.0/24 is so common.

 

[GSpock]

.. no problem, I really appreciate your help and BTW it is rather my bad than yours. I shoud have specified in the drawing that devices were Windows machines.

The push route made the job dispite the client access set to LAN only

Again, @eibgrad many thanks for your help,
GS

 

[Jeffrey Young]

@eibgrad, your instructions here, either way, are some of the best - simplest - instructions I and seen yet on this topic.

Many thanks. I never did get a OpenVPN site to site to work properly in Merlin. I ended up using a WireGuard Server on a RasPi to setup a Site to Site.

Nice job, my friend.

 

[eibgrad]

.. no problem, I really appreciate your help and BTW it is rather my bad than yours. I shoud have specified in the drawing that devices were Windows machines.

The push route made the job dispite the client access set to LAN only

View attachment 32112

Again, @eibgrad many thanks for your help,
GS

Glad it's working.

Perhaps it doesn't matter at this point, but I still can't understand how it could have worked w/ LAN Only given the following dump of iptables w/ each setting.

LAN Only:

admin@merlin-lab1:/tmp/etc/openvpn/server1# iptables -vnL OVPN
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.98.0/24

Internet Only:

admin@merlin-lab1:/tmp/etc/openvpn/server1# iptables -vnL OVPN
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.98.0/24

Both:

admin@merlin-lab1:/tmp/etc/openvpn/server1# iptables -vnL OVPN
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

LAN Only is specifically allowing the local network on which the OpenVPN server is running (192.168.98.0/24). Presumably all other destinations are denied (or else what's the point of the option). The call to the OVPN chain in the FORWARD chain is immediately followed by a DROP, confirming this presumption.

    0     0 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

So how in the world could 192.168.1.0/24 be accessible without using Both (or Internet Only, but would deny access to 192.168.98.0/24 in the process)?

Weird. It's like there's something else in the firewall that's letting that 192.168.1.0/24 network through.

In the end, if it works it works, but stuff like this triggers my OCD.

 

[Maverickcdn]

So how in the world could 192.168.1.0/24 be accessible without using Both (or Internet Only, but would deny access to 192.168.98.0/24 in the process)?

Weird. It's like there's something else in the firewall that's letting that 192.168.1.0/24 network through.

In the end, if it works it works, but stuff like this triggers my OCD.

Out of my realm, but would it have anything to do with the OP running cascaded routers and having static routes and the firewall is disabled on router 2?

I dont know the affect of firewall enabled/disabled on VPN generated rules.

 

[eibgrad]

Out of my realm, but would it have anything to do with the OP running cascaded routers and having static routes and the firewall is disabled on router 2?

I dont know the affect of firewall enabled/disabled on VPN generated rules.

Can't see how static routes would matter, since that only involves routing. But yeah, as I said, there has to be some other reason the firewall is letting this through, and obviously disabling it would be the topper of all reasons. But the OP never mentioned it.

 

[Maverickcdn]

Can't see how static routes would matter, since that only involves routing. But yeah, as I said, there has to be some other reason the firewall is letting this through, and obviously disabling it would be the topper of all reasons. But the OP never mentioned it.

Ya there was another thread with the OP regarding setting up static routes and it was advised to disable the firewall downstream, I knew it was relevant but wasnt sure if disabling the firewall on router 2 actually had an affect on the VPN rule generation in this scenario. I've got a touch of OCD too so thought Id chime in and help quell it for you if in fact that was it

 

[eibgrad]

Ya there was another thread with the OP regarding setting up static routes and it was advised to disable the firewall downstream, I knew it was relevant but wasnt sure if disabling the firewall on router 2 actually had an affect on the VPN rule generation in this scenario. I've got a touch of OCD too so thought Id chime in and help quell it for you if in fact that was it

Besides my own OCD, my concern is two-fold; 1) not leading others to believe that LAN Only would normally work (it' won't), and 2) the remote possibility of a bug. But as you know w/ these routers, there's often a lot of other things going on the OP doesn't always make known (just consider the plethora of third-party scripts), and you can therefore end up w/ things not working quite as expected. Sometimes it's benign, other times it might indicate more serious issues you're not even aware of. It's just NOT my nature to say "eh, it worked, so why bother asking questions".

 

[GSpock]

Besides my own OCD, my concern is two-fold; 1) not leading others to believe that LAN Only would normally work (it' won't), and 2) the remote possibility of a bug. But as you know w/ these routers, there's often a lot of other things going on the OP doesn't always make known (just consider the plethora of third-party scripts), and you can therefore end up w/ things not working quite as expected. Sometimes it's benign, other times it might indicate more serious issues you're not even aware of. It's just NOT my nature to say "eh, it worked, so why bother asking questions".

... wow, I am struggling to follow the recents posts.

I confirm that on my second router, the firewall is OFF (otherwise 1.x devices cannot access 98.x devices) but nat is ON (otherwise devices on 98.x network do not have access to internet). I can show here any output of iptables of both routers or anything else if it helps. just tell me what you want to see ... not being a native english, I must say it is an additional difficulty to follow you guys, anyway many thanks for your time. (and I agree with you about "eh, it worked, so why bother asking questions")
Thx,
GS

 

[GSpock]

So how in the world could 192.168.1.0/24 be accessible without using Both (or Internet Only, but would deny access to 192.168.98.0/24 in the process)?

could it be possible that the one below (on main server) is generated thanks to the static routes definition ?

-A FORWARD -s 192.168.1.0/24 -d 192.168.98.0/24 -i br0 -o br0 -j ACCEPT
​

EDIT:
I think I found it: in nat-start script on second router, there is this one:
iptables -I INPUT -s 192.168.1.0/24 -j ACCEPT

to be honest, I do not remember why it was there initialy ... , now I know it is required and why !

 

[GSpock]

... the objective of all this set-up is to provide an on-demand OpenVPN Server via a second router connected to an AC/DC homePlug that can be switched on/off remotely. BTW this was @eibgrad suggestion I saw in another threat.
So, the first thing was to have that second router working correctly (and that was not so easy for me with my skills (or rather my lack of ) and indeed there was another thread for this, as mentioned by @Maverickcdn where it was said firewall should be off on second router.

So, for the time being, it works as intended but I am fine to continue looking around if some parameters should be adapted.


To be complete, and may be add a bit of complexity .... there is one thing that does not work as I would like, but it is NOT related to OpenVPN Server: when connected to device say 1.13, I can RDP to 98.32 but I cannot, via a file explorer, access files on 98.64. But I can live with this.

Rgds,
GS

 

[eibgrad]

I confirm that on my second router, the firewall is OFF (otherwise 1.x devices cannot access 98.x devices) but nat is ON (otherwise devices on 98.x network do not have access to internet).

If the firewall is OFF, that pretty much explains it.

... the objective of all this set-up is to provide an on-demand OpenVPN Server via a second router connected to an AC/DC homePlug that can be switched on/off remotely. BTW this was @eibgrad suggestion I saw in another threat.

You've now peaked my interest even further.

I hadn't even realized until you mentioned it, that this config was your attempt to implement my suggestion about placing the OpenVPN server on its own device. Had I known, I probably wouldn't have made my initial error in assessing your problems.

So obviously you've configured the VPN server using a routed config (WAN to LAN wrt the primary router), hence why you need access upstream over its WAN to the 192.168.1.0/24 network.

While that will work, it would have been preferable to configure the secondary router as a bridge (e.g., AP mode, LAN to LAN), so it's LAN remains within the scope of the private network. Then the issues in this thread wouldn't have ever been raised. Not unless you've now decided to take advantage of the fact you have a secondary local network. But in general, that's best avoided since it can lead to its own problems (some of which you're now dealing with).

All that said, I don't know if perhaps Merlin only binds the VPN to the WAN. If that's the case, then obviously you have to use a routed configuration. But in my own case, I'm using FT (FreshTomato), and it has no such restriction. It's connected LAN to LAN wrt my private network. It just keeps things simpler. But if you must use a routed config, I personally would have limited the purpose of that VPN router to *only* providing access to the primary router's network (192.168.1.0/24) and nothing else. But that decision is up to you.

 

[GSpock]

While that will work, it would have been preferable to configure the secondary router as a bridge (e.g., AP mode, LAN to LAN), so it's LAN remains within the scope of the private network. Then the issues in this thread wouldn't have ever been raised. Not unless you've now decided to take advantage of the fact you have a secondary local network. But in general, that's best avoided since it can lead to its own problems (some of which you're now dealing with).

I do not think so because when you set the ASUS router in AP mode, you do not have access anymore to the OpenVPN Server gui screen ...