Posted: Tue Sep 08, 2020 0:16 Post subject: How to force all traffic through oet1 interface? [SOLVED]
I have a Wireguard tunnel setup on oet1, and while doing traceroute -i oet1 works as intended, by default network traffic is not going through the tunnel, in spite of setting 0.0.0.0/0 in AllowedIPs.
I've been googling around trying out different iptables commands that people have suggested, but none of them seem to work (If I'm being perfectly honest though, I still don't really understand iptables even after reading up on it).
Here's my current router information and config:
Router: Linksys EA6350 (v1)
Firmware: DD-WRT v3.0-r40559 std (08/06/19)
Current firewall rules:
Since your installed release, the Wireguard interface received many additions, including "Endpoint mode".
I'd advise to update your router to a newer release, discarding the bad 40559 (this wasn't a great build at all).
Newer Builds ftp://ftp.dd-wrt.com/betas/2020/ (like 44251) "just work" incl. wireguard. No additional iptables entries are needed. The GUI covers everything.
My config at home (on an old N66u) consists of
-enabling wireguard,
-disabling CVE-2019-14899 Mitigation,
-enabling NAT via tunnel
-adding the "other side"
-peer tunnel IP and DNS 0.0.0.0
-enabling endpoint
-allowed IPs 0.0.0.0/1,128.0.0.0/1
-enabling Route allowed IP's via tunnel
-set persistent keep alive to something suitable like 20-30 seconds
done
Many devices of my network use this router on a regular basis each day.
edit
Re-reading everything I stumbled across your allowed IP setting 0.0.0.0/0 this setting might also be cause of problems.
Have a look into @Egc's excellent Wireguard .pdf guide. It is pinned as important thread in this forum.
Everything is covered there, including this setting
Since your installed release, the Wireguard interface received many additions, including "Endpoint mode".
I'd advise to update your router to a newer release, discarding the bad 40559
Wow, that is a big difference.
Is there any reason why the wiki entry for my router only has build 40559 as the latest? I can see browsing the link you gave that the EA6350 is there for the newer builds, I just honestly had no idea since the database only had up to 40559 listed.
The database was already in this state when I flashed my wrt54 many many years ago.
It recommended out of date/bad builds like today.
Somehow some(-one/-thing) takes random releases and inserts them on the website, without refreshing those data if problems are found.
*shrugs*
In my opinion: reading the release threads, maybe taking a look into svn.dd-wrt.com is sufficient.
Good feeling about the release or you have some spare time to revive your device if it gets lost --> "do the flash"
If we could make it clear for all users to follow the forum guide lines (link in my signature at the bottom) than it would be general knowledge not to use the router database
Is it possible to either:
A - remove the router database on the website and instead have it redirect to the forum guidelines
OR
B - If there's just no one to manage the database, I would be interested in talking about taking over managing that as a way to give back to the project and make it easier for newcomers.
My config at home (on an old N66u) consists of
-enabling wireguard,
-disabling CVE-2019-14899 Mitigation,
-enabling NAT via tunnel
-adding the "other side"
-peer tunnel IP and DNS 0.0.0.0
-enabling endpoint
-allowed IPs 0.0.0.0/1,128.0.0.0/1
-enabling Route allowed IP's via tunnel
-set persistent keep alive to something suitable like 20-30 seconds
done
Many devices of my network use this router on a regular basis each day.
I'm not sure if it was the CVE mitigation, or the allowed IPs, but your settings worked perfectly for me. Traceroute is now going through the tunnel without any other configurations. Many thanks!
worked perfectly for me. Traceroute is now going through the tunnel without any other configurations
Ok I spoke too soon. Ping and traceroute work fine, but now many sites (including google, duckduckgo, etc) simply timeout in the browser. I'm currently stuck using Bing as as my search engine unless I turn off the VPN
In my case this happened due to wrong MTU settings.
Try lowering the tunnel MTU.
DSL PPPoE usually uses 1492 in my area but Wireguard brings its own overhead resulting in up to 80 bytes (if IPv4 and IPv6 headers are in use).
So I set my tunnel to 1412 and timeouts on my end did not happen anymore.
Lowering the MTU seems to have fixed everything, though I had to lower it way more to around 1200, even though 1500 (default) without the tunnel works fine. IDK ¯\_(ツ)_/¯.
Just to not leave things hanging - the DNS was PiHole running on the VPS.