Hi together,
i want to achive the following:
Connect from Mobile Devices to own vpn server by wireguard
I want on the whole Traffic from my home network sending with wireguard to nordvpn.
I have already extract the Publi and Private Keys and it seems they work.
But when i start the nordvpn interface , the traffic goes through wireguard. but i cant connect anymore to my "own" wireguard server.
it would be greate if some one could help me out, or explain what im doing wrong.
When you start the nordvpn wireguard interface, if you have some entries in the wg peer config -> list of "allowed ipv4", then:
If you also click "create route for allowed", then:
You can see the created routes under status -> routing in LUCI when wg tunnel is running.
So if you have "0.0.0.0/0" in "allowed ipv4" and you checked the magic routes checkbox, then when you start the tunnel, openwrt will route all ipv4 into the vpn tunnel...
Probably including some stuff it shouldn't in your setup. namely traffic related to your client-vpn wg setup.
Post your peer -> allowed list for both wg tunnels here.
Also post active routes when both tunnels are running (statusk -> routing).
When you get access to your home via the WG server you access the WAN interface, however return traffic goes out via the WG client interface as you have default routing via the the WG client interface and that is a no go.
To solve this situation you have to route the WG servers return traffic out via the WAN.
The magic word(s) is PBR , Policy Based Routing will do that for you
https://openwrt.org/docs/guide-user/network/routing/pbr
The PBR app even does that automatically, make sure you only set the WG listen port on the WG server, the PBR app picks this up and automagically route this via the WAN so that the return traffic goes out via the WAN
Thanks for the screenshots!
Configuration and routes look good, actually.
You have two default routes (0.0.0.0/0), one with metric 1 and one with metric 0.
The default route with the lowest metric 0 will be chosen. Any traffic going to fx. a public IP will use that. The metric 0 route points into the NordVPN interface.
(The metric 0 route was likely created automatically by some Wireguard-related software, see above post.)
My best guess is: if you connect to your MobileDevices VPN from the outside (a public IP), your MobileDevice wireguard actually accepts the connection handshake. Then it sends a handshake reply.
-if- the NordVPN tunnel is active, that metric 0 route into the NordVPN tunnel exists. And that means the MobileVPN handshake reply gets caught up in there, instead of going back out the WAN interface to your phone or whatever.
So...
What you want is probably to route reply traffic back the same way that the initiation for that traffic came from. Pretty much what everybody wants in 99.9% of all cases, of course 
(Notable exceptions that come to mind are ISPs and TV broadcasters, but whatever.)
Happens to be a normal feature in lots of high-end equipment... I recently looked at the network equipment for a very large media company, and those were configured to their default setting - which is to remember where connections come from, and send the reply back the same way.
Unfortunately for you, that is NOT how Linux works...
Linux insists that it is an Internet Router, and what it does is consult the whole IPv4 routing table for every darn packet.
Then when it finds the longest prefix that matches, that's where the packet goes.
It won't remember where a connection came from, and you have to figure out a way of manually forcing the MobileDevice handshake reply out the correct interface.
It's super stupid, and it causes lots of people endless problems, but that's just the way it's done, historically and now. (unless you pay for very expensive equipment of course.)
Hmm, now I'm wondering how the traffic from your NordVPN wireguard daemon gets out your WAN interface and over to the Nord VPN gateway without getting caught up in the metric 0 route.
Probably there is a special IPv4 "rule" to select -either- an alternative, non-default routing table, -or- select the metric 1 route.
Could you post this too:
# ip -4 rule
So we can check that out?
Perhaps we can piggy-back on how that works.
For example we can create a Traffic Rule to apply a "firewall mark" for all outgoing MobileVPN gateway traffic:
Aaand then an IPv4 rule to match the mark and select an alternate route table which always points to WAN:
Hmm.
Alternatively, you could drop the "automagic" creation of default routes by the wireguard software into the NordVPN tunnel in the nordvpn peer settings.
And then you would need to create your own default route into the NordVPN tunnel, but -only- apply it for traffic coming from your LAN zone.
This is maybe the easiest solution; fx. just drop a fwmark on anything from "lan" (traffic rule), add an ipv4 rule to select routing table "nordvpn" for anything matching the fwmark, and in the "nordvpn" routing table just have one entry, 0.0.0.0/0 -> wg_NordVPN. (default into the vpn interface.)
Yep this is probably by far the easiest way.
EDIT: Let me know if you want a couple UCI commands that will do what you want. I don't think we even need to use a traffic rule and fwmark, we can just make an ipv4 rule for a specific Incoming Interface.
That is exactly what I tried to describe in my post and what PBR is about to solve 
Lets see some configs to start with but you are on the right way to solve this
Please connect to your OpenWRT device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact keys, passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
ip route show
ip route show table all
ip rule show
wg show
service pbr status
i tried the esier solution and dropt the 0.0.0.0 at nordvpn interface and the check for "route allowed ips" too.
i have send you the details. could you check if something private still in there ? if not i post the data here.
Ooh excellent! I was actually super tired yesterday, didn't comprehend much, just stream-of-consciousness wrote out what I thought might be happening. Oops... Apologies for repeating already stated facts.
It is in the "General Settings" tab under the "Action" dropdown all the way at the bottom.
Check the first screenshot again, it shows this.
After removing the VPN's magic route, you also need to create a new manual one.
CLI example:
1) Create nordvpn route table:
==============================
root@OpenWrt:~# echo "500 nordvpn" >> /etc/iproute2/rt_tables
2) Create ipv4 rule: inbound traffic from lan uses nordvpn table
================================================================
root@OpenWrt:~# uci add network rule
root@OpenWrt:~# uci set network.@rule[-1].in='lan'
root@OpenWrt:~# uci set network.@rule[-1].lookup='nordvpn'
root@OpenWrt:~# uci set network.@rule[-1].priority='10000'
3) Create ipv4 rule: exception for traffic towards inside network, use main table
=================================================================================
root@OpenWrt:~# uci add network rule
root@OpenWrt:~# uci set network.@rule[-1].in='lan'
root@OpenWrt:~# uci set network.@rule[-1].dest='192.168.0.0/16'
root@OpenWrt:~# uci set network.@rule[-1].lookup='main'
root@OpenWrt:~# uci set network.@rule[-1].priority='9000'
4) Add a default route to nordvpn table, goes into nordvpn wg device.
=====================================================================
root@OpenWrt:~# uci add network route
root@OpenWrt:~# uci set network.@route[-1].target='0.0.0.0/0'
root@OpenWrt:~# uci set network.@route[-1].interface='wg_Nordvpn'
root@OpenWrt:~# uci set network.@route[-1].table='nordvpn'
5) Commit - make sure the nordvpn tunnel is up.
===============================================
root@OpenWrt:~# uci commit network
root@OpenWrt:~# ubus call network reload
Creates a new routing table, creates a default route to nordvpn device, creates an IPv4 rule. The rule says: if inbound interface is "lan", send to route table "nordvpn".
You can do this in LUCI as well, all except for creating the routing table.
(These commands match the last example I gave... The one without fwmark and traffic rules.)
Also note that egc's solution might be easier to work with! Might not need the CLI... I haven't tried it myself. But probably much easier. Recommend.
i have installed "Policy Base Routing" this works like a charm. @egc helped me a lot by pm and explained how this works.
for example i route the whole traffic to nordvpn by:
and if i connect my wireguard phone to openwrt i also route this through the "nordvpn" if i disable this route i would get back my home ip.
the policy base routing is insane. i gonna try now couple more routings.
but the problem earlier is solved. thanks a lot to @egc and @appelsin .
thread are solved. thanks.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
