[E.Johansson]

Hello. This is my first post. A huge thank you to everyone for their hard work and dedication to supporting and updating dd-wrt. It's both thrilling and a bit daunting to have so much power over your router, like being handed the keys to a Ferrari.

Could I please get help with a problem? I am literally at my wit’s end with this.

My router is an Asus RT-AC68U, converted from a T-Mobile TM-AC1900, running r47618 dd-wrt firmware.
It's configured as a wireless repeater router, connected to a public "xfinitywifi" hot spot on 5GHz on the wl1 interface, and it acts as an AP on 2.4GHz wl0 and on 5GHz on a VAP wl1.1 interfaces.
A Wireguard tunnel is set up between the dd-wrt router at my condo and a Raspberry Pi at my house, configured to send all internet traffic through the tunnel once the tunnel is up.

Everything is working great, except no matter what I try, I cannot access the Status page / web GUI Management page of the router from the other end of the tunnel (a Rapberry Pi on my house LAN). The connection times out, “Connection Refused” error - but everything else works through the tunnel.

**************************************************************
First, the dd-wrt router settings (Wireguard client):

I relied heavily on the Wireguard setup guide, and the WG Advanced setup guide on this forum, plus a ton of other posts and guides both here and on other forums.

Asus RT-AC68U, converted from a T-Mobile TM-AC1900, running r47618

Basic Setup:
WAN Connection type: Automatic - DHCP.
Ignore WAN DNS: checked
Local IP: 192.168.29.0/24
DHCP DNS Static Servers: 75.75.75.75 and 75.75.76.76 (Comcast / Xfinity)
DNSMasq: checked
DHCP-Authoritative: checked
IPV6: Disable

Advanced Routing:
Operating mode: Gateway
Dynamic Routing: Disable
one entry under Routing Tables: 192.168.20.0/24 via gateway 10.28.5.2, Interface LAN & WLAN, MTU = 1420

Tunnels:
Protocol: Wireguard
CVE: Disable
NAT via tunnel: Disable
MTU: 1420
DNS servers via tunnel: 75.75.75.75 and 75.75.76.76 (Comcast / Xfinity)
Firewall Inbound: unchecked
Kill switch: checked
Allowed IPs: 0.0.0.0/1,128.0.0.0/1
Route Allowed IPs via tunnel: checked
IP Addresses/Netmask: 10.28.5.2/30

Wireless Basic Settings:
wl1: Wireless Mode=Repeater, SSID=“xfinitywifi”
wl0 and wl1.1: AP mode
All three wireless interfaces: Network Configuration = Bridged.

Services/Services:
DNSmasq, Query DNS in Strict Order: Enable
Secure Shell: All three boxes Enable, notably including “SSH TCP Forwarding”
everything else on this page: Disable

Security:
SPI Firewall: Enable
ARP Spoofing Protection, Block WAN SNMP access, everything under Impede WAN Dos/Bruteforce: checked
everything else: unchecked / Disable

Administration / Management:
Web Access: HTTP, HTTPS, Enable Info Site, and Info Site MAC Masking all checked
Remote Access:
Web GUI Management: Disable
SSH Management: Enable
Allow Any Remote IP: Enable

Boot Wait, Cron, 802.1x, Reset Button, Bootfail Handling - Reset after 5 Bootfails, Routing: all Enable
everything else: Disable / default values

**************************************************************
Now the Raspberry Pi (Wireguard server) settings:

I relied on these instructions: https://engineerworkshop.com/blog/how-to-set-up-wireguard-on-a-raspberry-pi/

RPi LAN address: 192.168.20.41
The RPi is isolated on its own VLAN, IP 192.168.20.0/24 connected to my house router. It’s currently the only device on that subnet.

WG:
Address: 10.28.5.1/30
MTU=1420
AllowedIPs = 10.28.5.0/30, 192.168.29.0/24, 192.168.20.41/32

