Help 169.254 Link-local
-
Hi to all,
i have a problem with my pfsense ( ;) ).This is the situation:
Pfsense LAN IP –> 169.254.2.1
Server IP --> 169.254.2.20
Pfsense WAN IP --> 55.55.55.55 (example)I try to ping 8.8.8.8
I create a FW ruel that allow all traffic from LAN to WAN. I strat tcpdump on WAN interface and LAN interface. I see the packet icmp request that cross the LAN interface, i see the reuqest on the WAN interface natted with public ip . On the outside interface i see also the icmp reply from 8.8.8.8.
But all the reply packets are stopped on the outside interface.
I natted the server on another public ip 55.55.55.56 (example), when i try to connect form internet tn the server in the TCP dump on the outside interface i see the SYN packet but the packet are stopped.In the wan interface configuration i deselected Block private networks and Block bogon networks option.
I also deleted from bogons file the 169.254.0.0/16 network.But the packet are still stopped on the outside interface.
Who can help me please?
Thanks a lot to all
Regards
-
169.254 are link-local addresses. http://en.wikipedia.org/wiki/Link-local_address
You should be choosing from the private network address space for your private LAN: http://en.wikipedia.org/wiki/Private_network -
^ agree, 169.254 would be a terrible choice for a local network address space.. Why was the default address pfsense uses for its lan not viable? I would suggest you get it working with that first.. Then you can think about changing your local network to something else in the rfc1918 space 192.168.x.x, 10.x.x.x, 172.16-31.x.x
-
thank for the replay.
I choose that network because i can use only that network.I migrating from vyatta that support this network on all the eth.
Is possible to use thi network with pfsense?
Is possible that there is a sort of kernel drop? If yes is possible to watch these drops?
Do you have any suggest about advanced troubleshooting?
thanks a lot
-
"I choose that network because i can use only that network."
And why would that be.. That is not a rfc1918 address - as shown already its a link-local address space - and should not be used for this sort of setup. It is designed for boxes to be be able to talk to each other via APIPA, and does not have a gateway via this method, so you can only talk to local devices on the same 169.254 address space..
Where did you get the idea that you can only use this address space?
-
It's a little bit long to explain, but in my environment i can't use the classic 10 192 and 172.
I swear that i can't use the classic network and i'm not writing here to waste your time, i really need help to solve this problem.
We must use 169.254.
The strange is that the pfsense allow the packets in the LAN interface, tha packets are also natted , but on the wan interface the packets are "blocket" , i don't know which process, module or what else block this packet.
It's the first time for me that a firewall have this behavior.
Any idea.
-
If your saying you see the traffic go out using the public IP, ie it was natted and you see the reply – but your saying its blocked??
Where is it blocked? Do you see it in the block logs? And you have bogon removed from wan, its should never be enabled on a lan interface in the first place.
Did this ever work? I can clearly fire up a segment using this network on the lan side.. I am curious to hell why you would think you can not use rfc1918 address space on your own network??
-
That's not a valid configuration. The fact Linux forwards link local doesn't mean it should work. It shouldn't. From RFC 3927:
An IPv4 packet whose source and/or destination address is in the
169.254/16 prefix MUST NOT be sent to any router for forwarding, and
any network device receiving such a packet MUST NOT forward it,
regardless of the TTL in the IPv4 header.http://tools.ietf.org/html/rfc3927#section-2.7
FreeBSD doesn't forward that traffic, the fact it goes outbound is a quirk, the reply hits the part of the OS that won't forward traffic that "MUST NOT" be forwarded per the RFC. I was recently contemplating putting in a block all 169.254/16 in and out rule in the back end.
You shouldn't be doing that, use RFC 1918 or the CGN 100.64.0.0/10 reserved space. Anything that follows RFCs isn't going to forward that traffic. Anything that does forward that traffic is broken.
-
johnpoz: i disable all the control on the WAN interface. but the packet that come back from internet example the ping reply from google are not forwarded to LAN interface. If you send me a private message i can explain because i use this network.
cmb: thanks for the reply, but if "FreeBSD doesn't forward that traffic" why the packet from LAN are forward to the WAN interface correctly and is also natted ? I see the reply from 8.8.8.8 to my ping but the replay is blocked on the wan interace.
I'm pretty sure that is the WAN interface that not forward the reply to the LAN….but if "FreeBSD doesn't forward that traffic" pfsense must block the packet on the LAN interface .
ii also disabled Block bogon networks on the wan interface and removed the 169.254 form the bogons file.
Other ideas???
thanks to all
-
Can i change something in the os to forward from WAN to LAN interface the 169.254 address?
Thanks a lot
-
Here is the thing, when you go out a state is created. The answer would be to that state and the firewall would allow the traffic.
Let me do a simple test using that network - give me a few minutes. BTW what mask did you use on that network /16 or something else - I will use /24 in my test. because from your IPs listed with the same 3rd octet I would guess /24
Well I have duplicated your setup.. While I can ping pfsense interface 169.254.2.1/24 and I do see the nat created and the reply to the ping that comes back on the wan, not seeing it go out the lan to the client on 169.254.2.20
Could be very well something in the guts of freebsd or pfsense that doesn't like these networks. I don't have bogon enabled, etc. But as already stated these are not valid networks to route - they are link local type addresses.
I will PM you for why can not use normal rfc1918 space.
-
LAN is 169.254.2.0/24.
Thank you -
It's hard coded into FreeBSD itself to not route that space, because it's not valid to do so. The NATed traffic just happens to bypass that check because it hits a "route-to" out which bypasses normal routing portions of the kernel, the reply doesn't and can't.
What you're attempting is fundamentally broken. The fact it ever worked should be written off, and you should implement a proper network.
-
^ agreed!!! link local address space should never be routed!! As previous mentioned.. I have validated it for you so its not something you did wrong, etc.
And not something you can expect pfsense or freebsd to allow for - whatever other system you were using that allowed that traffic to route is broken ;)
"Link-local addresses are usually not guaranteed to be unique beyond a single network segment. Routers therefore do not forward packets with link-local addresses."
Your going to have to rethink your whole product if you ask me - trying to create a connection outbound from that address space is going to be hit or miss.. And most cases should be miss.. Your customers routers should not nat that network even.
Why don't just have customers give that interface an IP that works in their network other than what the management interface is using?
-
Really thank a lot to all
