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

    NAT-T between two 2.2 pfsense with public IP. Why?

    Scheduled Pinned Locked Moved IPsec
    5 Posts 4 Posters 1.4k 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.
    • N
      nikolaii
      last edited by

      Hi,

      not really a problem, since my tunnels are up and running, but I observed that even with two public IP (on both firewalls), the tunnel shows up as NAT-T configured.

      
      Description 	Local ID 	Local IP 	Remote ID 	Remote IP
      left to right 	A.A.A.A 	A.A.A.A		B.B.B.B		B.B.B.B
      				Port: 4500			Port: 48866
      				NAT-T
      
      

      Any idea why?

      Thanks,
      Nicolas

      Nicolas

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

        Same here.

        The situation is easily reproduced, between two firewalls running pfSense v2.2-RELEASE with Auto-matic NAT-T option.

        Although performance isn't critical in my case, wrong NAT detection is quite annoying.

        1 Reply Last reply Reply Quote 0
        • D
          doktornotor Banned
          last edited by

          Known bug, wait for 2.2.1

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            @dusan:

            wrong NAT detection is quite annoying.

            It's not wrong NAT detection, except the text in the status page. I'm guessing you're using IKEv2, where it's MOBIKE, not NAT-T. MOBIKE wasn't controllable until 2.2.1, and it defaults to on in strongswan. Now we default it to off, since most use cases are site to site, not mobile, but make it configurable. We also hide the NAT-T field in the GUI where IKEv2 is chosen now, to make it more clear when it's applicable.

            The status page text where it shows "NAT-T", it just spits that out if it's using port 4500 (it was a quick hack I put in to fix a problem with it not showing), so it's actually wrong in that case.

            You're using MOBIKE, because it's configured to do so.

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

              cmb, thank you for information. Yes, I'm using IKEv2, for security. I didn't know that switching to IKEv2 also [accidentally] activates MOBIKE.  It doesn't seem to have been mentioned in the 2.2 release notes.

              From pftop status display (below), I can confirm that ESP tunnels between pfSense firewalls with public IP addresses remain pure ESP, not UDP-tunneled. It's just the IPsec status page that displays misleading information.

              Thanks again!

              pfTop: Up State 1-100/17675, View: default, Order: dest. port
              PR    D SRC                   DEST                 STATE   AGE   EXP  PKTS BYTES
              esp   I xxx.xxx.11.62:0       xxx.xxx.84.122:0      2:2  38661    59 8936K 8989M
              esp   O xxx.xxx.84.122:0      xxx.xxx.227.40:0      2:2  41009    60  228K   40M
              ...
              tcp   I 74.125.82.172:33980   192.168.0.75:25      10:10   106    11   491  340K
              tcp   O 74.125.82.172:33980   192.168.0.75:25      10:10   106    11   491  340K
              tcp   I 192.168.19.4:4261     192.168.12.20:42      4:4  39727 86274   194 20994
              tcp   I 192.168.16.3:1087     192.168.12.20:42      4:4  37625 84775   186 19694
              udp   I 192.168.12.26:56079   8.8.8.8:53            1:2     15    15     2   352
              udp   I 192.168.12.26:55595   8.8.8.8:53            1:2     12    18     2   276
              udp   I 192.168.12.16:56447   23.5.165.172:53       1:2      7    23     2   152
              ...
              
              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.