I was testing out using network-attached storage with Samba and an external drive connected to the USB port on my Beryl AX (GL-MT3000). On the LAN, everything works as expected.
Next, my plan was to set up a WireGuard VPN server on the router, and client on the phone. I wanted to try using Dynamic DNS instead of a fixed IP address. Again, everything worked as expected.
Issue
However, when I disabled the VPN on my phone, I noticed I could still remotely access the SMB drive on my router from the WAN. Furthermore, I could still access the GL.iNet Admin Panel GUI through the web browser on my phone from the WAN!
There was a similar issue in a this forum post, but the solution did not work for me.
I double-checked and made sure I had all remote access settings disabled.
I checked the firewall rules, and they were already supposed to block remote connections from the internet.
I even added extra rules to specifically drop SMB and HTTP/HTTPS traffic to the LAN/router, but nothing worked except for disabling DDNS.
The router seems to block remote connections trying to connect to its public IP address, but not the DDNS domain name.
Question
Is there something in the settings that I am missing? The router is supposed to block remote connections from the internet by default unless I enable them, right? Even so, why is the firewall not dropping remote connections from the WAN just because I enable DDNS? I never enabled any of the "allow from WAN" settings.
Does this happen for anyone else when they enable DDNS?
I made sure again to disconnect the Wi-Fi on my phone, and turned off and deleted any possible any VPN profile to router.
Again, to test, I went into my router admin panel, made sure no VPN was on, turned on Samba and made sure Samba didn't allow connections from WAN, and then turned on DDNS.
These are the screenshots from testing a moment ago on my phone.
Accessed the login from iOS Firefox and Safari on cellular network data.
If this truly is not supposed to happen, could it be a bug?
Edit: Important detail I forgot to mention, I actually don't have an agreement with my internet service provider for a static public IP address, so I can't assume it works the same as with the DDNS name.
Firewall doesn't support IPv6? I don't think that's correct. It would be very concerning if enabling IPv6 granted internet access to the admin UI on the router.
The default setup on my Slate includes rules for IPv4 and IPv6 protocols, both for forward and input ports. And the nftables config in luci shows both IPv4 and IPv6 configs (things like expressly permitting DHCPv4 and DHCPv6). If I create a new input port via the GL-iNet front end I get an IPv4+IPv6 open port rule in luci.
At any rate I can't replicate the problem that OP is seeing, at least using addresses. I don't use the provided DDNS service. With IPv6 enabled and a pretty clean config, I can't connect to a Slate by its external IPv6 or IPv4 addresses when its WAN port is connected to my home network. The default firewall blocks both connection attempts. Moving to the Slate LAN and I get to the admin pages. So it's not improperly permitting IPv6 TCP port 443 from what I can see.
u/HeyYouKidGetOffMyLAN - you might want to disable the DDNS config and try the same experiment by connecting to each WAN-side IP address as a test. This should show if the DDNS config is adding something to the situation. Oh, and you'll need to enter the IPv6 address with square brackets (e.g. http://[xxxx:xxxx::xxxx]/. See if it can still connect without the VPN enabled.
Right, there isn't NAT6 since you don't need address translation (there are enough v6 addresses for everything). So in the absence of rules to prevent it, ingress can reach hosts behind the router.
I'm not an expert on the GL-iNet specifics, but both the old iptables rules and newer nftables firewall rules do seem to filter IPv6 traffic. And in the case of the input_wan rule set they looked like this:
Allow x
Allow y
Allow x
Drop all
Specific allows (for both v4 and v6) followed by a drop, which is good. When I added an input or port forward in the GL UI it added an allow for both v4 and v6. And that's what I saw when I tested. The router wan and my PC lan on the same network, with IPv6 addresses, and the router admin UI was not reachable.
So it's interesting that they say there is leakage. Perhaps they don't want to have a bigger test matrix so they only test with v4?
Thank you for the suggestion. I tested it with the IPv6 address. From the browser, it seems to behave as expected: access to the router login page is allowed from the LAN, but not from the WAN. see update below
I'll also privately message @alzhao to continue troubleshooting this.
I made a dumb mistake when testing with the IPv6 address the first time (incorrect IP).
Anyway, I turned off DDNS and tried accessing the login panel from the WAN by IPv6 address in the browser in my phone. And, uh oh, I was able to access it.
I'm going to reset the router, make sure the firmware is up-to-date, and try again.
Well I went back and tested again just to understand the options a bit better and it's interesting. When you enable IPv6 in the GL ui it does enable NAT6 but also offers a Native option. It indicates that if you choose native IPv6 routing, the guest network will still use NAT6. Guess I should have read the GL-iNet 4.x docs.
Either way, with Native or NAT6 set I was not able to hit the router admin website via IPv6 address from the WAN side. Only from the LAN. And that makes sense based on what I see in the firewall rules. Hopefully OP just had some non-standard config that explains their access via WAN.
Welp, I checked to make sure my router (GL-MT3000) is up-to-date on firmware (v4.6.2), reset it, and tested changes one-by-one.
It seems that turning on IPv6 (with NAT6 by default) is what opens my router up to the WAN.
This opens access to the router login page, and even the SMB share, if I use either the DDNS name or IPv6 address. However, disabling IPv6 stops that.
So, it may be as @admon suggested, and the firewall (and WAN restriction settings from within the GL.iNet panel) don't seem to work with IPv6 traffic on my router for some weird reason, but does for @cpunk.
