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

    IPSEC NAT Problem

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    2 Posts 2 Posters 1.2k 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.
    • J
      jom
      last edited by

      Hi All!

      I am trying to port an existing ASTARO configuration to pfsense. That's the desired Setup:

      192.168.0.0/24 (NAT to 172.17.22.155) <-> 205.23.0.0/16 (that's a faked IP)

      In ASTARO there is a SNAT rule to do the NAT from 192.168.0.0/24 to 172.17.22.155, the tunnel is defined by

      172.17.22.155/29 <-> 205.23.0.0/16

      With pfSense the tunnel comes up with defining the phase2 connection by 172.17.22.155/29 <-> 205.23.0.0/16, WITHOUT NAT/BINAT.

      As soon as I define the phase2 setup like 192.168.0.0/24 (NAT to 172.17.22.155/29) <-> 205.23.0.0/16 the tunnel fails and I have the following problems:

      • pfsense complains that the networks 192.168.0.0/24 and 172.17.22.155/29 do not fit
      • even if I change the setup to be 192.168.0.0/29 (NAT to 172.17.22.155/29) <-> 205.23.0.0/16 the tunnel will not come up
      • defining the setup like 192.168.0.0/24 (NAT to 172.17.22.155) <-> 205.23.0.0/16 makes the tunnel not come up

      I assume that ASTARO does the NATing before evaluating the IPSEC tunnel and pfsense does not. Is there a way to NAT the traffic to 205.23.0.0/16 before it hits the IPSEC tunnel?

      What options do I have?

      Best Regards,
      Joachim

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        Normally you should provide the log of what is going wrong.

        From ipsec side of things this does not matter at all.
        As soon in pfSense you define the natting the other side will not see the private ips at all.

        So it does not matter how you express policies of NAT here since the other side will not look ever at that.
        Its just some parameters do not match there and that is what the log will express hence the need for it.

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