Routing 169.254 Networks

johnpoz

Well if your clients are on the same L2 as the printer... Then yes they could directly talk to the 169.254 address since they are on the same L2 network... Amounts to just running multiple L3 on the same L2.. And to be frank its BORKED!!

If your company owns the IP space, and they want to use it on their devices... And allow them to be directly exposed to the internet ??? That is up to them.. Not something I would ever do in a million years.. Public space is fine if you own it, allowing it to be directly exposed is just plan moronic in this day an age.

If you want to put yourself behind a firewall where the 169.254 resides on your wan, the only way your going to be able to talk to it is nat to it..

Create an outbound nat rule to the vip you created on your wan with some 169.254.x.x address... NAT the traffic you need to send to your printers 169.254 address to your vip.

hopkins

There is of course a FW after the GW, which doesn't made the devices directly expose to the internet. Opening a port to the internet requires some kind of commercial HIDS agents installed on the machines (and exhaustive paperwork too!).

For that outbound NAT Rule to the VIP, I need to create the VIP with the address 169.254.x.x, right? Is it possible to create one in 192.168.1.x range (and outside DHCP range too) so that my Linux machines doesn't need to setup a route specifically for eth0?

I was hoping there is a "virtual host" on 192.168.1.x which redirect traffics to it to the printer at 169.254.169.233.

Thanks.

johnpoz

You could create a port forward, but your still going to need the 169.254 vip on the wan.

You understand all these problems would go away if they would just give the printer a 189.237 IP.. Why do they not give the printer an IP on the network its sitting on?

hopkins

Of course everything would be fine if the printer got an IP address on 189.237.xxx.xxx, but due to limited IP address space we own, they seems to think having a dedicated IP for a printer in a small office is a wasteful of resources. Plus the fact that no other colleagues had issues with current setup on Windows (only me because I need my PF Box).

I tried adding 169.254.169.233 as IP alias VIP, but it messed up my route in my PF Box.

My original config is adding the route at system boot, which is quite hacky IMO:
(Adding in "shellcmd" in "system" stanza of /conf/config.xml) (Have to put in this way or will flagged as spam by the forum's spam detection engine "flagged as spam by Akismet.com")

route add -net 169.254.169.233/32 -interface re0

which result in the following routes (netstat -rn)

169.254.169.233/32   <re0's MAC Address>  US          re0

When added the VIP, the route became as follows:

169.254.169.233      link#1             UHS         lo0
169.254.169.233/32   link#1             U           re0

Pining 169.254.169.233 always pinging the local machine (the PF Box itself).

Should I remove the floating IP too?

Any ideas?

Thanks.

hopkins

This post is deleted!

johnpoz

@hopkins said in Routing 169.254 Networks:

but due to limited IP address space we own, they seems to think having a dedicated IP for a printer in a small office is a wasteful of resources.

Then put your printer on a rfc1918 and put it on its own segment and route... JFC some people shouldn't be allowed to touch a network. Or for that matter give it a rfc1918 address and now you could just run the multiple layer 3 on the same layer 2.. Vs using IP space this is not routable.

If they are limited with their space they own - then don't freaking use it internally then.. The whole F'ing point to rfc1918 space!!

If you give your interface a vip on that 169.254 network, you would not need to create a route... Just create a port forward using your lan interface and using your vip as the nat.

If I get a chance I will duplicate this moronic setup and post screenshots how to do it.

johnpoz

Ok: So I didn't forget about this... But didn't get to it last night. And wife still sleeping so didn't want to fire up the laser printer because it makes a bit of noise.. But I did get my wan L2 running through my switch - so I can no easy add anything to that L2 I want and duplicate your 169.254 nonsense on my 64.53.x.x public wan.

When I get back from walk will connect something with 169.254 and then try and access it from my lan behind pfsense.

johnpoz

Ok here you go - sorry for the delay... When got back from walk yesterday I got side tracked on other things then had to leave for work.

Set my printer to 169.254.2.50, connected it to my wan L2

Created a vip on my pfsense 169.254.100.100

Made sure pfsense could ping it

Created outbound nat rule

Created a port forward for ping to some odd rfc1918 IP that would send to 169.254.100.100 - you will need whatever port(s) your using for printing.

Then from my PC I pinged the portforwarded IP 192.168.20.50 in my case - and via sniff on wan while this is happening you see that pfsense changed that to its 169.254.100.100 address

Make sure you turn off blocking APIPA
JimP has a post here about it
https://forum.netgate.com/post/737766

Validate that is working by looking at your full rule set or looking in your system of your config - download that section via backup and look at it with fav text editor..

Good Luck - but you really should get with your IT to do this correctly!!! Such a setup is just plain BORKED!!!

edit: To to be 100% complete on this - check your full rules
pfctl -sr
If you see

block drop in quick inet from 169.254.0.0/16 to any label "Block IPv4 link-local"
block drop in quick inet from any to 169.254.0.0/16 label "Block IPv4 link-local"

In there which is the default then no its not going to work.. Check the above setting in your <system> part of the config and do your filter reload, then check your rules again.

hopkins

Thanks! It was very kind of you to post the steps and screenshots.
It is working and I can finally connect to my printer now!

I really appreciate for your help :)

