Accessing 169.254.2.1:80 on an OPT interface from the LAN interface
-
|=Hello everyone,
I'm using pfSense as router for single LAN.
I'm using my ISPs CPE router (Telekom Speedport Smart) in modem mode. The CPE has 4 LAN ports.
When you switch it to modem mode, Port 1 starts acting like a bridge. I have connected it to the WAN interface and set up PPPoE on it and all of that works fine.
The other 3 ports now host the web interface, which I want to access from the LAN to look at the DSL line stats. In modem mode, the web interface is only reachable at 169.254.2.1 port 80.
I can't change that IP and the firmware is signed.I have connected one of the ports hosting the web interface to opt1 and configured opt1 with the IP 169.254.2.2/24, no gateway, no blocking.
I would like to access 169.254.2.1:80 from my LAN (10.0.0.0/24), while still treating opt1 as hostile because my ISP could theoretically remote flash firmware on that modem, which makes me think the right way to do that would be NAT.
The first problem was the pfSense refuses to route all traffic from/to 169.254.2.1 because it's the APIPA subnet. I solved that by adding <no_apipa_block></no_apipa_block> to the config file.
Now I can successfully access 169.254.2.1:80 from the pfSense box itself (tested using a CLI browser).
But I still can't access it from my LAN. I tried Outbound NAT, 1:1 NAT with a virtual IP and a port forwarding rule. No outgoing traffic ever appears on the opt1 interface. Meanwhile it's not blocked by the firewall because the attempts don't show up in System Logs>Firewall either.
My current configuration is the outbound NAT rule I attached. "MODEM" is opt1.
But I'm open to suggestions as to what would be the best way to get this to work.
Current config:
=| -
Those 169.254 link local addresses are not routeable, so you'll never see them on a different interface.
Normally, you'd only get that sort of address when DHCP fails.
-
@jknott said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface:
Those 169.254 link local addresses are not routeable, so you'll never see them on a different interface.
Normally, you'd only get that sort of address when DHCP fails.
They only become unroutable if the there is something in the pfSense source that makes it so.
I see them only mentioned here and that disabled by the no_apipa_block setting I mentioned. -
Routing requires a router address. Do you have on on that device?
-
Do you mean the opt1/modem interface? It is set to 169.254.2.2/24. And I can access the modem UI from the pfSense box itself.
-
@warudo said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface:
Do you mean the opt1/modem interface? It is set to 169.254.2.2/24. And I can access the modem UI from the pfSense box itself.
No, the device that's going to try to send packets to another network needs a router address, often called gateway address. For example, your computer will have a default route that contains the address of the router. To understand why this is necessary, you have to understand the difference between sending packets to devices on the local LAN and elsewhere. When your computer, or other device, wants to send a packet to an IP address, it compares the local network address with the destination address, which is logically anded with the subnet mask. If the two are the same, it's local and if different it has to be sent via the gateway. If local, the computer will do an ARP request for the destination IP address and the device that address is assigned to will respond with it's MAC address, which is then used to transmit the packet. If the destination is not local, then the computer forwards the packet to the router or gateway, which in turn determines where to send it. The same ARP process is used to determine the MAC address of the router. If the destination is not local and the transmitting device doesn't have the router address, what does it do with the packet? It can only discard it and return an error message.
Earlier today, I even tried a little experiment. I configured my notebook computer so that it would get a 169.254 link local address and then, while connected to my LAN, tried pinging my desktop computer. I got an error message stating that the destination was unreachable, as was expected.
-
Yep
What JKnott said above.
Some authors do in fact (when writing their particular software) do in fact set different standards to different types of IP addresses.
You just dont know who does or does not. Since your chosen address is not part of the RFC.. You know- the one that sets private IP address space.. You can not be sure it will always work and you could be setting yourself for failure.
http://lmgtfy.com/?q=rfc+1918+addresses
-
@jknott said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface:
No, the device that's going to try to send packets to another network needs a router address, often called gateway address.
Tried that:
ip route add 169.254.2.0/24 via 10.0.0.1 dev eth0on the host trying to access it. 10.0.0.1 is the pfSense box.
I can see the packets arriving on the pfSense box using packet capture, I see in the firewall log that they aren't blocked but pfSense doesn't do anything with them.@chpalmer said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface:
your chosen address
It's not like I chose it. I know this configuration is a very bad idea. As I said in the OP, it is forced on me.
My current workaround was to install squid on the pfsense box and use that proxy to access it.
-
If you set a VIP on the WAN in the 169.254 subnet and were outbound NATing traffic to it for that subnet the 'modem' would not need a gateway. You can't set a gateway on many of those devices anyway.
Do you see connections opening for that subnet at all? In the state table for example.
It seems possible your client is refusing to route that traffic to it's gateway.
Steve
-
@stephenw10 said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface:
Do you see connections opening for that subnet at all? In the state table for example.
I can see the following when trying to access the webinterface:
LAN tcp 10.0.0.10:50078 -> 169.254.2.1:80 CLOSED:SYN_SENT 3 / 0 180 B / 0 Band this when pinging:
LAN icmp 10.0.0.10:3803 -> 169.254.2.1:3803 0:0 15 / 0 1 KiB / 0 B10.0.0.10 is the client.
-
Hmm, but no states on the MODEM interface? I assume you do see states there if you ping from the firewall itself or use the proxy to open a connection?
My comment about a VIP on WAN previously doesn't apply here as you're connecting via a separate interface to a different port on the modem.
It looks like the APIPA tag is not set correctly perhaps if it's not routing between those subnets. Though you said it blocked all traffic before applying it.
Steve
-
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. -
Hmm, you may be able to override that with route-to.
https://redmine.pfsense.org/issues/2073Try adding the modem IP as a gateway and that adding that gateway to a rule passing the traffic on LAN.
Steve
-
@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).
