Cannot reach clients in the lan network, only the internal LAN IP



  • Hi all,
    I am probably missing something-

    The connection starts up, correctly, and I can ping the internal IP of the fpsense. The vpn is setup to IPv4 Local network(s) 10.125.0.0/16 and the tunnel on its 10.x.x.x

    I have a NAT for udp 1194 wan to LAN pfsense address, but I am not sure if I should have a NAT for any other internal client, or the setup in the VPN shpuld take care of forwarding to the lan defined in the IPv4 Local network(s) 10.125.0.0/16 for all IPs

    Thanks in advance
    Fabio D'Alfonso



  • I guess the pfSense running the OpenVPN server isn't the default gateway at your LAN hosts.

    If it isn't, you will have to add routes for the VPN subnet to your hosts or do NAT on pfSense to translate VPN packets to the pfSense LAN address.



  • Thanks,
    the client on the lan is using the LAN ip of pfsense as defaul gateway.

    Did you mean that? If yes the first answer is: it is using it.

    So should I be able to get access to the client?

    Also I see a linked firewall rule referring to LAN pfsense ip address not * for OpenVPN and port 1194 , so could it be that?

    Thanks in Advance
    Fabio D'Alfonso



  • You wrote above, you can ping the internal IP of pfSense. Do you mean the LAN IP? But you can't reach other LAN hosts?



  • 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'Alfonso



  • 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.


  • Netgate

    @fabio_dalfonso:

    Some other thing to check?

    Windows firewall on the target host.



  • @fabio_dalfonso:

    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

    Please verify the connection from the traffic logs?



  • @fabio_dalfonso:

    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'Alfonso

    Fabio, 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.


  • Rebel Alliance Global Moderator

    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.



  • @johnpoz:

    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.


  • Netgate

    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?


  • Netgate

    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.



  • @Derelict:

    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.


  • Netgate

    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?



  • @Derelict:

    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.