Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Pfsense with Nat+ipsec pinging in one direction onlu

    Routing and Multi WAN
    1
    2
    2.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      kcrozier
      last edited by

      Hi,

      Sorry if this has already been asked and solved, but i just can't seem to find the answer ….

      Here's my setup  2 pfsenses with an IPsec tunnel between them.

      The first has 3 interfaces, WAN, DEMO & Inside. Wan goes to the wide and woolie internet and has a Nat on it, Demo is a set of machines that are accessible through the WAN Nat, and inside points into my network and also has a nat on it.

      The second has two interfaces, WAN and inside with multiple networks hiding behind a router attached to inside.....

      The IPsec tunnel goes from #1-inside to #2-WAN, comes up and I can ping from #2 local network to addresses on #1-Demo.
      I cannot ping in the reverse direction ... weird as if ICMP can normally flow in one direction and get back then it should flow the other way to  >:(

      So a little more on my setup, #1 has 3 interfaces, Wan has a dfgtway that points out to the internet, Inside has a dfgtway that points to a router inside my network, and Demo doesnot have a dfgtway defined. The systems that on the Demo interface have their default gtway pointed at the ip address of the Demo interface.

      When I do a trace route from the systems attached to demo, for a network that lives on the other side of the IPSEC vpn, pfsense #1 is trying to resolve that network through the WAN interface, which to me seems to be broken as I would have thought that pfsence should know that that network is locally attached at the other end of the VPN ....

      addressing ....

      #1 WAN is x.y.z.a and points to x.y.z.1 , LAN is 10.120.18.40/dfgate 10.120.18.1, Demo is 192.168.1.1
      the systems on #1 demo are 192.168.1.2 through 100 with dfgtway of 192.168.1.1
      #2 Wan is 10.66.100.24 with dfgateway 10.66.100.1, Lan is 192.168.6.1 with dfgateway 192.168.6.1
      there is a device that lives at 192.168.6.2 that it can ping 192.168.1.2 through 192.168.1.100
      192.168.1.2 can't return the favour and ping the device at 192.168.6.2
      the IPsec vpn goes between #1 LAN @ 10.120.18.40 to #2 WAN @ 10.66.100.24 with the map showing 192.168.1.0/24 --> 192.168.6.0/24
      of course the reverse is the reverse ... with map 192.168.6.0/24 --> 192.168.1.0/24
      The tunnel comes up and like i said I can ping from 192.168.6.2 to 192.168.1.2

      What am i missing ?
      Is it the default gateway on the #1 Demo, is it a static route, which i've tried but doesn't seem to make any difference ?
      is it because the IPsec vpn on #1 inside is on the other side of the NAT and therefore I need to set up a virutal IP, and if so how the heck can I ping inbound & get an answer ?

      pulling my hair out now ...

      Ken

      1 Reply Last reply Reply Quote 0
      • K
        kcrozier
        last edited by

        A quick update, moving the icmp filter above the tcp/upd filter resolved the problem and now traffic goes both ways.

        How for another twist, I added a second IPSec tunnel to 10.66.102.0 and now I'm back to the same type of symptoms on this link. But a little more strange ….

        From a workstation at 192.168.1.2 I can ping 192.168.6.2 all the time, if I stop that and ping 10.66.102.2 the ping never gets through the VPN.... Now if I start a ping from 10.66.102.2 and let it run for a while, then all of a sudden the reverse ping starts to work....if I stop the reverse and ping 192.168.6.2, stop it and then ping 10.66.102.2 it doesn't complete, and then after about 30 - 40 secs.. It starts again

        Could this be an arp, routing problem, or a IPSec tunnel problem ?
        Ken

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.