OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue
-
@r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
I can confirm PFSense is the default gateway
So why do you think then, the server has no route back to the client? If pfSense is the default gateway he will send responses to pfSense and this node knows what to do with the packets, since the client is in the same subnet.
@r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
The OpenVPN settings should be in images on first post ('OpenVPN server.png', 'Client_override2.png')
I sadly can't see any.
@r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
I have made sure on the client firewall that ICMP will respond to pings from the server network.
Did you try a ping from Diagnostic > Ping. Try a ping with the default options and another after changing the source to LAN.
-
@viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
@r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
I can confirm PFSense is the default gateway
So why do you think then, the server has no route back to the client? If pfSense is the default gateway he will send responses to pfSense and this node knows what to do with the packets, since the client is in the same subnet.
Only because I cannot ping the client from pfsense from the LAN net the server is on, I can only ping from default / 'OpenVPN server'.
@viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
I sadly can't see any.
There were URLs at the bottom of the post; I've re-uploaded below
CheersClient_override2.png
OpenVPN FW rules.png
OpenVPN server.png -
So the client doesn't respond if the ping is coming from the servers LAN (unkown network).
Possible reason for this may be that the client blocks the access, which is the default behavior on most desktop systems, or that the client has no route to the remote LAN.Did you check the clients routes?
For the first point if its a Windows client a do a trick to get its trust: I push the default route to it. Windows trust networks which provides a default gateway. However, since I don't want to direct all the clients upstream traffic over the vpn, I push the routes with a low metric.
To do so I have this in the custom options:push "route-metric 512";push "route 0.0.0.0 0.0.0.0"With that I usually can access Windows clients on services that are open in a trusted network like ping or file shares.
-
On the windows client I have tried the following:
Add remote networks into the scope
@viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
To do so I have this in the custom options:
push "route-metric 512";push "route 0.0.0.0 0.0.0.0"With that I usually can access Windows clients on services that are open in a trusted network like ping or file shares.
I have also added the custom option as above, however this doesn't seem to make any difference.
I believe the client routes are correct, as I can ping devices on the remote lan, or access an SMB share from a server etc.
-
Okay, then the routes should be added correctly.
I'd never trust a Windows firewall. You think you open something and it blocks the access anyway. You may try to disable the firewall for testing.
On pfSense you can easily check, what's going on with Diagnostic > Packet Capture. Select the OpenVPN interface and start the capture and try to access the server.
After stopping you see the result. Check if the packets from the server go into the tunnel and if the client responds. -
Okay I have now checked using packet capture;
When I ping from the VPN client > server, I can see traffic with the server response.
When I ping the VPN client from the server, there are no replies logged in the capture.
Windows firewall is completely disabled at this point.
-
So obviously the client does not respond. Never trust a Windows firewall even if it's disabled.
No idea at this point.However, you can do a workaround with NAT to translate the packets from the server:
Firewall > NAT > Outbound
Set the hybrid mode and save it, so that you can add individual rules.
Add a rule:
interface: OpenVPN
source: <servers IP, LAN network or any, what you want>
dest: <OpenVPNtunnel subnet or any>
translation interface: addressThis translates packets into the the OpenVPN server virtual address. Since this is within the same subnet as the client, you should get responses.
-
UPDATE
As usual, it was a PEBKAC, of course the local LAN on the VPN client was listed as a 'Private network' but the OpenVPN adapter was listed as 'Public network' so any rules/disabling firewall was only affecting traffic on the local, 'Private' LAN.
Apologies!
-
As far as I remember, it's only possible to set the VPN as private network when there is an default gateway by pushing the default route:
@viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:
push "route-metric 512";push "route 0.0.0.0 0.0.0.0"
However, that this has to be done manually I didn't remember anymore.
-
@viragomann Thanks for the help, making sure firewall rules also apply to 'Public' has resolved my issues.
Reuben
