OpenVPN Server - route back to client

[mekabe remain]

I am running OpenVPN server on my Asus RT-AX88U
On another location I have a Keenetic router which has OpenVPN client.
The client connects to VPN server on AX88U
I tried both with TAP and TUN configuration.
But I want to be able to access clients behind the Keenetic router.
So I need to route back subnet 192.168.1.0/24 (which is the LAN of the Keenetic router) back to the VPN client on Asus router.

How can I route back a subnet to a vpn client ?

Also which type of VPN (TAP/TUN) is suitable for this operation ?

thanks

 

[eibgrad]

You route from the OpenVPN server and back to the LAN behind the OpenVPN client by configuring the Manage Client-Specific Options section of the OpenVPN server. It's there you define the subnet(s) available behind the OpenVPN client based on the CN (Common Name) in the OpenVPN client's cert (iirc, named "client" if using the built-in certs and keys of the ASUS router).

As far as tun (routed) vs tap (bridged) tunnels, 99% of the time you use the former, since having two different IP networks between the two sides is typical. The latter usually only makes sense when both sides are using the same IP network *and* are logically part of the same enterprise. For example, a company that has two offices on either side of the street would typically use a bridged tunnel since the fact they are physically separated is merely due to happenstance (e.g., they didn't have enough room within the one building).

The one exception I can imagine for the home user using a bridged tunnel is when the OpenVPN client is the *only* device acting as the client. IOW, it's NOT acting as a gateway for other devices behind it. That would allow the OpenVPN client to participate in the remote LAN as a *full* member, just as if it had been plugged into the switch of the remote network, w/ all the same privileges, access to network discovery, no firewall, etc. A very powerful configuration, but also potentially dangerous if such access should fall into the wrong hands.

Note: With a bridged tunnel, you do NOT need to configure Manage Client-Specific Options since that only applies to routed configurations.

 

[mekabe remain]

thank you.
I just tried this now.
I selected "yes" for "Allow Client <-> Client"
And even I added a line to allow "client":

CN: client
Subnet: 192.168.1.0
Netmask: 255.255.255.0
Push: No (Btw, what is this ?)

But I do not see any route to 192.168.1.0/24 added on my AX88U when the "client" is connected.
I checked from command line (route -na) and also on VPN status , routes section.
No route is added ?

 

[eibgrad]

The Push option is not applicable in your case. That's intended for situations where you have *multiple* OpenVPN clients connect to the same server, and you wish to use the server as a gateway between the private IP networks behind each client. The OpenVPN server will only push that network to other connected OpenVPN clients if you enable it (it's smart enough to NOT push it to the OpenVPN client that's supporting that IP network).

The Allow Client-to-Client option isn't relevant either. It only applies to the above situation. IOW, by default, the server will NOT allow communications between OpenVPN clients. You have to enable it explicitly.

Make sure you actually added the route in Manage Client-Specific Options by hitting the +s sign! It's all too easy to configure it, NOT hit +, then apply, and have it do nothing!

 

[mekabe remain]

I found the issue. On my Keenetic router , the firewall denies incoming packets from VPN tunnel by default.
When I added rules for icmp, tcp and udp I am able to reach both ways.

Thank you

 

[mekabe remain]

btw, in my case, I tried the push option and Asus router pushed the 192.168.1.0 subnet to the Keenetic client which is in fact using that subnet. Then Keenetic became unstable and I had to disconnect it from uplink , restart and then turn off vpn.
Then I removed the push option
I don't know why Asus router pushed it back to the client.

 

[eibgrad]

I don't know why Asus router pushed it back to the client.

I don't either. Then again, knowing how it works, and its purpose, I always keep it set to No anyway. As I said, it's only relevant when using Allow Client-to-Client. For all I know it's an undiscovered bug. It's NOT likely there are may users using the server for such purposes anyway, so it could easily go unnoticed.

 

[mekabe remain]

ok. thanks for all your help.