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

    Address mismatched log flood

    Scheduled Pinned Locked Moved IPsec
    3 Posts 1 Posters 2.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.
    • C
      corradolab
      last edited by

      Hello everybody,

      I've a working IPSec tunnel, but the log is flooded with this:

      Jan 28 10:51:30 racoon: [vpn1]: [x.x.x.229] WARNING: remote address mismatched. db=x.x.x.229[4500], act=x.x.x.229[10012] 
      Jan 28 10:51:35 racoon: [vpn1]: [x.x.x.229] WARNING: remote address mismatched. db=x.x.x.229[4500], act=x.x.x.229[10012] 
      Jan 28 10:51:46 racoon: [vpn1]: [x.x.x.229] WARNING: remote address mismatched. db=x.x.x.229[4500], act=x.x.x.229[10012] 
      Jan 28 10:51:51 racoon: [vpn1]: [x.x.x.229] WARNING: remote address mismatched. db=x.x.x.229[4500], act=x.x.x.229[10012] 
      

      Look like a NAT-T issue. Network setup is:

      pfSense <–> Wireless link (PPPoE) <--> Internet <--> Adsl router (NAT) <--> Fortigate

      I've other tunnels with similar configuration which does not show issues.

      Any idea?

      Regards,
        Corrado

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

        The issue seemed to go away yesterday when I restarted racoon, but today is back again.

        I wuold like to put racoon in debug mode, but I'm concerned about leaving debug mode on for a day or longer on a box with a dozen active tunnels.

        Is it possible to set debug mode on a single tunnel?

        Regards,
          Corrado

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

          **FIXED **

          I got the issue on 2 tunnels out of a dozen.
          Apart log flood, the tunnels get stuck after a few weeks.
          The affected tunnels originated from the same ISP.

          I fixed the issue disabiling NAT-T.
          UDP encapsulation of IPSEC (NAT-T) kicks in as soon as NAT is detected, despite many SOHO routers can forward ESP when properly configured.

          I suggest to always try IPSEC without NAT-T first.
          If it works you save 8 bytes / packet (no extra UDP header) and lower the chances to get packets fragmentations (seems IPSEC MTU is not adjusted subtracting 8 bytes when using NAT-T).

          Regards,
            Corrado

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