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

    Serious packet loss issues when 1:1 is enabled.

    Scheduled Pinned Locked Moved NAT
    7 Posts 3 Posters 4.0k 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
      Numbski
      last edited by

      I've confirmed this using both CARP and Proxy-ARP.  Beta2.

      I create a virtual IP address for the server.  I create rules to allow traffic to pass to the server (using the LAN IP address of the system, not the virtual IP), and very strange things start to happen.

      Name lookups, ssh, voice traffic, all break down badly.  If I allow ICMP, I'm losing a good 2/3 of the packets.  If I ping from the machine out to the firewall's gateway (ie, the next hop upstream) the packets I get back take over a millisecond to return, and I don't get all of them back.  The problem immediately ceases as soon as I disable the 1:1 NAT entry.  Very bizarre.  Unfortunately I'm stuck in a situation where I can't route the public IP's and will be that way for ~6 more weeks. :(  My upstream provider is totally clueless about routing.  Scary stuff.

      So 1:1 NAT I must.  Is this a known behavior?  It seems to me that allowing ICMP traffic to return correctly might be an outbound NAT issue, but if I set up 1:1, it should automatically appear to be coming from the external IP of the 1:1 entry, correct?

      What's more, I was getting an error scrolling in my logs like this:

      kernel: arp_rtrequest: bad gateway x.x.x.x !AF_LINK

      I searched for that, and of course it complains about arp table weirdness, which would make sense with the problem I'm having.  It could be that layer 2 is getting hosed up getting back to the interface, but I've tested all of my cables, leaving the switch which is, sadly, an unmanaged switch.

      Thoughts?

      1 Reply Last reply Reply Quote 0
      • N
        Numbski
        last edited by

        I've further narrowed the cause of the problem.  I've turned off 1:1, and instead I've enabled advanced outbound NAT.  I added a new rule and placed it in front of the default rule, stating that traffic coming from this machine on the inside should be seen as the virtual IP address I've added.  As soon as I do this, i get packet loss.  Turn it off, packets flow fine again.

        This is really odd.

        1 Reply Last reply Reply Quote 0
        • S
          sullrich
          last edited by

          I run both 1:1 and advanced outbound on the same firewall… I am not seeing this.

          1 Reply Last reply Reply Quote 0
          • N
            Numbski
            last edited by

            I'm not seeing it on my other boxes either.  Really makes me wonder.  I'll reply here if I figure out what's causing it, but for now I cannot assign a public IP to that machine until I can clue in my provider of how to set up routing.

            1 Reply Last reply Reply Quote 0
            • N
              Numbski
              last edited by

              Resolved.  I did something dumb, and yet it's probably a common mistake when setting this sort of thing up even though there's a warning sitting there.

              The virtual IP I assigned was in a /26.  When I set up the carp IP, I set it up as a /32 (even though it says to use the REAL subnet mask).

              Oi.  Drove me nuts.  Packet loss, begone!

              1 Reply Last reply Reply Quote 0
              • S
                sullrich
                last edited by

                Unfortunately we cannot cure the world of not reading :/

                1 Reply Last reply Reply Quote 0
                • H
                  hoba
                  last edited by

                  We need to make our textx more interesting to ready, maybe some boops would help  ;D

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