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

    NAT and IPSEC

    NAT
    4
    8
    642
    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.
    • A
      anohles
      last edited by

      Hello together,

      i´ve got a problem with an ipsec tunnel and NAT. But i`m shure that I am not smart enough to get it running.

      I have an ipsec tunnel with an attached VLAN (an internal address). There is a NAT defined for a computer in another VLAN.
      The incoming path is working fine, the packets are coming in and beeing forwarded using the NAT.
      BUT, the way back is not working. The answers for the computer behind the NAT are going out, but on the wrong interface (default GW) but using the NAT.
      When I will integrate the additional VLAN in the ipsec, the packets are going on the correct ipsec tunnel but without the outgoing NAT.

      So, how do I get NAT and IPSEC running together?

      I did try to change the NAT with 1:1, port forward, outgoing... but no change in the handling.

      Maybe somebody could give me some hints to get this running.

      Thanks

      Alex

      1 Reply Last reply Reply Quote 1
      • A
        anohles
        last edited by

        Hi ho,

        some additional Infos:

        This is the VPN Tunnel Phase 2

        2d1477a1-a3a5-4634-9632-1f0a51e1178b-image.png

        So, I will access the 192.168.70.83 using the 172.16.210.74 as NAT when the traffic is coming from the 172.25.134.0/24

        So, the Packets are coming in, will get natted to the correct server, but on the way back, they will not get the outgoing NAT, so the Packets are going out using the 192.168.70.83 Address which is not known on the other side of the VPN Tunnel...

        e224be05-3b20-4cc5-8fe8-868e370d7f52-image.png

        I hvae alos setup an outgoing NAT, but i think that i normaly do not need one, but with or without it is not working.

        87a07624-a7c8-4b82-8434-37d31bd0e742-image.png

        Maybe someone could tell me my mistake.

        Thanks

        Alex

        1 Reply Last reply Reply Quote 1
        • J
          julienb
          last edited by

          Hello Alex, I attempted to create the same setup (using pfsense 2.4.4-3), and it failed EXACLTY the same way.

          The extra NAT rule did not work either for me.

          Do you have any update on this configuration ?

          Did you took the capture (a) on the pfsense, or in the (b) 172.25.x.x network ? In the (a) case it MIGHT be normal, since in the CAVEAT section in the help, the documentation states that the capture is performed before the NAT. In the (b) case, yes the NAT does not work properly.

          Hope to reading from you Alex, or from anyone,

          I have been banging my head against the netgate device for two days now, and I cannot switch to OpenVPN, since our big client requires IPSEC usage, with a NAT/PAT.

          Julien.

          1 Reply Last reply Reply Quote 0
          • GrimetonG
            Grimeton
            last edited by

            PfSense or better pf in FreeBSD for that matter, cannot do NAT after IPSec. Dunno if that has ever been fixed or not, but that's one of the few things the whole setup cannot do.

            https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185876

            https://forums.freebsd.org/threads/solved-ipsec-l2tp-vpn-on-10-0-no-traffic-to-internet.45691/

            1 Reply Last reply Reply Quote 0
            • J
              julienb
              last edited by

              Thanks Grimeton for the reply, the bugs you are linking to seems to be resolved now.

              The documentation seems to agree that NAT is possible in a 1:1 form, and in a NAT/PAT form. (Although nobody seems to use the latter, and it might be buggy).

              Too bad my netgate support is expired when I need it.

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by Derelict

                @anohles said in NAT and IPSEC:

                So, the Packets are coming in, will get natted to the correct server, but on the way back, they will not get the outgoing NAT, so the Packets are going out using the 192.168.70.83 Address which is not known on the other side of the VPN Tunnel...

                That is not true. Packet captures in the outbound direction happen before NAT occurs but the NAT WILL occur.

                In the example above, the other side should create a tunnel like this:

                Local Network: Network: 172.25.134.0/24
                Remote Network: Host: 172.16.210.74

                ETA: This is only on captures on IPsec/enc0. Interface captures will be post-NAT for outbound traffic and pre-NAT for inbound.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • J
                  julienb
                  last edited by

                  Ok thanks, so I cannot confirm if NAT is working or not just by looking at the client logs or captures.

                  I will setup a server platform to test my client settings, and not just blindly trust my peer that says "your incoming address must be wrong".

                  GrimetonG 1 Reply Last reply Reply Quote 0
                  • GrimetonG
                    Grimeton @julienb
                    last edited by

                    @julienb If you can, check on the other end what IP-address you see there. If it is the one you expect, then NAT is working.

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