Question

Hi

I have a routing problem with accessing clients direct connect to the LAN side of RUTX11. I am using Zerotier with a managed route to connect to all IPs on the LAN. Network config uses 1 DHCP server in the router, there is only 1 subnet for L2 design. All devices can access the internet inc mobile phones and tablets, PCs etc. SIM card is private IP.

Using Zerotier from remote (my home) I can access all the devices highlighted in Green but none of the Red ones. I can use Mikrotik Android App and Windows Winbox to access all green WAPs and also web browser.

I have setup port forwarding so that the NVR App works from remote -  this works great.

All DHCP leases show correct in the RUTX11 as with 3 static IPs. Some of the green devices use static some DHCP so its not this. All Mikrotik WAPs are identical config and were all bench tested along with PTP before site install.

Latterly, I have configured the WAN ethernet port to be LAN as per Teltonika instructions. My problem existed before this.

Do I need to forward ports 80, 8291 from WAN to LAN but why do the devices behind the PTP link and the AP_Base work ok?

Thanks
C

Answer 1

Hi,

It seems like the bridge connected devices have their own "instances" through which you are allowed to connect remotely, so as those are routed through ZeroTier - they're available without any additional port forwarding or so. On the other hand, on the left of your topology, those 2 addresses are connected straight to RUTX11 so it might be that they're not included in the routing for some reason, but if you port forward the ports of those two from WAN to LAN, you should be able to reach them through RUTX11 LAN IP / ZeroTier given IP plus the port you've defined.

EB.

Comments

EB

Thanks. Very strange, only a few mins to look at this today, I did try to forward ports to a couple of devices but no luck. I need to do some more testing..i'll get back to you.

C

---

Hello,

It is probably a default route issue on the "red" devices. The simplest solution is to allow Zerotier->Lan forwarding and enable Zerotier masquerading in the RUTX11's firewall settings. I do that for wireguard tunnel and it works perfectly.

Are the "red" devices configured via DHCP or are they static ?

Regards,

---

@flebourse

I tried enabling masquerading but no luck...

Your question about IP assignment is both DHCP and static.

Testing this morning onsite when I'm connected to my wifi AP_Base (hardwired) to RUTX11, this is not the router internal wi-fi by the way, I can connect no problem.

Maybe I need to reboot to test masquerading..?

Thanks for your help
C

---

Hello,

"I tried enabling masquerading but no luck..." but did you set the Zerotier=>Lan Forward box to Accept ?

To try to debug this you can do a tcpdump -i any -n -v 'icmp' on the RUTX11, ping one of the "red" devices and see if there is a suspect icmp packet appearing - a network unreachable or the like.

With masquerading, you won't need to perform port forwarding anymore, the system will become "transparent".

Regards,

---

@flebourse

Well PING reveals all! I can't ping any of my red devices from RUT CLI, but green ones no problem. But I can ping the red devices...

I have tried to add a static route 192.168.1.0/24 via my 'Zerotier address' but no luck finding how I can set those parameters in the GUI.

I tried new interfaces/zones etc nothing works..

Yes I set the LAN forward rule to Accept...
 

Somehow route output does not read correct, why is gateway column empty? i.e. all '*'

[email protected]:~# route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

default * 0.0.0.0 U 1 0 0 qmimux0

10.231.93.255 * 255.255.255.255 UH 1 0 0 qmimux0

192.168.1.0 * 255.255.255.0 U 0 0 0 br-lan

192.168.192.0 * 255.255.255.0 U 0 0 0 ztks5wilpe

[email protected]:~#

---

That's strange indeed.

1) for devices configured via DHCP, do you set the default gateway option (3) ?

2) do the tcpdump as mentioned above, and ping one of the "red" devices. What does it say ?

Regards,

---

Hello

Here is the PING output from three devices, my gateway, one of my WAPs (which is assessable) and then a WAP which is not assessable (.166) which results in no return of information 100% packet loss and I have to CTRL C to exit.

OK new info. I have fixed the ping issue by adding a ICMP forward rule from Zertier to LAN. So then I saw how to add a forward rule for Mikrotik Winbox (8291) from Zerteir to LAN but this did not allow me to access on LAN as I hoped and made it even worse as devices behind bridges were also not availble either. So the port forward works to capture the incoming WinBox packets on zerotier by dumping them in the LAN bu they seem lost in a black hole.

Re your question about DHCP devices, I have tried setting the Gateway address in the LAN interface if this is where you mean but this does not help. Remember all these devices that I can't access by remote route DNS requests all day happily providing internet.

[email protected]:~# ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 56 data bytes

64 bytes from 192.168.1.1: seq=0 ttl=64 time=0.366 ms

64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.274 ms

64 bytes from 192.168.1.1: seq=2 ttl=64 time=0.256 ms

^C

--- 192.168.1.1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 0.256/0.298/0.366 ms

[email protected]:~# ping 192.168.1.188

PING 192.168.1.188 (192.168.1.188): 56 data bytes

64 bytes from 192.168.1.188: seq=0 ttl=64 time=1.832 ms

64 bytes from 192.168.1.188: seq=1 ttl=64 time=1.555 ms

64 bytes from 192.168.1.188: seq=2 ttl=64 time=1.641 ms

^C

--- 192.168.1.188 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 1.555/1.676/1.832 ms

[email protected]:~# ping 192.168.1.166

PING 192.168.1.166 (192.168.1.166): 56 data bytes

^C

--- 192.168.1.166 ping statistics ---

23 packets transmitted, 0 packets received, 100% packet loss

[email protected]:~#

TCPDUMP

[email protected]:~# tcpdump -i any -n -v 'icmp'

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

16:40:05.164251 IP0

16:40:06.545256 IP (tos 0xc0, ttl 64, id 16599, offset 0, flags [none], proto ICMP (1), length 193)

192.168.1.1 > 192.168.1.1: ICMP host 195.181.173.159 unreachable, length 173

IP (tos 0x0, ttl 64, id 50037, offset 0, flags [none], proto UDP (17), length 165)

192.168.1.1.9993 > 195.181.173.159.9993: UDP, length 137

16:40:06.545338 IP (tos 0xc0, ttl 64, id 16600, offset 0, flags [none], proto ICMP (1), length 193)

192.168.1.1 > 192.168.1.1: ICMP host 195.181.173.159 unreachable, length 173

IP (tos 0x0, ttl 64, id 50038, offset 0, flags [none], proto UDP (17), length 165)

192.168.1.1.43734 > 195.181.173.159.9993: UDP, length 137

16:40:06.545398 IP (tos 0xc0, ttl 64, id 16601, offset 0, flags [none], proto ICMP (1), length 193)

192.168.1.1 > 192.168.1.1: ICMP host 195.181.173.159 unreachable, length 173