johnpoz

Yeah never know when the next guy will have the same question ;)

Glad you got is sorted - but its still BORKED!!! dude.. Your IT guys need to rethink how they have their printer setup.. That is just nonsense to have to have users create route statements, etc.

hopkins

To be fair, I don't think they will do anything about it though. Regardless the network is borked or not, they won't modify the network settings for the one single guy who wants more security with a PF box. Especially when other (Windows) users doesn't have any issues.

Funny thing is, the printer seems automatically change its IP every few days, I guess I have to live with it and use IP Aliases..ha!

johnpoz

APIPA (169.254.x.x) is what is used when device is set for dhcp and it gets no dhcp, so yeah it could change whenever it tries to get dhcp again, or when its rebooted for sure, etc..

You would think they could take the time to actually just set a rfc1918 IP on the freaking thing - so its always the same IP..

You sure they even understand what its doing?

hopkins

I am not sure. But if the printer gets a RFC1918 IP (e.g. 192.168.x.x), I think it requires more configurations for my colleagues' Windows PCs, which means they (the IT guys) need to do more things, which means it is better to leave the network configuration to status quo. I don't think they really care if the network is f*'d up or not, as long as it works...

johnpoz

No it would require the same sort of shit nonsense with a route statement..

But it wouldn't be freaking changing as the wind blows.

hopkins

Hmm... I will try to talk to the IT guys later if possible.
In the meantime I think I probably will need to stick to current configurations.
Thanks again for your help. You really did save the day!

hopkins

Sorry for bumping up the old post.
After upgrading to 2.4.5, I cannot reach the printer anymore.

It seems that I can ping it on the pfsense box, but not on the NAT IP on LAN.

When pinging 192.168.200.1 (Printer is at 169.254.169.100, VIP of my box is 169.254.100.100/16) from 192.168.1.4:

It seems that there is no response:

I have confirmed that no_apipa_block is set to true, and

pfctl -sr

shows no blockage for packets in 169.254.0.0/16

Any ideas what is going on?

Thanks

hopkins

@hopkins Got similar issue for users upgraded to 2.4.5, not sure if it helps to diagnostic the issue:
https://www.reddit.com/r/PFSENSE/comments/fq8t8f/245_breaks_apipanat_rules_for_me/

johnpoz

And clearly that redmine was rejected..

johnpoz

@hopkins said in Routing 169.254 Networks:

shows no blockage for packets in 169.254.0.0/16

To talk to something on another vlan that is using apipa, that device would have to have a gateway.. Or you would have to nat to it, etc.