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

    IOS-style proxy-arp supported?

    General pfSense Questions
    2
    3
    1.8k
    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.
    • O
      Oroboros
      last edited by

      A customer's network is misconfigured such that a bad subnet mask on a dozen machines is preventing a VPN from working correctly. I know this, they know this. They are afraid to fix it.

      The problem was exposed because their Cisco router interface (recently replaced with pfsense) was defaulting to "ip proxy-arp" which meant that if an arp request is received for a random third-party host that isn't in a known subnet, the router will answer back as if it were that remote machine and then perform the routing required to get the traffic where it needs to go.

      So in IOS parlance "proxy arp" means "answer for any arp request and do a kind of NAT with it". The customer has multiple sites behind pfsense now, and sloppy subnetting means there are holes.

      I've always hated that the old style proxy arp was there as a kludge to allow misconfiguration to persist. It also has some uses. I've been in hotels that did a kind of proxy arp for my statically configured NIC that had a foreign public IP on it. In that case, it was real NAT and more than simple proxy arp.

      So am I missing a simple configuration tip that allows me to emulate "ip proxy-arp" on Cisco? My standard template for locking down routers means I usually apply "no ip proxy-arp" to every interface, because I think it's that evil.

      So it's a bit of a paradox then that I'm here looking for a way to emulate it in pfsense…. Because of the way proxy arp is implemented for binding IPs locally, I wind up reading a lot of non-relevant posts here.

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        It cannot be done without development afaik.

        1 Reply Last reply Reply Quote 0
        • O
          Oroboros
          last edited by

          I'm not surprised, and I'd personally discourage such development.

          I just sent the customer a long list of workarounds. #0 is "fix the brokenness you see first". They complain this particular server is "finicky". No wonder.

          I also could put the device into bridging mode and probably get the behavior back, since the Cisco is on the other end still terminating a T1.

          Or I could setup some OpenVPN tunnels bridging.

          It's gonna hurt if I have to do any of that.

          I even came up with a solution to the most serious consequence (broken VPN) that only involves adding a couple more specific static routes to the more important servers.

          So many workarounds  ::)

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