Posted: Tue Jan 17, 2023 2:52 Post subject: [SOLVED] Services not accessible with WireGuard
Netgear R6400
Build 51362
Gateway mode
I setup a tunnel to my mullvad VPN to cover majority of my network. I used the guide discussed here https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324624. I have setup policy based options like so “Route Selected sources via WAN” selected and in the source for PBR I have 10.176.208.2/31, 10.176.208.4/30, 10.176.208.8/31, 10.176.208.10/32. I’m still unable to reach my services outside of my network when the tunnel is enabled. My services are 10.176.208.2-10. When testing my services their public IP reports as my home IP address. I also tried using the below guide to setup routes so that they would use WAN instead of Tunnel but that didn't work either. https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327810. I'm not sure what I'm doing wrong and why my services are only available when the tunnel is disabled when they are not even using the tunnel in some cases. Any help is appreciated Thank you!
Last edited by Bhumblet on Wed Jan 18, 2023 14:58; edited 1 time in total
Yes, the clients with IP addresses between 10.176.208.2 to 10.176.208.10 do in fact show WAN IP, while anything above shows WG tunnel IP.
By services I mean my self hosted services such as Plex, Nextcloud, VPN server, etc. Although these have IPs between the range above and are using the WAN IP, verified with ipleak.net, they are not accessible outside of the network (from internet) unless I disable the tunnel as a whole.
Joined: 18 Mar 2014 Posts: 12877 Location: Netherlands
Posted: Tue Jan 17, 2023 13:14 Post subject:
Assuming you are using PortForwards to make your servers accessible from the Internet there are a couple of things to pay attention to:
On WireGuard page:
CVE mitigation this can interfere with traffic going to your LAN, but as traffic is not going in via the WG interfaces it should do no harm
Kill switch, this stops all traffic from going out of the WAN but the PBR IP's should have an ACCEPT rule so those should be able to go out of the WAN and as the ACCEPT rule does not have a state NEW it should work for ingress traffic too
So it should actually work even with the settings of CVE and Killswitch but worth a try to disable those settings.
But before you try that take a look at Basic Setup page, do you have Short Cut Forwarding Engine/Flow acceleration enabled?
Bit of an update here. Yes I do have the ports forwarded and set to the corresponding servers on the router.
The way I have tested if one of my servers is "accessible" from the internet in the past, was to enable my Mullvad client on my laptop as that has an option that blocks all local connections, and then I would verify that the IP accessing the server was in fact the outside Mullvad IP.
Fast forward to setting up the Mullvad tunnel on my router. I again relied on this method to test whether I am able to access my servers outside of my network. With the tunnel enabled on both the router and then also my Mullvad client on my laptop I was not able to access my servers. Without the Mullvad tunnel on the router I was then able to access my servers again. I'm guessing this is because of the complexity of networking when having multiple hops, and maybe you know and could give some information pertaining to why this didn't work?
Anyways, I was away from my network today and decided to test some of my servers just to see if I was able to access them and to my surprise I was. I found though that my Plex server would load but not play any content, so I thought I would try your suggestion of disabling Short Cut Forwarding Engine. Note, Flow acceleration was already disabled. Once I rebooted my router, I was then able to stream my content. Thank you for the support, I don't think I would've ever messed with that setting to fix my streaming issue or fully understood some of the WireGuard additional settings. Please comment if you do have some thoughts on why the double Mullvad tunnel did not work, and also if you have a suggestion on how I test access from home in the future.
Joined: 18 Mar 2014 Posts: 12877 Location: Netherlands
Posted: Wed Jan 18, 2023 7:23 Post subject:
It is in all the guides:
"Test from outside your network e.g. with your laptop/phone on cellular"
Why because these are routed solutions and all three networks: server, client and VPN have to be different.
When testing from inside your server and client networks are the same.
So which route does the traffic take, does it take the internal route, the external route, if you try to block the internal route does your client already know the internal route and now report it to being blocked?
WireGuard does sometimes work (OpenVPN almost never because it has a control and data channel) but it is not a reliable testing method, so always test from outside.
About SFE/CTF, this makes a shortcut if there is heavy traffic on an interface.
It works reliable for simple setups but for more complicated setups e.g. where you have more than one interface facing the same side e.g. two exit interfaces the WAN and the VPN, you can get into trouble.
When one interface let say the WAN is having heavy traffic a shortcut is made to exit your router.
Traffic wanted to use the VPN to exit the router is redirected via the shortcut as that is the way to exit your router. You see the problem.
Now if there is no heavy traffic or the interfaces take turn it might even work so this is what is described as a heisen-bug, it is there and it is not.
When you are certain you have setup the right way and something is not working and you start to pull your hair out, bang your head on the desk and considering a career swap then it is time to disable SFE/CTF
One other thing about streaming media (also in the VPN troubleshooting guide) is MTU.
If you experience streaming media problems but otherwise a working connection then lower your MTU.
The higher the MTU the better your throughput, until it breaks, first noticeable on streaming media.
If you are IPv4 only and the provider is IPv4 only an MTU of 1440 (or 1432 when using PPPoE) can be used but if one side or both are using IPv6 then lower to 1420(1412), in rare circumstances (hops in between use lower MTU) then you have to go even lower.
I think Mullvad is supporting IPv6 so in case of Mullvad use 1420, did you setup manually or from an imported config?
If so does that config state an MTU and if so which MTU?
The Client Setup guide nowadays warns that it is better to use an MTU of 1420 when in doubt.
I see that makes sense. The cellular connection where I live is very unreliable most time resulting in me having 1x on my phone inside of the house, and so it is hard for me to test from these. I will make sure in the future to always check with another source though.
The Mullvad tunnel I specifically selected the IPv4 only tunnel. The configuration file doesn't state an MTU, so yes based off the guide I manually chose 1440 since both my network and Mullvad are using IPv4 only. I should be good sticking to 1440 then?
The streaming actually shouldn't be going through the VPN tunnel since it is part of the IPs in the PBR to use the WAN instead. I also verified the public IP of the Plex server is my WAN IP, so the MTU related to the tunnel here shouldn't have caused it. The issue with streaming however did only occur while the tunnel was also enabled if that gives more info. The way you describe SFE/CTF makes it seem like that was what was happening, but I don't know if that also applies the other way around. As in the traffic wanted to exit the WAN interface but was redirected via the shortcut.
Since the streaming is happening through the WAN not the tunnel, it looks likes the regular MTU on the basic setup page is set to Auto with 1500 greyed out next to it. Is this something I should look at changing? If so I assume this would also be 1440 since IPv6 is disabled for my network.
Joined: 18 Mar 2014 Posts: 12877 Location: Netherlands
Posted: Wed Jan 18, 2023 13:40 Post subject:
Your WAN MTU should be good.
Although you choose IPv4 Mullvad tunnel, it is possible they actually use the same default for IPv4 and IPv6 (which is 1420) so I would choose 1420.
But if everything is working with 1440 you might keep it like that, you have a small speed advantage
About SFE it can impart on both tunnels the tunnel which is first with heavy traffic gets the bypass so the other tunnel is toast but if traffic is gone the bypass stops.
CTF is unclear, it does something similar but it is closed (Broadcom) source.
