Can't ping OPT [solved]

[jg3]

I can't ping the OPT interface and I am seeking help to discover why. I mean I can't ping the local OPT interface IP from the local shell.*
I have an any-any-accept firewall rule on the OPT interface. I do not have any NAT rules.

I have a pair of Netgate 1100s that I will set up in HA. I'm hoping to have the OPT interface directly connected between them for config updates. They are both behaving the same way.

I reset them to factory default this morning to get started on my project. They are current on 24.03 (patch 1).

The LAN interfaces can ping each other, ping to other addresses, ping from other addresses, no sweat. OPT seems to be behaving differently and I can't figure out why.

Any pointers would be very appreciated!

The WAN interfaces are disconnected.

*edit: I can ping the local OPT interface address using the webUI Ping feature, or from the shell if I use the -S option to ping with a specific source address. I still cannot ping the IP on the directly connected OPT interface of the other device.

[jg3]

Additional detail:
The OPT interface configurations are largely defaults: Enable is checked, Static IPv4 address, block private is unchecked, block bogon is unchecked.

[johnpoz]

@jg3 you're saying you set this as static ip?

Why would you have picked that 169.254 address? This is APIPA/Link-Local IPv4 address space.. To be honest I would think pfsense would complain..But it doesn't seem too..

But yeah your not going to go anywhere with that address space, there are default hidden block rules

cat /tmp/rules.debug

# block IPv4 link-local. Per RFC 3927, link local "MUST NOT" be forwarded by a routing device,
# and clients "MUST NOT" send such packets to a router. FreeBSD won't route 169.254./16, but
# route-to can override that, causing problems such as in redmine #2073
block in  quick from 169.254.0.0/16 to any ridentifier 1000000101 label "Block IPv4 link-local"
block in  quick from any to 169.254.0.0/16 ridentifier 1000000102 label "Block IPv4 link-local"

You would have to allow for that in Advanced / Firewall & Nat settings

But you have all of rfc1918 space to use - that choice is not a good one..

Why would you want a network under the link-local space 169.254.0.0/16 ? Are you planning to use this as a transit/connector network to some other router? Again you have all of rfc1918 to work with, I wouldn't choose that range.. Use something 10/8, 192.168/16 or 172.16/12

[jg3]

@johnpoz Thanks! It would have been a LONG time of guessing before I found that option.

I'm using the "This Net" space for exactly what it was intended for, point to point networks where the addresses will never communicate beyond the local network. I did that out of habit.

I figured the un-checking to block private and block bogons would have covered that.

Incidentally, do you know if this option to "Disable all packet filtering" would have achieved the same result?

I'm not using these guys for firewalling, just a reliable DNS, DHCP, NTP, Cert Auth.

[johnpoz]

@jg3 I would assume so because turning off the firewall would not load any of the rules. But have never done such a thing, been in networking a really long time, and have never used 169.254 - we always just use a /30 out of range we set aside out of rfc1918. Or public space that we own, etc.

[jg3]

@johnpoz Reall appreciate the assistance. I can't figure out how to edit the topic title to "solved" if that's a thing here.

[mvikman]

@johnpoz I just tested making an interface with IP from APIPA range , no notification about it being an "invalid" IP...
As the APIPA range probably isn't known to all users and there's a hidden block rule, pfsense should check and notifify this, especially when the "Allow APIPA traffic" setting is not checked.
Maybe this should be flagged to the devs (I don't have redmine account myself)?

[johnpoz]

@jg3 I marked is solved for you - but in the future edit your first post and edit the subject

[mvikman]

@johnpoz Not a topic I started, it was @jg3
I just chimed in on the pfSense not notifying about APIPA :)

[johnpoz]

@mvikman oh sorry - I must of hit reply on wrong post, corrected ;) thanks

Good idea about redmine, I will look to see if anything in there already - and not make the suggestion