Tagged WAN not working in 22.03

Installing and Using OpenWrt Network and Wireless Configuration
1

My main router is a Netgear R7800 running Lede 17, and it has worked well for years. The WAN port is connected to an upstream switch that provides internet at VLAN 102.

On the R7800 the switch is configured to use VLAN 102 for WAN, and VLAN 102 is tagged both on the actual WAN port and on CPU (eth0), and this is working fine.

Now I am trying to upgrade to 22.03, and I have a second R7800 that I have manually configured to replicate the old router config. I was sure I had everything correct, so I just swapped the old R7800 for the new one. However, there was no internet connection, even if the WAN interface did aquire a connection to the ISP (all correct).

The routing table looks correct, and the firewall also looks correct. If I run tcpdump (on the router itself) on my WAN interface (eth0.102) and try to ping for example 8.8.8.8, I can see packets going out, but no replies.

I also tried defaulting the router, and only changing the WAN VLAN from 2 to 102 and making it tagged also on the WAN port. Same problem, so it is not some stupid config error I have done (I think). I even tried flushing the complete nftables ruleset to see if that made any difference, but it did not (I think that should basically leave the firewall open, right?).

Given that the router performs a correct DHCP to the ISP, traffic does flow both ways on the WAN interface, so there shouldn't really be a problem with traffic flow on WAN.

Also keep in mind that this is working on LEDE 17, and the config is basically identical now on 22.03, but no dice.

Not really sure how to diagnose this further, so any pointers would be appreciated. I guess trying OpenWrt 21.02 might be an idea, but even if that worked, I'd be none the wiser. I want 22.03 going forward.

2

Compare your 17.01.x config (/etc/config/network) with your new 22.03~ based one, apart from the ifname/ device changes and a slightly more verbose bridge setup, they should be almost identical (as ipq806x is still using swconfig and didn't move to dsa yet).

3

Yes, they are identical, the switch is configured exactly the same. Not that it really matters, as the problem is the same with the stock config if I just make the WAN VLAN tagged.

I just did the same test flashing a stock image of 21.02.3, changing nothing except making the WAN VLAN be 102 instead of the default 2, and making it tagged (instead of untagged) on the WAN port. It then aquires the address and DNS servers from the ISP, but there is no internet connectivity. I really wonder what I am missing here. Here's what the routing looks like, and an attempt to ping the outside:

root@OpenWrt:~# ip route
default via 79.16x.xxx.1 dev eth0.102  src 79.16x.xxx.xx
79.16x.xxx.0/20 dev eth0.102 scope link  src 79.16x.xxx.xx
192.168.1.0/24 dev br-lan scope link  src 192.168.1.1
root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

Routing looks correct to me, and I have not touched any firewall settings from the defaults.

If I connect the WAN port of this new router to one of the LAN ports of my running router (and make the WAN port VLAN untagged), it will aquire an address on my LAN, and I can communicate from the inside of the new router to the WAN side (which is then my main LAN, of course).

4

Ok, so this one turned out to be weirder than I had thought. Thankfully, the issue has nothing to do with OpenWrt at all.

What happens is that the ISP maintains some kind of MAC address lock, so even if the new router can perform a normal DHCP, the ISP will not let any other traffic flow. If I spoof the MAC address of the old router, it all seems to work just fine.

However, this is still a catch22, in the sense that I don't really want to spoof the MAC, but since I don't know when that lock expires, I will have to stay disconnected from the internet, and just periocally try reconnecting with the new MAC until it works. Not great.

5

Since you don't want to spoof the MAC: Have you contacted your ISP, asking for unlocking or changing the MAC adress from mac_old -> mac_new?
In my case, I had to call the cable provider, giving them the new MAC, and after IIRC 2h I had internet access again with my new cable modem.

6

I can see that whenever I renew the lease, I don't actually get a new lease time, the lease time I had before continues. I am pretty sure that if I make sure to disconnect just before the lease time expires, and then remove the spoofed MAC and reconnect, I will be fine again.

I did speak to a contact at the ISP who has some knowledge about these things, and it seems plausible that the above is true. I guess it might also be possible for someone at the ISP to manually unlock, but I don't care if my above mentioned method works. If it doesn't, I'll have to contact them in a more official way.

I'll know in just a few hours. :slight_smile:

7

It's ISP specific how long they lock on the stale MAC address. In practice, anything is possible - from just a distinct reconnect (modem/ ONT reboot), 10-15 minutes, an hour, over night up to calling them by phone and requesting a manual port reset.

Personally I'm in the more than an hour, less then a full night camp (haven't been able/ willing to pin-point this further). In order to avoid this for the future, I'm spoofing a MAC address of a broken device, avoiding the native MAC of any of my routers.

8

Sure, and if I can't get it to connect with the new MAC as I outlined above, I might just keep spoofing.
However, I find it perhaps a bit strange that they do respond to the DHCP request, even if no further traffic is allowed.

9

Both approaches are sadly common among ISPs, either rejecting the DHCP lease or granting it, but then blackholing the alien MAC/ IP.

10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.