IPSec Causes Local Routing Issues



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



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



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