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 10.0.100.1 (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 169.254.2.1 OPT5 has the address 169.254.2.2. 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 10.0.100.1 set service nat rule 10 inside-address address 169.254.2.1 set service nat rule 5050 type masquerade set service nat rule 5050 source address 10.0.100.0/24 set service nat rule 5050 destination address 169.254.0.0/16 set service nat rule 5050 outbound-interface OPT5
And here how I did it on my Zyxel USG310
vlan1 = LAN
SPEEDPORT_MASK_IP = 10.0.100.1
SPEEPORT_IP = 169.254.2.1
SPEEDPORT = the physical Interface the Device was connected to
Maybe that helps
-
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"); filter_configure_sync();
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 addressIf 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?
-
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 10.0.100.1 (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 10.0.100.1 (external) to 169.254.2.1 (internal)
- Hybrid outbound NAT with rule on OPT5 to map a source of LAN net, destination of 169.254.2.1 (or the whole subnet), translated to the interface address
Windows clients on LAN talk to 10.0.100.1, 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?