Same subnet address on LAN and WAN side does not work - why?
When I first set up my pfSense box, I put it between my internal network and my internet provider's router. Resulting in networks like this
Fibernet modem / router
| (192.168.1.x network with two active addresses - gateway 192.168.1.254 and my device / firewall 192.168.1.217 on WAN interface)
| (192.168.1.x network with all my own devices - on LAN interface
This means both the WAN (igb0) and LAN (igb1) ports have the same subnet ranges. DHCP addresses are given out on the LAN side but nothing works - can't even ping the pfSense firewall or access web interface.
Some would say - that is obvious - how is it supposed to figure out how to route between two identical networks? BUT, the 192.168.1.x range is non-routable - so it should never route anything between these two networks. Only in the case of going to the internet the firewall should route data from internal addresses through the gateway 192.168.1.1 on LAN side and then through the WAN network to the fibernet modem (192.168.1.254) as gateway to the internet and things coming back should be received on 192.168.1.217 on the WAN side and delivered to the client on the LAN side. Why does it not work? Is it because pfSense (and Linux boxes in general ) can only differentiate different interfaces by their subnet addresses?
"Non-routable" applies to only from the global perspective. RFC1918 addresses are not routable over the internet but locally all the rules for routing still apply, you can't have conflicting routes on the routing table or the system won't have a clue which interface/gateway it should send the the traffic to.
Do not confuse "non-routable" with "link-local". The behavior you describe is not the behavior of RFC1918 networks, as @kpa explained. What you describe is "link-local" behavior, which for IPv4 is the APIPA range,
169.254.0.0/16and for IPv6 is
Even then IPv4 doesn't work properly with the same subnet on two different non-bridged interfaces. IPv6 works because it has interface scoping which gives the OS a nudge to know how to reach specific addresses even when there would otherwise appear to be a conflict.
@kpa Thanks. I thought you could never address a 192.168.1.x address and similar outside your own subnet. Then it makes sense why the firewall would have an impossible task managing a setup with two similar subnets.