Forward traffic from Wireguard Server to Wireguard Client

openingthewrt · February 4, 2024, 3:56am

I've been researching topics here on this exact problem, and I've been attempting a solution at achieving the following goals:

Have a Wireguard Server setup to access LAN devices remotely from LAPTOP (done)
For all other traffic going through Wireguard Server, forward it to a WireGuard Client using a commercial VPN. Reason: I can allow multiple devices to connect to the Commercial VPN, as the Commercial VPN limits the keys given out.

Here is my current approach I've attempted:

Create a WireGuard Server in zone WG_SERVER [inherit LAN permissions]
Create a WireGuard Client in zone WG_CLIENT [inherit WAN permissions]
Forward WG_SERVER -> WG_CLIENT in the firewall

Right now, I don't have issues with the WireGuard Server accessing LAN, but forwarding the rest of my traffic to the WireGuard Client is what I'm having difficulty with.

The issue is, I'm not sure how to configure the allowing all traffic to flow through the WireGuard Server from LAPTOP without disrupting the usual traffic for devices on LAN. I attempted adding the Allowed IPs 0.0.0.0/0 to the WireGuard Server/LAPTOP, but that was a mistake, as all traffic (LAN included) attempted to go through WireGuard Server and fail.

Main thread I was reading was here.

Below is the advice I was somewhat following.

It depends on your implementation. If the WG server is meant for local lan access only, then it needs a separate zone and only lan zone forwarding. If you also want to access the internet though Mullvad, then you can assign it to lan zone, without any other changes. If you only want to provide internet via Mullvad without lan access, then you need to create a new zone and allow forwarding to Mulvad.

I'm not sure if there is a policy based routing solution that could address this.

egc · February 4, 2024, 7:31am

Policy Based routing is the way to go.

Problem is that traffic which comes in via the WAN to the WG server also has to go out via the WAN, but to get internet access via the WG client the WG client has to route all traffic out via WG interface instead of the WAN.

If you want all traffic via the WG client then you can route all traffic via the WG client by default and only route the WG server port out via the WAN

If you want some LAN clients and/or some destinations going via the WG interface and some via the WAN then remove the default routing via the WG client by Disabling Route Allowed IPs and use PBR to route the desired LAN clients/destinations via the WG client, all described in the PBR guide

openingthewrt · February 4, 2024, 1:49pm

Thanks for the document link. I was suspecting that PBR was the only solution, just wanted to double check.

I’m going to attempt to set this up and report back my findings. If I get it working, I’m thinking this might be a good entry to add into the WireGuard wiki, as this seems to have been asked a few times before.

openingthewrt · February 4, 2024, 4:40pm

Alright, I'm following the instructions for WireGuard Server / WireGuard Client Scenario 2. Gonna debug here, as it my first time using PBR, and I'm having some issues. Just want to make sure I understand what I'm doing.

For this, we are assuming that 192.168.200.xxx is the subnet for the wireguard server.

Relevant part of /etc/config/pbr:

config pbr 'config'
  list ignored_interface 'wgserver'
  ...
config policy
  option name 'Ignore Local Traffic'
  option interface 'ignore'
  option dest_addr '192.168.200.0/24'
  ...

For the above, My interpretation is that the wgserver is included so it can be supported for PBR routing. Since I want to tunnel wgserver -> wgclient, this makes sense.

For the policy, I'm not quite sure I 100% understand it. Here, I'm ignoring the wgserver VPN subnet.. I'm assuming this means that I'm actually ignoring the VPN subnet from egressing to WAN, and therefore will egress to wgclient? Looking at luci-app, the interface is defaulting to wan it seems, despite the ignore option in the file.

Relevant part of /etc/config/network (DO NOT modify default OpenWrt network settings for neither wan nor lan):

config interface 'wgclient'
  option proto 'wireguard'
  ...

config wireguard_wgclient
  list allowed_ips '0.0.0.0/0'
  list allowed_ips '::0/0'
  option endpoint_port '51820'
  ...

config interface 'wgserver'
  option proto 'wireguard'
  option listen_port '61820'
  list addresses '192.168.200.1/24'
  ...

config wireguard_wgserver
  list allowed_ips '192.168.200.2/32'
  option route_allowed_ips '1'

Having wgclient allow all IPs makes sense. I disabled route allowed IPs so it doesn't try to steal all traffic (PBR will be routing). Now the wgserver the port/subnet, and one of the peers is configured to use a specific ip addres and route allowed ips.

Relevant part of /etc/config/firewall:

config zone
  option name 'lan'
  list network 'lan'
  list network 'wgserver'
  ...

config zone
  option name 'wan'
  list network 'wan'
  list network 'wgclient'
  ...

config rule
  option name 'Allow-WG-Inbound'
  option target 'ACCEPT'
  option src '*'
  option proto 'udp'
  option dest_port '61820'

No issues here - this is as expected.

