Ping LANVPN not working



  • [0_1560594488381_Diagramme Test vpn.vsdx](Uploading 100%)
    Hello,
    I just got a Netgate SG-1100 with PFSENSE. I am trying to do a simple OPENVPV Server so I can connect securely to my home NAS when I am abraod . The diagram is attached.
    I have configured the WAN with 192.168.1.250/24 with default gateway 192.168.1.254 (my Internet box lan address).
    The Pfsense LAN is configured with 10.10.10.250/24.
    The VPNLAN (the lan used for the tunneling) is 192.168.100.0/24 (the remote PC got 192.168.100.2 and the pfsense 192.168.100.1).
    The remote PC can set the tunnel (so there is no problem with the certficates) but cannot reach the distant LAN (10.10.10.0/24).
    When I ping from the remote to the distant lan no reply but the ICMP paquet reaches the distant pc which seems unable to reply. This PC has 10.10.10.250 as default gateway.
    When I ping from pfsense I can reach the VPNLAN both sides (192.168.100.2 and 192.168.100.1) which means that the tunnel is up and running.
    From the distant PC I can ping 192.168.100.1 but not 192.168.100.2. I see (using Wireshark) the ICMP request going out to Pfsense but no reply.
    The Pfsense firewall rules are the one set by the wizard ( LAN, IPV4, Lannet, any source, any dest, any port through WAN gateway).
    For sure something is missing somewhere but I cannot see what. I have tried many things but without success so I need some help.



  • @alainmandine said in Ping LANVPN not working:

    The diagram is attached.

    I can't sadly see it.

    Consider that the NAS's firewall may block access from remote networks.
    To investigate, you can try a ping from pfSense using the default source and after another one like OpenVPN address. If it responses to the default, but to the other one, the NAS blocks it (presumed the pfSense is set as the default gateway as you stated).

    The same may apply to the remote PC. Desktop firewalls usually block access from remote networks. You my test it the same way, using its VPN address when the client is connected.



  • Thanks Viragomann,
    I have checked that the Firewalls of the PC's are not blocking pings. From Pfsense I can ping the local PC which in turn can ping the IP tunnel address of Pfsense local (192.168.100.1) but not the IP address remote (192.168.100.2).


  • LAYER 8 Rebel Alliance

    Post your OpenVPN Configuration and Firewall Rules (Screenshots).

    -Rico



  • OpenVPN_servers_Config6.PNG OpenVPN_servers_Config5.PNG OpenVPN_servers_Config4.PNG OpenVPN_servers_Config3.PNG OpenVPN_servers_Config2.PNG OpenVPN_servers_Config1.PNG Firewall_rules_Wan.PNG Firewall_rules_OpenVPN.PNG Firewall_rules_LAN.PNG
    Tks for yr help. Here are the screenshots. Hope it helps.
    Rgds Alain


  • Netgate Administrator

    @alainmandine said in Ping LANVPN not working:

    I have checked that the Firewalls of the PC's are not blocking pings. From Pfsense I can ping the local PC which in turn can ping the IP tunnel address of Pfsense local (192.168.100.1) but not the IP address remote (192.168.100.2).

    But did you test from both the LAN interface address as source and from some other source address such as the OpenVPN tunnel IP when pinging from pfSense? That's the test you need to do to be sure the NAS or 'Distant PC' can respond to pings from outside their subnet.

    The remote PC may also have a local firewall preventing it responding to pings from the distant PC.

    The top firewall rule you have on WAN can never match anything, you should disable or remove it.

    What is the alias LANVPN?

    Steve



  • I am pretty sure that both PC can reply or receive pings. When the tunnel is up and I ping something on the Internet, I get replies from the pinged host thru the VPN tunnel .
    When I ping from Pfsense the tunnel ip address on the remote site (192.168.100.2) it works. From the local site I can ping 192.168.100.1 (tunnel address on pfsense). This means (for me) that the local site has a route to the 192.168.100.0/24 network (its default gateway being 10.10.10.250 the pfsense LAN address) . Ping to 192.168.100.2 does not work.
    LANVPN alias is bound to 192.168.100.0/24. It is a trial to make this network known from pfsense.
    Tks for yr assistance.
    Rgds Alain


  • Netgate Administrator

    When you ping 192.168.100.2 from pfSense it will ping from 192.168.100.1 which is onside the remote PCs subnet so it will allow it.
    If you ping 192.100.2 from pfSense but set the source as the LAN it will ping from 10.10.10.250 which is outside any subnet on the remote PC. Does that fail? If so it's probably the remote PC either blocking it or with no route back.
    Check the routing table on the remote PC when the tunnel is up for a route to 10.10.10.0/24.

    The same applies to the distant PC and NAS. Ping them with source OpenVPN Server and it will ping from 192.168.100.1. They should respond.

    Steve



  • Thanks for the assistance,
    When a ping goes out to Internet the ISO box is doing source nat so the remote PC get a ping from my public ISP address and respond back to it without any problem.
    I have done more testing : when I ping 192.168.1.254 (the default gateway and access to the Internet), I can see the pings going out and in on the PFsense capture on the WAN side diagnostic tool. Which is normal. When I ping 192.168.100.2 I can see the ping reaching the PFsense box but nothing going out to the Internet.
    Now I am wondering if this is not a bug :
    the NETGATE SG-1100 is a pretty new box and the version I am using is also pretty new (2.4.4-RELEASE-p3 (arm64)
    built on Thu May 16 06:01:19 EDT 2019 ) . Perhaps no one as already used the box as a VPN server.
    What is the procedure to have NETGATE to look at the problem ?


  • Netgate Administrator

    @alainmandine said in Ping LANVPN not working:

    ISO box

    ISP supplied router?

    When I ping 192.168.100.2 I can see the ping reaching the pfSense box but nothing going out to the Internet.

    You should not see those pings on the WAN as that traffic should be inside the OpenVPN tunnel. You would have to pcap on the OpenVPN server interface to see that. The only thing you would see on the WAN are the OpenVPN UDP 1194 packets.

    The SG-1100 works just fine as an OpenVPN server I have tested it myself many times.

    You need to run those tests I outlined, ping with a different source selected, and let us know what the results are.

    Steve



  • Yes, ISP not ISO.
    I am setting a VPN server not a Client. The tunnel is only between the Remote Client and PFsense. All other traffic is not encapsulated.
    When I ping 192.168.100.2 from PFsense the pings are encapsulated (port 1194) and reach correctly the remote PC which is replying. This is perfectly normal behaviour. Now when I ping 192.168.100.2 from the local PC (the one attached to the PFsense LAN port), the ping DOES NOT go out of the PFsense Box. And this not a normal behaviour but as far as understand routing this is not a routing problem. PFsense only default gateway is the ISP box. So any address that is not on the LAN should be sent to the ISP Box . The Local PC has an address on the 10.10.10.0/24 which is PFsense LAN network.
    All non-tunneled traffic originated from the local PC to the Internet is working fine including pings. This traffic is going through the PFsense box.
    The SG-1100 that you are running as a VPN server does it run version 2.4.4-RELEASE-p3 (arm64) ?
    Thanks for your assistance.


  • Netgate Administrator

    Pings to 192.168.100.2 from a PC in the 10.10.10.0/24 subnet should still go out over the OpenVPN tunnel as that is in the system routing table. The only reason they would not is if you had a firewall rule on LAN either blocking that traffic or with a gateway set that forced the traffic. It doesn't look like you have either in the screenshot.
    Check the routing table in Diag > Routes to make sure it is there.

    The PC at the client end of the tunnel may not necessarily reply though.

    Yes I've tested it with 2.4.4p3.

    Steve



  • Tks Steve,
    here is my routing table.
    RoutePfsense.PNG
    When the PC at the remote end is pinged from pfsense it, it replies.
    Rgds Alain


  • Netgate Administrator

    @alainmandine said in Ping LANVPN not working:

    When the PC at the remote end is pinged from pfsense it, it replies.

    But from what source?

    We know it replies when you ping from 192.168.100.1 but what if you select LAN as the source IP?

    Try running a packet capture on the OpenVPN interface at the same time to be sure traffic is going that way.

    Steve



  • When the pings go out of PFsense the source address is NATted by the ISP box into my Internet public address ( in my case 93.5.222.183) . This is the only source address that any paquet is allowed to go with to the Internet.
    Here are the capture paquets with different source address.Ping4.PNG Ping3.PNG ping2.PNG Ping1.PNG .
    As you can see only the pings with source address "Automatically seleceted(default)" and "OpenVPN sever: OpenVPN instance Serveur" which is 192.168.100.1 are getting a response.
    Capture paquets from PFsense WAN interface are a little bit less easy to look at because most of the paquets are encapsulated and crypted which is what we are looking for :
    Capture1.PNG
    Capture2.PNG
    Capture3.PNG
    Capture4.PNG
    Capture5.PNG

    Tks for yr help
    Rgds Alain


  • Netgate Administrator

    Ok, so run a packet capture on the OpenVPN server interface and then ping 192.168.100.2 from LAN. You should see the ping requests going out.

    Steve



  • When I do that I see ICMP going out :
    Capture10.PNG
    This is, to me, a nonsense. The network 192.168.100.0/24 is only known inside the tunnel. It's a private network and no router will route it on the Internet.
    PFsense should encapsulate the ICMP into a packet with destination 80.12.34.95:1194 which is the tunnel end point.

    Btw when I 1st started the SG-1100 out of the box, the OpenVPN server worked fine. I did not check the check the PFsense version but as it was las May It cannot have been 2.4.4 . I cann't remember if I did an upgrade or got an autoupgrade. I have contacted Netgate support to get the previous version but they are very reluctant to provide the version.
    Rgds Alain


  • Netgate Administrator

    It is encapsulated. You are capturing on the OpenVPN adapter so it shows only traffic inside the tunnel.

    So you see the requests being sent and the remote client is not responding. Either it is blocking that traffic because it's outside it's own subnet or it does not have a route back to the LAN subnet.
    However you said previously you were able to ping a PC in the LAN and the pings reached it and also the OpenVPN tunnel is set to route all traffic through the tunnel. It's likely some local firewall on the client is blocking it.

    Ok now lets test the other way. Try to ping 10.10.10.250 from the remote client at 192.168.100.2.

    If that works try to ping some other client on the LAN whist packet capturing on the LAN interface. Do you see the ping requests from 192.168.100.2?

    We can provide you a previous version but I'm almost certain it won't help here.

    Steve



  • Hello Steve,
    This morning I have done a few trials :
    - ping 10.10.10.250 from remote : no reply

    • ping another alive server on the 10.10.10.0 network : no reply
    • disabled anti-virus and firewall on remote PC : still no reply
    • on remote pc added a static route 10.10.10.0/24 to gateway 192.168.100.2 : still no reply but before the route was added when pinging 10.10.10.250 i was getting "waiting time exceeded" and after the addition I was getting "from 192.168.100.2 unable to reach the destination".
      I still want to make a trial with the previous version. Can send the file.
      Tks Rgds Alain

  • Netgate Administrator

    The static route should be via 192.168.100.1, the pfSense end of the tunnel.

    It does sounds like it has no route. Check the routing table on the remote PC when the tunnel is up.

    Your config is to set a new default gateway on the remote PC when the tunnel comes up so all traffic should come over the tunnel. The remote client might just be refusing to allow that. You could change that setting in the OpenVPN server so that you set 10.10.10.0/24 as a local network and it sends only a route to that.

    The static route should do that though.

    You will have to open a ticket with us at https://go.netgate.com to get older firmware.

    Steve



  • Hello Steve,
    I have changed the route to 192.168.100.1 without improuvement.
    I have also tried on a different Windows PC 5Win 10) also without improuvement.
    I have issued a ticket to Netgate support but they refuse to give the previous version arguing that the 2.4.4 should work.
    I will continue arguing with them.
    May be I will try 2.5 which is available for testing.
    Rgds Alain



  • Hello Steve,
    GOOD NEWS
    I have added these 2 rules and now it works not only I can ping the local network from the remote PC but it has also access to the local servers.
    Capturelast.PNG
    Thanks for your assistance.
    Regards Alain


  • Netgate Administrator

    Ah, that would do it! I would have suggested that but in your screenshot above you already had an allow all rule on the OpenVPN interface that would have passed that.

    The first version of pfSense that supported the SG-1100 was 2.4.4p1 and the differences to p3 there is minor. It definitely would not have helped here.

    Steve


Log in to reply