@warudo said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface:
I did some digging through the FreeBSD sources.
While the blocking of this subnet can be disabled in pfSense and causes it to respond to packets, the underlying FreeBSD TCP/IP stack is hardcoded to not forward traffic from and to it. The relevant part is here.
So this seems to be impossible.
Of course it's impossible, it's against the RFC to do that.
https://tools.ietf.org/html/rfc3927
Section 2.6.2
[...]
The host MUST NOT send a packet with an IPv4 Link-Local destination
address to any router for forwarding.
Section 2.7 Link-Local Packets Are Not Forwarded
A sensible default for applications which are sending from an IPv4
Link-Local address is to explicitly set the IPv4 TTL to 1. This is
not appropriate in all cases as some applications may require that
the IPv4 TTL be set to other values.
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. Similarly, a router or
other host MUST NOT indiscriminately answer all ARP Requests for
addresses in the 169.254/16 prefix. A router may of course answer
ARP Requests for one or more IPv4 Link-Local address(es) that it has
legitimately claimed for its own use according to the claim-and-
defend protocol described in this document.
This restriction also applies to multicast packets. IPv4 packets
with a Link-Local source address MUST NOT be forwarded outside the
local link even if they have a multicast destination address.
As @stephenw10 said maybe if you had a VIP on WAN in 169.154.x.x and you did NAT to that on the way out it might work, but it would likely still fail to be carried properly since the original host is violating the RFC by sending 169.254.x.x traffic to a router when trying to connect. I would not use a gateway or route-to on traffic to or from 169.254 -- See https://redmine.pfsense.org/issues/2073 for why.
What you might need is inbound NAT on the LAN of pfSense to map that 169.254 address to something actually routable.
LAN host -> destination LAN VIP -> exit WAN outbound source NAT to 169.254.x.x to destination of 169.254.x.x. The link-local stays local, no RFCs would be violated by that behavior (technically).