**************************************************************
Like I said, almost everything runs great. I can connect to the dd-wrt router, and all traffic, once the tunnel is up and after the initial DNS to find my home address using DDNS, goes through the tunnel to the RPi, and then out through my home firewall. I have a laptop connected to the dd-wrt router - 192.168.29.102. I can access anything and everything on my home LAN (192.168.1.0/24) through the tunnel with no problem, subject to whatever rules I have set on my home firewall. I’m not worried, at least not now, if DNS requests leak out of the tunnel, because DNS is going to Comcast servers at each end anyway.

However, when I try going the opposite way, from the RPi to the dd-wrt Status page, it always fails. The connection times out, and after some time I get a “Connection Reset” error.
I have tcpdump set up on both ends of the tunnel to sniff the traffic on the tunnel interfaces. I can see the browser on the RPi send a request to the dd-wrt, and the dd-wrt respond on the other end with the full and complete Status page html code, but it never makes it back through the tunnel to the RPi for whatever reason. Only maybe the first few bytes of the packet, then the rest is missing. The dd-wrt then repeats / resends the page, up to 19 times by my count, but it never makes it through the tunnel. Eventually, the dd-wrt gives up and sends the “Connection Reset” error.

So, I had the idea to test by disconnecting the dd-wrt router from “xfinitywifi” and connect it to my guest wifi instead. I have my guest wifi on its own VLAN, and on my firewall I shut down all connections between the guest wifi VLAN and the RPi VLAN except for UDP packets on port 51822 for Wireguard. No other settings on the dd-wrt router or RPi were touched. To my surprise, suddenly everything works perfectly: I can access the dd-wrt Status page from the RPi by going to 192.168.29.1 in the RPi browser, and again I verify that everything is actually flowing through the tunnel by watching the traffic using tcpdump at both ends, and this time the full webpage html code flows through free and easy with no problems.

Connecting back to “xfinitywifi” I tried various things: I lowered the MTU to 1420. I saved a copy of the Status page to an html file on my laptop at the dd-wrt end, then used sftp to move it to the RPi - it worked perfectly. Tried the same thing with several other webpages and then with large pdf files - all went through perfectly. I tried setting up tightvnc on my laptop connected to the dd-wrt (192.168.29.102), and verified that it works at that end of the tunnel, but when I try to access from the RPi it gets to the Authentication screen, but after I enter my password I get the error “Authentication failed from 192.168.29.1” (i.e. from the dd-wrt router, not from 192.168.29.102 which is the laptop). So, then I tried to set up port forwarding rules on the dd-wrt for port 5900 to forward to the laptop at 192.168.29.102. That also failed. I also tried enabling the VNC Repeater service in dd-wrt. Fail. I also of course tried enabling “Remote Access” for Web GUI Management on the dd-wrt Administration page. This also failed. So, I had a look at the rules created for this in iptables, and notice that they point to the wrong gateway, the xfinitywifi WAN address instead of the tunnel endpoint. So, I try replacing the rules and change the gateway address to the tunnel endpoint (10.28.5.2). This also fails. I also tried connecting another device with a web gui administration page (192.168.29.104) to the dd-wrt router. That also failed to work / connection timed out over xfinitywifi but worked perfectly through my guest wifi.

I have also tried many, many other things, mostly messing around with the firewall rules using iptables, which I don’t really understand what I’m doing. It seems like the firewall is slamming the door shut on me when I try to access the Status page through the tunnel; yet, for some reason everything works great when the dd-wrt is connected through an isolated VLAN on my home network without me touching a single rule. I have tried dozens of combinations of rules for filtering, forwarding, nat, mangling, whatever based on examples and guides on the internet, until I finally give up hope on routing and I try using port forwarding instead. At one point, I even erased every firewall rule on the dd-wrt except for two rules, one to allow the Wireguard UDP traffic and another to block everything else from the WAN. Again, this absolutely barebone configuration worked perfectly when connected to my guest network, and failed miserably when connected to xfinitywifi.

