[shb]

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 ??

[egc]

Why do you want to Enable NAT/Masquerade ?

Does the R7000 also runs WireGuard and uses the same build?

[shb]

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.

Screen below from the R7000 site:

[egc]

Still the question remains why do you want it Enabled e.g what do you think this options does?

I suggest you read the WireGuard Documentation, that is a sticky in the Advanced Networking forum:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327397

I will also transfer this thread to the Advanced networking forum as it can be of interest to us all

To give you a head start see the Changelog under 51058: on the WireGuard Documentation page.

The oet interface is setup via the tunnel so do not mess with the interface on the Networking Tab.

[shb]

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 !

[shb]

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 ?

[egc]

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

[shb]

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) .

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.

[egc]

[shb]

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

[egc]

Disable SFE to test.

Consider upgrading both sites to the latest build 51741, at least you can better compare the two sites.

[shb]

SFE - enable/disable - had no effect.
Bypass LAN Same-Origin - checked/unchecked - had no effect.

It is vexing, because the first rule:

iptables -t nat -A PREROUTING -i oet2 -p tcp --destination-port 8011 -j DNAT --to-destination 192.168.33.11

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.

[shb]

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.

[egc]

I would also not upgrade a site if I do not have physical access, safety first

[shb]

Yes ! I totally agree. Especially as that site is currently working with no problems.

But, for the next few weeks I am at the site of the Linksys. So I can certainly upgrade it.