RPI stopped working after ISP changed the modem

Bob · December 19, 2022, 2:27pm

I had followed and successfully implemented the steps in this guide to bridge Zerotier to local router, until I was forced by my ISP to change the modem/router.
Now I don’t have access to configure it (which seems to become a standard practice), so I had to ask them to configure the router IP and its DHCP range.
I understand I they have implemented the necessary configuration, just as mentioned in the guide above. But since then Zerotier Bridge has stoped working.

Whenever I scan my network I can find a dynamic IP address associated to the WIFI of the RPi, but the static IP for the ethernet does not show up. I can still SSH to the RPi. And remote computers on the same Zerotier network can ping the Ethernet. But the remote node cannot ping anything behind the RPi.

Do you know if there is any additional config such as firewall permission, opening ports or similar that I need to implement the Bridge?
Should I be asking myself some other question?

zt-travis · December 19, 2022, 5:59pm

Hello,
that’s not very nice of them…

Do the subnets of the router/lan and of the zerotier network still match?

You could post the output of ip addr and brctl show on the pi here.

Bob · December 19, 2022, 8:38pm

hey Travis, thanks for the reply.

All IP related configuration is supposedly Ok on the router. Every IP is on the range 192.168.0.65 up to 192.168.0.126. I basically copied the Guide.

So ZeroTier Central has the Managed routes being: 192.168.0.0/23(LAN) and auto-assign on the range: 192.168.0.129 to 192.168.0.190

The router has the gateway on 192.168.0.65 and subnet mask: 255.255.255.0.

I can manually assign an IP to my phone for example and the router will accept the IP will show on Fing device search for example. But when I manually assign an IP to br0 it won’t show up on Fing.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 02:42:17:2c:4c:46 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:42:17:2c:4c:46 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global noprefixroute br0
       valid_lft forever preferred_lft forever
    inet6 fe80::2f1:e797:6b73:414e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 96:87:e4:64:1e:87 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.115/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 57723sec preferred_lft 57723sec
    inet6 fe80::9627:f77:3d17:5c6e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
5: ztyqb2g4av: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether c2:5e:31:04:88:ad brd ff:ff:ff:ff:ff:ff
    inet 172.25.74.60/16 brd 172.25.255.255 scope global noprefixroute ztyqb2g4av
       valid_lft forever preferred_lft forever
    inet6 fe80::45bb:1e5:5193:f5b8/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
6: ztwdjezd5y: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether 8e:8b:37:e5:a2:44 brd ff:ff:ff:ff:ff:ff

Network 5 is a straight-forward ZeroTier network and it is working as expected. Network 6 is the one that stoped working.

brctl show result is here:

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

zt-travis · December 19, 2022, 10:47pm

Thanks. I was hoping something would jump out from the output, but… nothing did. It looks normal as far a I can tell.
I can’t think of anything needing to change on the pi just because the internet gateway device changed.

Is the pi plugged directly into the router, or is there a switch? Can you restart the switch? That’s a wild guess.

Bob · December 20, 2022, 2:39am

Come on, Travis. You are my last hope

Is there some package filtering, or routing rule the ISP could enforce that would prevent the bridge?

I’m considering two options now:

creating a lan behind lan and setting up the bridge on a router I really control;
clean install of the RPi and reinstalling everything.

But I really don’t know what variables I’m crossing out.

Anyway, thanks for the help and attention!

Bob · December 20, 2022, 2:41am

Sorry I didn’t answer you: the Pi is connected via Ethernet to one of the 4 ports of the modem. I’m using 3/4 and just switched the cable to see if anything changes.

zt-travis · December 20, 2022, 11:34pm

I don’t think so? I don’t see how. Maybe the router doesn’t like the bridged traffic somehow? I’ve only done it with a switch. router → switch → devices

Has the pi been just rebooted?

If you plug another router into the isp router, you’ll have a different set of “double NAT” problems. Not just for zerotier.

It may have a way to put it in “bridge mode”, many ISPs modems do that. Then you can plug a better router into it.

Bob · January 3, 2023, 6:01pm

Coming back to explain what I’ve found out so far:

I deleted all the .network files and re-wrote them according to the guide.
I used nmap to map the local network and found out that whenever I used eth0 I was able to see the Zerotier network, but none of the local network. And when I used nmap -e wlan0 I was able to see the local network but none of the Zero Tier. Important to note that the wlan0 is provided by APs that are different, but within the same network, as the router.

So my best guess now is that there is some settings on the ISP router that blocks traffic from one port to the other.

To work around this, I’m trying to add wlan0 to the br0 along with eth0, but for now this haven’t generated the desired effect.

system · February 2, 2023, 6:02pm

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