My router gets a 192.168.0.0/24 IP from my ISP's "modem" (sigh) and then my clients get a 172.168.0.0/24 IP from OpenWRT. While not very elegant, this double NAT worked fine for years until yesterday, when my clients suddenly started getting 192.168.0.0/24 IPs. I can only assume that my ISP changed something (DHCP authoritative?) because this used to work with mostly default OpenWRT settings.
The router is a TP-Link Archer C7 v2 with OpenWRT 18.06.1. After resetting to default settings, the issue persists. It occurs both with wired and wireless clients. I've enabled "Force DHCP" on the LAN interface but that hasn't helped. In dhcpdump, I consistently see DHCP responses for both subnets, and clients prefer the ones from my ISP. Perhaps they were already there before, but I don't think they should hit the LAN, right?
According to the ticket I posted above, it did get fixed, but then a bunch of people were still seeing it.
What's the intended behavior? Am I supposed to change a flag?
This shouldn't happen, even if the upstream DHCP server is in authoritative mode. Something is wrong with your OpenWrt installation, hopefully just a configuration issue.
First things first, check to make sure you're fully up to date with the latest version (18.06.1). If not, perform the update and see what happens.
If that doesn't fix it, post the following files:
/etc/config/network
/etc/config/firewall
/etc/config/dhcp
Also, you could try backing up your configuration and then performing a factory reset... resetting everything to defaults should give you a working config right out of the gate (using the 192.168.1.0/24 network which will be fine since your ISP modem is working on the 192.168.0.0/24 network). If that works, you can try restoring your saved configuration, and see if things still work or if it breaks again (in which case, you know for sure it is something with the config files; you can then try recreating or restoring the files in a systematic way to find out which one is causing the issue).
As I mentioned, I tried a factory reset earlier today. After I connected my laptop over UTP, I immediately got a 192 IP, so I think it's broken out of the box somehow.
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
config rule
option name Allow-DHCPv6
option src wan
option proto udp
option src_ip fc00::/6
option dest_ip fc00::/6
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
config include
option path /etc/firewall.user
Note that I didn't edit any of these directly. What I did do was:
Change the router's IP from 192.168.1.1 to 172.168.0.1.
Add 1.1.1.1 DNS.
Move ports 1 and 4 from VLAN 1 to VLAN 2 because I don't want those on the LAN. It's basically a lightweight version of this issue. However, I've rolled that change back (you can see all four ports are in the same VLAN) and the issue already occurred before I'd applied it.
Sorry, by "I immediately got a 192 IP", I meant that when I connected the client machine over UTP right after a factory reset, I got a 192.168.0.0/24 IP from my ISP rather than a 192.168.1.0/24 one from OpenWrt. I had to manually assign 192.168.1.x to the client to get to luci for initial setup.
Nothing jumps out at me as problematic in your config files.
The bug you mentioned is 8 years old, and I haven't personally seen any recent reports of this issue in general as well as for this device (and this is a very popular router model).
Can you confirm that you are on 18.06.1 from the official release builds on the OpenWrt downloads page? It might be worth re-flashing just to make sure it applied correctly.
Also, just to make sure you're really connecting through the C7 -- please verify that you are connected via ethernet and that wifi is turned off on your computer. This will ensure that there is no other means of network connectivity other than through the C7.
What happens if you don't connect the WAN? Will your computer get an IP address via DHCP from the C7? When you connect the WAN, does it then suddenly get DHCP in the 192.168.0.0/24 network?
Thanks again for all the pointers. I did try another flash, with 18.06.1 and then 18.06.0 to rule out any regressions. That didn't help.
However, it turns out I was looking in the wrong place. Hindsight is 20/20.
After unplugging the uplink, I suddenly noticed that I still had internet access on my client machine. So I unplugged the remaining client cables and reinserted them one by one until there was some sort of uplink. That made me realize that the culprit was actually my ethernet-over-power extender to another room. Somehow, that segment contained a modem from my ISP (the market leader), but apparently not actually mine!
I live in an apartment and I can only assume that a neighbor also has ethernet-over-power plugs. It's pretty bonkers that the circuits aren't isolated from each other, but securing my segment better by re-pairing the plugs did obliviate the mysterious DHCP reply.
I'm still going to follow up on how a neighbor's modem can be connected to my power outlets, but obviously, that's not an OpenWrt problem. Again, thanks for all the help!