Wireguard Asus 2 x RT-AC86U Wireguard Reverse Tunnel


New Around Here
I have managed to setup Wireguard on 2 x RT-AC86U on USB sticks. It works "conventionally" as a Client > Server using the standard configuration files e.g. wg0.conf for the client and wg1.conf for the server. The RT-AC86Us are continents apart and each end on a "normal" ADSL connection i.e. IPv4 addresses and DDNS work.

I understand that the theory is Wireguard is not directional, but "peer-to-peer". In practice, as a VPN I rationalise what I am after is a Wireguard client and server (the client initiates the connection to the server), and once the connection established the VPN I want is the other way direction i.e. I am at the Wireguard Server end, but want my internet traffic routed via the Wireguard Client end. The complexity is needed because the desired ISP at the VPN Server end uses CGNat i.e. DDNS does not work / there is no IPv4 address (nor IPv6 yet).

As per upper half of attached PDF, I have got this working between 2 Windows PCs on: the right PC connects outbound from the CGNat end to the left PC behind normal ADSL. Once connection is made, internet requests from the left PC are routed via the right PC / ISP. Trial and error showed one or more IP addresses must not go via the VPN, hence I blocked off

I now want to replicate it using the 2 x RT-AC86U routers, at the same locations. However, the Wireguard setup on Merlin / USB appears to assume a more dedicated client / server relationship e.g. in S50wireguard, and whether it uses wg0.conf or wg1.conf. I have got the Asus's working together over ADSL connections in the conventional manner, but wish to replicate the Windows setup above with CGNat.

I have, via luck :rolleyes: trial and error got it working to handshake / send KeepAlive packets i.e. the wg commands at each end show regular traffic each way... however, the internet traffic from e.g. wireless clients of the (left) RT-AC86U is not routed. I suspect it is due not understanding all the routing stuff in wg-server, or knowing enough to use wg-up / wg0.conf on the (left) VPN client end.

Any assistance would be very welcome :cool: If there are different flavours of Wireguard on the Asus RT-AC86UI used this youtube link


  • Wireguard SNB.pdf
    90 KB · Views: 121


Very Senior Member
I don't see any theoretical problems with this, altough some practical problems. Routing data out of a server requires you to track whiether anyone is connected.

I have never setup a server (I'm also behind a cgnat) so I wouldn't know how this would work.

You will probably have to cherry-pick lines from wg-up and wg-server and mix them.

Looking at my client though, in order for it to accept and forward incoming connections the following rules will be needed (taken from wg-server)
iptables -I FORWARD -i wg0 -j ACCEPT

If you don't plan to access internet from your client you should comment the
ip route add $(ip route get $host | sed '/ via [0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/{s/^\(.* via [0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\).*/\1/}' | head -n 1) 2>/dev/null
ip route add 0/1 dev wg0
ip route add 128/1 dev wg0
From wg-up.

The ip route part will then need to be moved to wg-server for it to route data to non local adresses out the wg1 interface...

I wouldn't expect this to work like this, I have probably missed some stuff, but maybee a start?

Last edited:


New Around Here
Thanks Zeb - gave me the confidence to play with the lines and it is now working well :cool:

You will probably have to cherry-pick lines from wg-up and wg-server and mix them.
I had thought as much, but the pointers you gave led to the success. I adapted wg-server / wg1.conf since that is how I had got the handshakes to work, and wg-up / wg0.conf did not work. Copying across:
ip route add 0/1 dev wg0
ip route add 128/1 dev wg0
stopped it working, but with only the 0/1 line it still worked handshaking... which led me to the same process as with the Windows GUI, and should not be routed (the CGNat ISP reports it has a IPv4 address which must be a clue?).

Summary, as I added these lines and stopped/restarted the Wireguard VPN client end:
ip route add 0/1 dev wg1
ip route add 192/2 dev wg1
ip route add 128/3 dev wg1
ip route add 176/4 dev wg1
ip route add 168/5 dev wg1
ip route add 164/6 dev wg1
ip route add 160/7 dev wg1
ip route add 163/8 dev wg1
more and more websites went over the Wireguard VPN ;)

I'm not helped by understanding very little of the wg-up / wg-server lines, but next step will be to revert to wg-up / wg0.conf adding the lines above and removing (which stops it working):
ip route add 128/1 dev wg0
and will then be using most of the default VPN client file(s).

Summary Now have a Reverse Wireguard Tunnel between 2 RT-AC86Us where the VPN Server end has no known IP address due CGNat. Any wired / wireless client of the VPN Client Asus (abroad) now appears to be at VPN Server Asus (UK) location for geolocation purposes e.g. streaming TV :) Many thanks again...


Very Senior Member
Glad you made it work!

Routing prioritize via specificity within a routing table. So a ( default route) will always have lowest priority which is why, takes priority since it is a little more specific.

Another way of doing this would be to use 2 routing tables (as done in wg-policy) but working differently. Leave main intact and customize your new table according to your needs to route out wg vpn. Then add a "ip rule" for adresses TO to use main table and a rule with a lower priority for the rest to use your new table. This way you don't have to make soo specific routes.

You could make a loop to copy routes between the tables as needed as you probably need to add local routes aswell.
In this example I copy all routes except wg0 routes to my new table:
# Create ip table 117 without VPN
ip route flush table 117 2>/dev/null # Clear table 117
ip route show table main | while read ROUTE # Copy all routes from main table to t>
        if ! echo "$ROUTE" | grep 'wg0' ; then
                ip route add table 117 $ROUTE
        } 1> /dev/null

Adjust to your needs.
Good luck!

Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!