Accessing a Device with an APIPA on OPT from LAN

  • Hi Everyone,

    on my Interface OPT5 i have a device which only has an APIPA adress, which i can't change, the manufacturer built it like that, it's stupid, I know, but nothing I can do about it.
    On other Firewalls I used a mask IP adress like (which is nowhere used) and routed or nat this to the Interface OPT5 so I can access the APIPA-device.
    But due to my lack of network knowledge i can't do it on a pfsense (it's a little less user friendly than I'm used to :))

    The APIPA Device uses the adress OPT5 has the address The PFsense can allready reach it, so I'm halfway there. How can I make this possible for my whole LAN?

    maybe it helps to understand what I mean and what I did in my other configs so here is how I did this on my Edrouter X

    set service nat rule 10 type destination
    set service nat rule 10 inbound-interface LAN
    set service nat rule 10 destination address
    set service nat rule 10 inside-address address
    set service nat rule 5050 type masquerade
    set service nat rule 5050 source address
    set service nat rule 5050 destination address
    set service nat rule 5050 outbound-interface OPT5

    And here how I did it on my Zyxel USG310

    vlan1 = LAN
    SPEEDPORT = the physical Interface the Device was connected to
    routing.png nat.png

    Maybe that helps

  • Rebel Alliance Developer Netgate

    That's a rather large mess.

    First, you have to disable APIPA blocking. There isn't a GUI option for that yet (added in 2.4.5) but you can do it from Diagnostics > Command Prompt:

    $config['system']['no_apipa_block'] = "enabled";
    write_config("Diable APIPA Block");

    Then go to Firewall > NAT, Outbound tab.
    Enable Hybrid Outbound NAT mode & Save (or if you are already on Manual, that's OK too)
    Create a rule for the OPT5 interface to NAT the LAN network to the OPT5 address

    If you have any pass rules on LAN with a gateway set, make sure you have a pass rule above them to pass traffic going to the OPT5 network without a gateway set. That's important, since if APIPA traffic hits a policy routing rule, it's going to cause all kinds of trouble. That's why the default block is in place.

    All that said, there is a chance it still may not work right, since APIPA traffic is not meant to be passed through a firewall.

    You might also need to setup proxy ARP VIPs and 1:1 NAT on the LAN interface to translate an entirely different non-overlapping subnet to the OPT5 subnet since, as I mentioned, APIPA traffic is not meant to be processed by a firewall. Adjust the outbound NAT rules to match that.

    That way clients in x.x.x.x talk to y.y.y.y, in the firewall, the destination y.y.y.y gets translated by 1:1 NAT into the APIPA net. On the way out, the source x.x.x.x has outbound NAT applied to it appears to originate from the firewall's own address in the APIPA subnet.

    I haven't tested any of that since I desire to retain what remains of my sanity, but that's probably your best hope at the moment short of coming up with some kind of proxy-based solution.

  • Hi thanks for the reply!

    so by your solution I would actually call an APIPA address from my client?
    I don't want that since windows for example has it's problems with this too!

    is there no way to do it like i did it in my example?

  • Rebel Alliance Developer Netgate

    Windows clients would talk to "y.y.y.y" in that last example, which is analogous to your 10.0.100.x address. I geralized it to cover the entire subnet you'd use. But if it's only a single device address that can work, too.

    You could do:

    • Add a VIP for (Proxy ARP or IP Alias -- if it's a single address, either is fine, for subnets, proxy ARP is easier)
    • 1:1 NAT on LAN to map (external) to (internal)
    • Hybrid outbound NAT with rule on OPT5 to map a source of LAN net, destination of (or the whole subnet), translated to the interface address

    Windows clients on LAN talk to, NAT takes care of translating it so that by the time it reaches the target, it appears to have originated from the firewall's own address in that subnet.

  • It works!
    thank you veryyy much :)

  • i hope it's okay to reopen this problem, but with the newest pfsense release, 2.4.5, this stopped working.
    I noticed there is now a GUI Option for $config['system']['no_apipa_block'] but disabling and enabling it won't make it work again.

    At first the Traffic was blocked in the FW but after adding a rule to allow every traffic from LAN, the log looks better but still strange:

    It's only sending TCP-SYN?

Log in to reply