• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Apr 11, 2012, 2:35 AM

    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 Apr 12, 2012, 6:50 PM

      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
      1 out of 2
      • First post
        1/2
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.