The only success that I have had is when I shut down Wireguard altogether and went back to OpenVPN, and I modified the port-forwarding rules for Remote Web GUI Management to point to the OpenVPN endpoint in the dd-wrt router. That I was able to get working over xfinitywifi, but I cannot achieve the same success using the same trick with Wireguard.

Please help. What firewall rules do I need to add or modify to get this to work? Has no one else had this problem? Is it only because the dd-wrt router is in wireless repeater / routed mode instead of a conventional wired connection through the WAN port to a modem? At this point, I’m ready to either buy 10 miles of fibre optic cable and string it along the street from my house to the condo, or give up on dd-wrt and try maybe a Mikrotik wireless router instead.

Thanks in advance for any help or insight that you can offer.

[tedm]

[egc]

I have never setup a site-to-site setup on a repeater so that could be the culprit.

However I do see some settings I would do differently (not saying it will solve your problem though)

First as this is a routed solution all subnets involved should be unique (all the subnets on the server side, all the subnets on the client side and the VPN subnet should all be different)

As said your Local IP address of the client should be 192.168.29.1 netmask /24

Gateway and Local DNS should be left at its default 0.0.0.0

(it helps tremendously if you just post pictures of your setup pages)

On the client you have set a static route, not sure why you are doing this, all routing is already done in the WG interface that is what "Route Allowed IP's" means.
You are already routing everything via the WG interface (with 0.0.0.0/1, 128.0.0.0/1) so also traffic for the RPI, but if you really want a route specifically for the RPI you just add in the Allowed IP's 192.168.20.0/24

So I would delete the static route.

The IP address/Netmask has an odd netmask of /30.
You either use /32 or better /24 so change that in /24

I do not have an RPI but I would also sets its address 10.28.5.1 with netmask /24
Allowed IP's: 10.28.5.2/32, 192.168.29.0/24

You have set the RPI's own address under allowed IP's that is wrong, I assume the RPI also routes allowed IP's by default so you are now routing traffic for the RPI back through the tunnel that does not seem right.

You should be able to access/ping the interface at both http://192.168.29.1 and at http://10.28.5.2
Make sure you type http and not https and make sure CVE mitigation is disabled

Now on to the firewall, which could be the problem 😊
It is possible that the wan interface is not correctly identified on a repeater

So send output of :

[E.Johansson]

[egc]

Quick note you should not set any port forward on the repeater.

I am starting to think you maybe are overcomplicating things.

Access is done through the WireGuard server, so if it is working you can actually make a peer on your server for your phone and from your phone on cellular connect to your server and via your server you connect to your client with your phone.

These kind of setups are done to overcome CGNAT and/or the inability to port forward from your ISP

Maybe if the WAN in the repeater is correctly identified you might consider starting over after a reset.

[E.Johansson]

[egc]

Do not do a 30-30-30 on ARM routers it can brick them
To reset to defaults, from the CLI (telnet/Putty):

[E.Johansson]

[egc]

Some clarification about the port forward, your WAN is not accessable as it is behind another router which does not port forward so that is useless.

Can you port forward on your WG interface, of course you can but why would you?

The WG interface is a direct connection to your WG server and as your WG server has a route to your client and its subnet, the WG server knows how to reach the client and everything on the subnet so there is no need for a port forward.

The client is nothing more than just another subnet of the server like any other subnet the server already has.

The only useful port forward is on the server, e.g. a port forward to anything on the server and its subnets (like the the WG clients subnet)

So no use for a port forward on the client.

One thing which is necessary to reach the wg client and its subnet is creating a hole in the firewall.
Something which is normally done by disabling the setting "Firewall inbound" (so it should be unticked)

As requested in my first post we have to make sure that this works on a repeater.

I maybe have some time tomorrow to test if a repeater works

One thing about connecting to a hotspot, it is possible that hotspots actively block the use of a repeater/tethering they do this by counting the TTL value.
But if this was the case I would expect that you do not have internet at all from clients connected to your repeater

