VLAN with Synology RT600AX in AP mode

[Tobanja]

I feel compelled to just add that with the new unifi AP, wireless isolation works. But not before disabling the tailnet completely on the test device (the phone). I feel bad making such a mistake, but I believe Tailscale has been sneaking behind my back, creating a backdoor into the LAN without me noticing. Anyway, that wraps up this horror episode, and we can all go back to living happy lives.

The story does not tell if the AP purchase was completely unnecessary. Blaming the synology AP might have been unfair. But I'd rather leave this all behind for now.

[nero355]

I feel compelled to just add that with the new unifi AP, wireless isolation works.

NICE!!! :)

But not before disabling the tailnet completely on the test device (the phone).
I feel bad making such a mistake, but I believe Tailscale has been sneaking behind my back, creating a backdoor into the LAN without me noticing.

Tailnet = TailScale and it was runnning all the time or something ?!

Please explain, because I have no idea what you mean exactly ?

Anyway, that wraps up this horror episode, and we can all go back to living happy lives.

The story does not tell if the AP purchase was completely unnecessary. Blaming the synology AP might have been unfair. But I'd rather leave this all behind for now.

IMHO you did the right thing, because the Synology seems very "features limited" without resorting to flashing it with alternative firmware if that's even possible ;)

[Tobanja]

Sorry, I'm too stupid to figure out how to quote you properly here.

But yes, I had a tailnet network that was active on my test device, the phone, and also opnsense. However, on opnsense, I allowed it to"advertise subnet routes" so I basically could use opnsense as a springboard to reach all LAN devices from WAN. I do believe this was the issue, because if I understand Tailscale correctly, it uses the tailnet to connect if the other routes are blocked (like in my case with blocks to 192.168.0.0/16). Also, all pings from the phone - although it was on the correct network - always emanated from the opnsense IP (192.168.1.1) to the ping destination IP. This bugged me for many days since I was pinging from the phone on the 192.168.50.x-network.

With this being said, I am still not 100% sure if this was the only issue, since other things have been flaky as well. For instance, I read somewhere that with an Omada switch, you are sometimes required to completely reboot it for some changes to take effect. And also, I had the IoT VLAN configured with a "DHCP Server Device" active which I have now removed to make sure opnsense is in charge for anything DHCP related. The VLAN now operates as "a pure Layer 2 switching network", according to Omada. Seriously though, there are many different settings at play, it's easy to mess something up for a beginner I suppose.

I am way over my head here, but I have learnt so much during my failed attempts.