Posted: Fri Feb 17, 2023 4:20 Post subject: bug in Setup-> Networking r51306
Router is Linksys wrt1900acs v2.
Firmware: DD-WRT v3.0-r51306 std (01/15/23).
Is this a known bug ?
I have 2 wireguard tunnels (oet1 and oet2), both running fine.
In the Setup-> Networking tab,
When I enable "Massquerade / Nat", and then SAVE, the screen does change to indicate my selection. However - "apply settings" or a "reboot router" will ALWAYS undo that selection, putting it back to "Disable".
1. This problem does not appear on Netgear R7000, ie a non-Marvell router.
2. As there seems to be no way, given this problem, to enable this setting by the GUI is there some manual way via stored commands in Startup or Firewall to enable this on the Linksys router ??
The R7000 is a slightly older build: Firmware: DD-WRT v3.0-r47911 std (12/23/21)
Yes, the R7000 also has 2 wireguard tunnels, identical configuration, going to same VPN provider (a different account of course). The tunnels are used in exactly the same way at the R7000 site, and both sites have near identical configuration (eg same IP addresses).
And yes, I am checking every possible difference. Because the routes (iptables commands in firewall), while being identical, do not operate with same behavior in both sites.
The R7000 site has the Masquarade/NAT "enabled".
But is impossible to do that on the Linksys.
Why do I want it enabled ? What do I think it does ?
I an neutral on it. I just want my Linksys routes to work exactly same way that my R7000 routes work. I have near zero care-factor about whether it is enabled or not enabled. However- I do know this (1) it is enabled on the R7000, where the routes work, and (2) it is not enabled on the Linksys site where LITERALLY NOBODY can explain why the routes do not work....
Although - there is an interesting guess given by @SurpriseditWorks
Anyway - I am a humble person. I have no preconceived ideas about this. I have no desire that it be enabled or not enabled. I just want my (identical) routes to work. They work in the R7000 site, they do not work in the Linksys site. So I systemically explore all the differences of the 2 systems.... And that setting is one difference.
The biggest difference is that the vlans are set up manually ( using the startup script) in the Linksys, but they are setup by the gui for the R7000.
So, in linksys site, what exactly works and what not working ?
Answer: For packets that arrive, from the internet, via oet2, they first DO HIT the nat table and increase the counter for the PREROUTING rule. That rule will -j DNAT a new destination address (ie 192.168.33.11). And then in the FORWARD chain, they DO NOT hit the rule ( to ACCEPT the packets). That is when the rule is the identical to the R7000 site. In that rule "iptables -I FORWARD -p tcp --dst 192.168.33.11 --dport 8011 -j ACCEPT" it is explicitly matching on the (newly DNAT-ed address). And no packets match that rule in Linksys site...... But in R7000 site they do match on that (identical) rule. why ??
And then - if I change the rule in Linksys site to "iptables -I FORWARD -p tcp --dport 8011 -j" , the packets DO HIT that rule !! So my question is what is the ACTUAL dst ip address in the packet. Apparently it is not what it should be. I know it is also not the original (I have tested for that), and it is not "192.168.33.11" (as per the DNAT) .....
So my current theory is that it is actually the DNAT rule in PREROUTING in the nat table, that is "not working as it should, or as expected"... and that is what causes the later FORWARD rule to not match.... So I think the intended dst address (192.168.33.11) never gets successfully DNAT-ed to the packet. And without the DNAT, the packet does not know where to go.
Anyway --- I just want it to work... Any assistance would be GREATLY appreciated !
About my 2 wg tunnels - that is 2 tunnels in each site. Note these 2 sites are not interconnected. They are completely independent of each other. The tunnels go out to external VPN provider.
All wg tunnels are working perfectly - and have been for a long time.
IN BOTH SITES (both r7000 and the linksys sites)
The r7000 site for about 15 months, absolutely rock solid, working perfectly.
The Linksys site, for over a month, which is as long as they have been setup.
The ONLY problem is about routing traffic, that came in from eot2, to a device on vlan3 on the Linksys site. And that exact routing scenario is working perfectly in the R70000 site and has been for over a year..
I am curious why you think I need some assistance to setup the wg tunnels ?
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Fri Feb 17, 2023 13:18 Post subject:
I can not comment on your problem, I am only commenting on your statement that you have found a bug.
The Nat/Masquerade rule does SNAT traffic of the interface out via the WAN, so actually allowing WAN (internet) access from that interface.
In the WireGuard Changelog
Quote:
51058:
WireGuard used as server is now IPv6 compatible.
A setting has been added "Allow Clients WAN Access" which makes it possible to toggle internet access (NAT out via the servers WAN) for attached clients, both for IPv4 and IPv6 if applicable, this has been duplicated and overrides Networking Interface: Masquerade/NAT.
So that setting has been moved to the WireGuard interface, to get the same rule in the WireGuard interface Enable: Allow Clients WAN Access.
WireGuard itself does not have DNAT rules so I assume you are trying to port forward through the WireGuard interface?
Things to look at:
Disable CVE mitigation
The Head of development has been playing with INVALID iptables rules, not sure if your build actually has them but it is worth a try to remove those if you have it.
The INVALID rules will DROP INVALID packets which can arise if you have made routing mistakes.
Edit 1: Furthermore be sure to disable SFE (Shortcut Forwarding Engine) on Setup page this can also play tricks with routing
Edit 2: Failure to reach clients on your LAN from WireGuard can also come from the firewall of your clients, most firewalls only allow local traffic and need to be tweaked to also allow traffic from Wireguard's subnet.
The setting you point out "Allow Clients WAN Access" seems to have an entirely different purpose. The way you described it it seems to be for traffic that is OUTBOUND. The problem I described is specifically about INBOUND traffic (on oet2) .
Also - at BOTH of these sites - (Linksys and R7000) there has never been any problem about devices accessing the WAN. And I do not use any ipv6 in either site.
Could you please be specific about the SNAT rules that the "NAT/Masquerade" checkbox puts in place. It seems like an easy step for me (troubleshooting my problem), to manually add those rules, and to test if it makes any change to the symptoms I am seeing...
As I said - is working at the R7000 site and not working at the Linksys site - so I am just systematically running through every difference (however small) that I can find between the 2 sites.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Sat Feb 18, 2023 7:06 Post subject:
shb wrote:
Hi @egc and thank you for your reply.
The setting you point out "Allow Clients WAN Access" seems to have an entirely different purpose. The way you described it it seems to be for traffic that is OUTBOUND. The problem I described is specifically about INBOUND traffic (on oet2) .
My comment is not about your original problem, my comment is about you complaining of a bug: " bug in Setup-> Networking r51306" that settings has been moved to the WireGuard interface and has a more descriptive naming: "Allow Clients WAN Access"
So if you enable that you have the same rule.
I do not know if it is related to your original problem.
Regarding your original problem I added a few thoughts you might look in to:
Quote:
Things to look at:
Disable CVE mitigation
The Head of development has been playing with INVALID iptables rules, not sure if your build actually has them but it is worth a try to remove those if you have it.
The INVALID rules will DROP INVALID packets which can arise if you have made routing mistakes.
Edit 1: Furthermore be sure to disable SFE (Shortcut Forwarding Engine) on Setup page this can also play tricks with routing
Edit 2: Failure to reach clients on your LAN from WireGuard can also come from the firewall of your clients, most firewalls only allow local traffic and need to be tweaked to also allow traffic from WireGuard's subnet.
To check if this is the problem you can Enable "Bypass LAN Same-Origin Policy" in the WG interface
I understand your explanation, and I agree - not a bug. It is just "a setting moved to a more appropriate place.".
The confusion only arises because the original field in the gui (which you have clearly explained - does nothing), is still there. A user may "enable that field" without knowing that doing so, actually has no effect.
Thank you for your comments on the things I can look at. I will work through each of those suggestions. I will first look at the ones that are different between the working site (r7000) and the non working site (linksys).
1. cve is enabled in both sites.
2. I do not see any INVALID iptable rules
3. SFE is a difference. The linksys only has option to enable/disable sfe. The r7000 site has settings as follows:
4. I will test further on "Bypass LAN Same-Origin Policy". Currently unchecked in the Linksys site, and that option does not exist in the r7000 site
DOES get hit (counter increases) . But it seems like the DNAT did not work, because the second rule, in FORWARD, only gets hit if I remove the matching on the explicit --dst.
I will upgrade the router that has the problem, ie the Linksys, to 51741.
Maybe that can makes some difference. I should note that - EVERYTHING ELSE - including everything else about the 2 wg tunnels is all working perfectly on the Linksys. e.g. outbound access to the internet via those 2 tunnels.
About the r7000 site: I am not going to makes any changes to that - FULLY WORKING -R7000 site. Especially now, as I am 8000km away from that site. Risking to introduce new problems to that site, while I am not even there, could really cause big disaster.
Last edited by shb on Sat Feb 18, 2023 8:51; edited 1 time in total