[E.Johansson]

Hello egc.

Yes, what you are saying is all very good advice and I follow what you are saying, and thank you for taking the time to explain. But, the reason for my trying port forwarding is again a very simple one: because routing does not work, and nothing I can think of to try can make it work. So, I have been bouncing back-and-forth between trying whatever I can find on the internet to get routing to work, until my eyes are raw and my fingers numb, until I say the heck with routing, I give up, I will just get a port-forward set up on the tunnel endpoint interface - because either dd-wrt or WG keeps slamming the door shut on me when I try to route to the status page. Yes, I fully understand how the routing is **supposed** to work: Set the client LAN subnet (192.168.29.0/24) in the WG server's "Allowed IPs", WG will automatically set up the static route for you (192.168.29.0/24 dev wg0), and the subnet on the other side of the tunnel is now like any other subnet on your local LAN - and in fact I have done all these things, and confirmed that the routing table is correct, many times over now, and it all works perfectly and exactly how it should - until I connect to xfinitywifi. Again, and I can't stress this enough, the **only** thing that I change is which wifi I am connecting to, and that's enough to break things.

I have also spent plenty of time on iptables firewall rules (besides port forwarding), but logically how could the problem possibly have anything to do with the firewall, when the exact same set of rules works perfectly for traffic through the tunnel when connected to one wifi hotspot (my guest wifi) but not the other (xfinitywifi)? I even dumped the whole of iptables in both cases and did a detailed line-by-line comparison, and did not see anything that somehow got changed from simply switching wifi connections from one SSID to another.

I think you are onto something with the TTL value, but IMO - and I am still a novice who is learning, so I could be way off track - it's dd-wrt itself that's blocking access based on TTL values. My next angle of attack on this problem is to compare TTL values between the two instances, and set up rules in the iptables mangle PREROUTING table to alter the TTL value in the packet header and trick dd-wrt into let the traffic pass unhindered.

But first, I decided that before I reset the ASUS RT-AC68U back to factory defaults, I would go get my old workhorse Linksys WRT1900ACv2 off the shelf, update it to the latest dd-wrt, and set it up in the exact same configuration and see if it also suffers the same problem when connected to xfinitywifi.

Thanks again, I will report back later with updated results.

[E.Johansson]

BTW, another clue is that I ping anything and everything on the dd-wrt subnet through the tunnel, whether connected to xfinitywifi or my guest wifi, and I tested and confirmed that the router isn't intercepting the ping requests, but allowing them through.

So, before messing with the iptables mangle table PREROUTING chain to change the TTL values, my next step will be to set up a test server on a UDP port, see if dd-wrt allows that through the tunnel. Just occurred to me that everything that's been blocked has been TCP.

[egc]

I just setup a E2000 as a repeater connected to my phones hotspot.
Made a WG tunnel setup for site-to-site to my WG server.

From my WG server I could reach the E2000 and its subnet behind.
The WAN interface is correctly identified and everything is working so a repeater mode setup with WireGuard seems to function without a problem.

Miscellaneous things to try (assuming the hotspot allows tethering otherwise you have to increase the TTL value), disable SFE (Short cut forwarding Engine on Setup page), lower MTU to 1280

[E.Johansson]

Hello egc. Thank you for the help.
I will try those ideas.
Set up my WRT1900ACv2 with r47644 (released yesterday! - thank you) same config as the RT-AC68U - and same issue. Cannot reach the status page.
We are making progress narrowing down the problem.
More later when I return from the dentist, minus one tooth.
Cheers.

[E.Johansson]

[egc]

Great to hear you have got it working!

1280 is an educated guess, I assume that your provider is using IPv6 also and that is the lowest which is allowed for IPv6 maybe higher will work.

The Troubleshooting section (in the WireGuard server setup guide) has a paragraph about MTU problems.

I see you already marked this thread as solved