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

    IPSec Causes Local Routing Issues

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 511 Views
    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.
    • D
      david_halliday
      last edited by

      It almost works but not quite.

      WAN 1.2.3.1/28
      LAN 192.168.200.1/24
      OPT1 10.40.0.1/16

      Without IPSec firewalls rules are setup so it is possible to

      a) Ping 192.168.200.1 from hosts on LAN
      b) Ping 10.40.0.1 from hosts on OPT1
      c) Route between the networks for example ping 192.168.200.222 from 10.40.0.111

      (also works for TCP/UDP as well as ICMP)

      All this works now enter IPSec

      Now With IPSec configured with:

      Phase 1
      First Phase 2 local LAN Net remote Net 10.0.0.0/8
      Second Phase 2 local OPT1 Net remote Net 10.0.0.0/8

      Now IPSec comes up correctly and I can get 2 way access (ICMP, TCP,UDP) for example

      10.10.10.10 can access 10.40.0.111 (and the reverse)
      and
      10.10.10.10 can access 192.168.200.222 (and the reverse)

      So all seems good BUT here is the problem

      When IPSec is up it is no longer possible for 10.40.0.111 to access 192.168.200.222 and vica versa.

      It is still possible to ping 192.168.200.1 from the LAN
      It is NOT possible to ping 10.40.0.1 from a host on OPT1 (remember remote network is 10.0.0.0/8 and 10.40.0.0/16 is a sub of that)

      So it appears that pfSense is not obeying classless network when IPSec is up and it thinks that 10.40.0.0/16 is remote even though the local route is more specific that the network for IPSec.

      It is not possible to specify a different remote end as in reality there are lots of 10.X networks that need to be routed to not just 10.10 in this example. Likewise it is ugly to change the local end from 10.40 as that would involve mass renumbering.

      So.

      Is there a way to force local routing before IPSec?
      Or perhaps a way to exclude 10.40 out of IPSec (I see an option to exclude LAN)
      Or perhaps a way to use a static route (rather than the remote network range) to determine what goes into IPSec. (This would allow the lPSec to work at the same layer as the local routing).

      Thanks,
      Dave.

      dotdashD 1 Reply Last reply Reply Quote 0
      • dotdashD
        dotdash @david_halliday
        last edited by

        Traditional IPSec grabs the traffic before it hits the routing table. If you really can't fix having your phase2 match an entire class A, you have a couple of options:
        Wait for 2.4.4 and used routed IPSec
        Change the 10.40/16 (You need a class B?) to the LAN interface and the 192.168 to the OPT. This will allow the LAN bypass to work.

        1 Reply Last reply Reply Quote 0
        • D
          david_halliday
          last edited by david_halliday

          Ah, should have thought about LAN bypass. Oh well. In the end I went and renumbered everything out of 10.40/16 and into another Class C 192.168.201.0/24.

          I am looking forward to 2.4.4. however, routed IPSEC sounds like the real solution. This is how the Juniper SRX on the other end handled things. Creates and extra interface and you simply route down that interface.

          Thanks again for the input it is appreciated.

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