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

Virtual IP Proxy ARP Network will use invalid IPs for Pool

HA/CARP/VIPs
2
8
937
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
    Allen G
    last edited by Nov 21, 2018, 3:50 PM

    I had a lot of users complain they couldn't get to the internet. Seemed random and temporary, and by the time we'd get out to visit in the field the issue was gone.

    Digging into it, we found it was the outbound NAT trying to use reserved IP addresses and the interface gateway address as a source address .

    For example, if your WAN interface is 64.233.160.2, your netmask a /25 and your gateway is .1, you 'd expect a VIP on that interface to avoid using the .0 (subnet ID) and the .1 (the gateway) as source addresses. You'd be wrong however and 1.5 % of your users will be blocked. When you have thousands of devices, that's a lot of unhappy people.

    To demonstrate, create a Firewall -> Virtual IPs and click add. Set it to type Proxy Arp, the interface to WAN, and the address type of network. Enter your network and subnet (such as 64.233.160.0/25) and disable expansion.

    Now go to your Firewall -> NAT -> Outbound and edit your mapping under Translation -> Address to the new subnet you cerated (such as Subnet: 64.233.160.0/25)

    Lastly, check your state table and you'll see entries like 64.233.160.0 -> 8.8.8.8 with bytes send, but 0 bytes received.

    If you'd setup your Firewall NAT Outbound with a pool option that users Sticky Addresses, you'll have users 'stuck' mapped to the .0 or .1 address. When that happens to the VP you have a difficult time explaining you don't know what's going on :-/

    The only remedy we found was to create a series of Individual Virtual IPs of type alias, and then under Firewall -> Aliases add an alias entry and put the range of IPs we'd just crated there, then use that for the outbound NAT

    1 Reply Last reply Reply Quote 0
    • D
      Derelict LAYER 8 Netgate
      last edited by Nov 25, 2018, 5:17 PM

      That is working as designed.

      Outbound NAT has no concept of the interface network and broadcast addresses.

      It is just doing what it was told to do.

      If it was not that way you would "waste" two addresses if you told outbound NAT to use something like 64.233.160.16/29 as an outbound NAT pool.

      1 Reply Last reply Reply Quote 0
      • A
        Allen G
        last edited by Nov 25, 2018, 5:53 PM

        That's surprising, as you do tell it the netmask, and so the broadcast and network ID are known, the .255 and .0 in the case of a /24, for example.

        Is there a way to remove non-routeable addresses from the proxy arp pool?

        1 Reply Last reply Reply Quote 0
        • D
          Derelict LAYER 8 Netgate
          last edited by Nov 25, 2018, 6:00 PM

          But it is not a broadcast network in all cases. It is just a CIDR/Subnet. In the scenario I described, 64.233.160.16 and 64.233.160.23 are perfectly valid Outbound NAT addresses when they are on a 64.223.160.0/25 interface.

          About all that can be done there is to try to do some input validation in the web page since pf is what is handling the NAT there once told what subnet to use. Can only prevent so much foot-shooting especially in the more advanced areas like this.

          I agree the behavior there might be unexpected in some cases but it is technically correct.

          A 1 Reply Last reply Nov 25, 2018, 6:48 PM Reply Quote 0
          • A
            Allen G @Derelict
            last edited by Nov 25, 2018, 6:48 PM

            Ahh, so the proxy arp pool CIDR notation strictly defines the pool size and has nothing to do with netmask and routing.

            In your example, there are 6 useable IPs,
            64.233.160.17 - 64.233.160.22. However the pool will include all 8,. 16 and .23, because it's a pool defifition and not a netmask

            That is an important safety tip!

            So how would one create a proxy arp pool that didn't include the two reserved address and the gateway address without cutting the pool in half by increasing the netmask?

            1 Reply Last reply Reply Quote 0
            • D
              Derelict LAYER 8 Netgate
              last edited by Nov 25, 2018, 11:21 PM

              This post is deleted!
              1 Reply Last reply Reply Quote 0
              • A
                Allen G
                last edited by Nov 26, 2018, 1:53 AM

                What's more of a mystery is how you use the feature effectively.

                Maybe it's more effective when the wan gateway is on a different network and pf is routing a pool of VIPs to it. That way you dont have any conflicting IPs.

                When the VIPs are on the same network as the gateway, you obviously need to exclude that address, and you may get (like I did) unexpected results with the bottom address and top address ( the .0 and .255, in the case of a /24 )

                pf isn't my edge device so that may not be the most common use case.

                1 Reply Last reply Reply Quote 0
                • D
                  Derelict LAYER 8 Netgate
                  last edited by Nov 26, 2018, 2:01 AM

                  That (now-deleted) reply was totally to the wrong thread. Sorry.

                  Well, right, you should not have a /25 on your WAN interface. You should have a much smaller subnet there and the /25 should be routed to you.

                  If that was the case, as strange as it sounds, .0 and .127 would be valid NAT addresses.

                  In order to use something other than round robin you must use type subnet.

                  If you can use round robin, just define a host alias using a range and NAT to that.

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