Cannot reach clients in the lan network, only the internal LAN IP
-
Ensure that you have a firewall rule in place on OpenVPN interface that allows the access to your LAN. Also check that the access isn't blocked by the destination hosts SW-firewall. Windows, for instance, blocks access from other subnets by default.
-
Thanks,
I will check as soon as I am again able to connect to web GUI, meanwhile, should I have a pass firewall rule that has as a source the tunnel network and destination the LAN one?Thanks
Fabio D'Alfonso -
Yes, at least for testing open any protocol and port, perhaps you may restrict it later.
-
Hi,
the rule was already in place, in the OpenVPN tab on firewall rules and is * * **, so traffic should not be blocked.Some other thing to check?
Thanks in Advance
Fabio D'Alfonso -
It should work with this config.
Please use the packet capture tool from the Diagnostic menu for analysing. Enter the LAN hosts address in the appropriate box and take a capture while pinging the LAN host once at OpenVPN interface and a second one at LAN and post the outputs.
-
-
Hi,
the rule was already in place, in the OpenVPN tab on firewall rules and is * * **, so traffic should not be blocked.Some other thing to check?
Thanks in Advance
Fabio D'AlfonsoPlease verify the connection from the traffic logs?
-
Yes,
I can ping the LAN IP of pfSense from the VPN connected client, but I cannot reach other LAN hosts, that is the point.So currently the connection is useless, we would need to get access to LAN side connected clients/servers to access shared folders and remote desktop, currently we cannot ping anything other than the LAN IP of pfSense
Thanks in Advance
Fabio D'AlfonsoFabio, did you ever get this sorted? I've got the same issue - created a standard/generic OpenVPN TUN connection via the wizard, exported, tested w/ OSX and Windows, can ping/ssh/web to the PFSense LAN IP, can't touch anything else.
-
And what are you trying to access on the lan? As Derelict mentioned a few days back, is the device your trying to talk to on the lan running a firewall. Out of the box for example windows firewall will not allow you to access anything because your tun network IP is going to be different than its local lan network.
-
And what are you trying to access on the lan? As Derelict mentioned a few days back, is the device your trying to talk to on the lan running a firewall. Out of the box for example windows firewall will not allow you to access anything because your tun network IP is going to be different than its local lan network.
(I'll be happy to split this off to a separate thread if needed)
Many of the devices I'm attempting to connect to don't have a firewall - switch, wireless AP, printers, etc, just attempting ICMP/ssh/https…
Perhaps I'm attempting something non-standard or not quite understanding the routing assumptions: Internal LAN is a /16, so something like 10.123.0.0/16, default (LAN) DHCP pool is 10.123.100.0/24 (which can talk to everything else, say, 10.123.1.x just fine), and the OpenVPN pool is 10.123.200.0/24. Once I'm properly off-site where I can test I'll re-check the VPN clients are getting the default gateway.For current needs (just two IT admins) I might also try a TAP.
-
Do those devices have their default gateway set to the pfSense device that is terminating the OpenVPN connections? Do your APs even have the capability of setting a default gateway on LAN?
-
Internal LAN is a /16, so something like 10.123.0.0/16, default (LAN) DHCP pool is 10.123.100.0/24 (which can talk to everything else, say, 10.123.1.x just fine), and the OpenVPN pool is 10.123.200.0/24. Once I'm properly off-site where I can test I'll re-check the VPN clients are getting the default gateway.
Yeah you need to set your OpenVPN pool/tunnel network to something OUTSIDE your LAN subnet to have any prayer of being able to route to it. Or, more accurately, to have a prayer of anything on LAN being able to route back.
-
Internal LAN is a /16, so something like 10.123.0.0/16, default (LAN) DHCP pool is 10.123.100.0/24 (which can talk to everything else, say, 10.123.1.x just fine), and the OpenVPN pool is 10.123.200.0/24. Once I'm properly off-site where I can test I'll re-check the VPN clients are getting the default gateway.
Yeah you need to set your OpenVPN pool/tunnel network to something OUTSIDE your LAN subnet to have any prayer of being able to route to it. Or, more accurately, to have a prayer of anything on LAN being able to route back.
Right, that seems rather obvious now. (I guess I was thinking along the lines of Layer 2, not routing through different networks.) Okay, set OpenVPN server tunnel network to a separate subnet (10.12.34.0/24), I connect, get the first open IP (10.12.34.2) assigned. However I now can see I don't get a default gateway assigned.
The only real mention I can find in the pfSense Book is under troubleshooting (20.19.3), but doesn't explain where that is defined.
Verified Outbound NAT is auto, and that VPN subnet is in the rules.
-
Default gateway on what where?
If you want your VPN clients to route all traffic to OpenVPN, use the Redirect Gateway option on the server.
If you don't, I don't know what you're talking about. Put 10.123.0.0/16 in the Local Networks on the server and the client will route traffic to that over the tunnel.
Verified Outbound NAT is auto, and that VPN subnet is in the rules.
VPN subnet is in what rules where? Are you still talking about VPN clients accessing the 10.123.0.0/16 network or are you moving on to them accessing the internet over the tunnel?
-
Internal LAN is a /16, so something like 10.123.0.0/16, default (LAN) DHCP pool is 10.123.100.0/24 (which can talk to everything else, say, 10.123.1.x just fine), and the OpenVPN pool is 10.123.200.0/24. Once I'm properly off-site where I can test I'll re-check the VPN clients are getting the default gateway.
Yeah you need to set your OpenVPN pool/tunnel network to something OUTSIDE your LAN subnet to have any prayer of being able to route to it. Or, more accurately, to have a prayer of anything on LAN being able to route back.
(Sorry for the delay in replying.) That was the key, once I changed the OpenVPN pool to not be a sub-set of the LAN, all is well. There was a bit of a red herring in testing as the main target I was using is an L3 switch that (understandably) doesn't allow management traffic from a different subnet.
Thanks again, and next time I have a question I'll try and get second set of eyes sanity check first.