Issue I'm having now is that this doesn't seem to work. Enabled WireGuard on my laptop (still on the same network), and now I can't even get a request anywhere. nslookup returns REFUSED. I can access LAN devices just fine, but all egress traffic seems to be blocked.

I was thinking that maybe I need a specific PBR policy to explicitly route to from wgserver to wgclient?

config policy
  option name 'wgserver -> wgclient'
  option src_addr '192.168.200.0/24'
  option interface 'wgclient'
  option dest_addr 'IP_FROM_COMMERCIAL_VPN'
  option chain = 'forward'

egc · February 4, 2024, 6:16pm

openingthewrt:

config policy
  option name 'wgserver -> wgclient'
  option src_addr '192.168.200.0/24'
  option interface 'wgclient'
  option dest_addr 'IP_FROM_COMMERCIAL_VPN'
  option chain = 'forward'

The last two lines can be removed.
You simply specify the source address and the interface to use.

Reboot and try again

openingthewrt · February 4, 2024, 6:59pm

Nice, this worked for me greatly appreciate the help.

Now on to the next step of troubleshooting. This setup is now working! However, I'm now I'm detecting DNS leaks, which I suspected was going to happen. Currently, I have unbound running on my OpenWRT. I'm currently running it using the Parallel dnsmasq configuration. Copy/pasting the config here in case it changes:

/etc/config/unbound:

config unbound
  # likely you want to match domain option between Unbound and dnsmasq
  option dhcp_link 'dnsmasq'
  option domain 'yourdomain'
  option listen_port '53'
  ...

/etc/config/dhcp:

config dnsmasq
  option domain 'yourdomain'
  option noresolv '1'
  option port '1053'
  option resolvfile '/tmp/resolv.conf.auto'
  ...

config dhcp 'lan'
  # dnsmasq may not issue DNS option if not std. configuration
  list dhcp_option 'option:dns-server,0.0.0.0'
  ...

On a site note, I've enabled DoT for Unbound via cloudfare, but I don't think that is super meaningful for DNS leaks.

Is there a good way to use the commercial VPNs provided DNS server for egress requests, while using unbound for LAN lookups? Not sure if this is another PBR for routing port 53 to the respective DNS servers.

I tried updating the DNS servers on wgserver to the following:

config interface 'wgserver'
  option dns `COMMERCIAL DNS SERVER`
  option dns `127.0.0.1`
  ...

and updating my laptop to point to those servers as well (well 192.168.1.1 as the secondary after the commercial DNS). However, the commercial DNS server failed to resolve.

openingthewrt · February 4, 2024, 9:04pm

Well it works for my laptop, but now my iPhone WireGuard doesn’t seem to like the updates. Strange business, I’ll keep diagnosing that.

egc · February 4, 2024, 9:12pm

On the wg server clients you can just set the dns server of the wg client vpn provider.

The traffic from these clients will be routed through the wg client unless you have dns hijacking implemented

If you have lan clients using the wgclient you can use dns option 6 with tagging the clients.
See my notes paragraph about option 6

egc · February 4, 2024, 9:13pm

Remove that, you set the dns server on the clients as outlined in my previous post

openingthewrt · February 4, 2024, 10:02pm

The traffic from these clients will be routed through the wg client unless you have dns hijacking implemented

Such a simple mistake - I had this enabled. I just disabled this, and now everything is working as expected, even on my iPhone.

Can't think you enough for your help! With this, I'd like to add a Wiki entry for this basic WireGuard Client -> WireGuard Server configuration. I haven't done this before, so I'll do some research first. Probably won't get around to it too soon though, and this thread is a decent enough debug guide.

Funnily enough, I actually have a home server I'd like to route egress through the wgclient, so eventually I'll try testing this out as well. I'll consider tagging clients if I face dns leaks at that point.

openingthewrt · February 4, 2024, 10:19pm

Alright, one final (minor) hiccup. Let's say I have a server myserver.lan that resolves to 192.168.1.123. On my wg server client (iPhone), I set two dns servers as follows:

DNS = COMMERCIAL_VPN,192.168.1.1

If it fails to find it in the commercial VPN as expected, so I was hoping it would fall back onto unbound. I made sure that the wgserver was configured on unbound for lan and trigger.

config unbound 'ub_main'
   ...
   list iface_wan 'wan'
   list iface_lan 'lan'
   list iface_lan 'wgserver'
   list iface_trig 'lan'
   list iface_trig 'wan'
   list iface_trig 'wgserver'

If I attempt to access a web service via http://userver.lan:1234, it fails, but http://192.168.1.123:1234 works fine.

While this is just a nice-to-have, I'm curious why it won't resolve. I even have a dig utility on iPhone and I can see it resolves to 192.168.1.123 as an A record, so I have no idea why it can't seem to find it.

egc · February 5, 2024, 7:10am

Great to hear it is working
About unbound, I do not know , I am not using unbound so you better make a separate thread about this as it is outside the scope of this thread.

system · February 15, 2024, 7:12am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.