Necessary components for a split wireguard tunnel

Installing and Using OpenWrt Network and Wireless Configuration
1

Apologies for a noob question, I've been searching but don't think I've made much progress.

Local net: 192.168.1.0/24
Remote net: 192.168.143.0/24
VPN net: 192.168.10.0/24

Wireguard peers:

  • local router 192.168.1.1 / 192.168.10.1
  • remote host 192.168.143.200 192.168.10.83

I want to divert internet traffic to some domains over wireguard to emerge from the remote net. To test that it's working, the result of curl ipinfo.io should describe the remote city rather than my local city.

I'll focus on ipinfo.io, 34.117.59.81.

Steps taken:

  • Ensure connectivity from local net to remote net: ssh 192.168.10.83
  • Ensure frequent handshakes between router and remote peer
  • add 34.117.59.81 to the AllowedIPs section of router's config for wireguard peer:
config wireguard_vpn 'm83'
	option public_key '<my_public_key>'
	list allowed_ips '192.168.10.83/32,34.117.59.81/32'
  • add a route in router's /etc/config/network to direct from local lan zone to peer
config route                  
        option interface 'lan'
        option target '34.117.59.81'
        option gateway '192.168.10.83'
  • add vpn interface to lan zone (automatic from wireguard package)
config zone
        option name 'lan'
        list network 'lan'
        list network ''
        list network 'vpn'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

Still, I can't curl and get the desired result either from the local net or when logged into the router itself. What am I missing?

2

Hi

i think it is not correct, because route is NOT on LAN interface,it is on 'm83' if i get it right ?

and second, you don't need static route
in wireguard config, you need to add

        option route_allowed_ips '1'

this will route 34.117.x.x to proper interface

1 Like
3

A better mousetrap.

Routing application traffic based on IP address, when you don't control and can't guarantee the reliability of that IP address, is not the most efficient approach. What happens if ipinfo.io moves to a different IP address? Many high-volume websites sit behind services such as Cloudflare, with multiple IP addresses available for use.

A better approach would be to use a proxy server, and configure your browser (or http_proxy / https_proxy environment variables) to send certain traffic to the proxy.

This thread describes another forum member's efforts to do just that: Usung 'smart routing' for browsers in LAN and on mobile - #3 by iplaywithtoys

I, too, happened to do the same thing last week. I wanted to send some traffic (determined by pattern-matching on the .TLD) out of an exit node in another location. So I did the same as that other forum member. And you can, too.

4

The idea is to route requests from 'lan' to the 'm83' device, where it will emerge to the Internet.

I tried removing the route and adding the wireguard option but no luck yet.

5

Thanks for this, it looks like quite a robust solution, thank you!

In actuality, I plan to target a few IP blocks managed by corporate entities, not ipinfo.io, so I'm willing to believe that while individual IPs will be dynamic they will generally stick to the fixed ranges.

Besides not wanting to bite off too much at once, my other reluctance to start with this approach is my openwrt router is an embedded tp-link device so containers or other infra in the network stack is a bridge too far for right now.

I'll read through more in detail to see what elements I can use.

6

Hi

from ssh, try
ip r
lets see where this route points

7

With my route in place:

#/etc/config/network
config route                  
        option interface 'lan'
        option target '34.117.59.81'
        option gateway '192.168.10.83'


root@OpenWrt:~# ip route
default via 173.56.93.1 dev eth0.2  src <myPublicIP>
173.56.93.0/24 dev eth0.2 scope link  src <myPublicIP>
192.168.1.0/24 dev br-lan scope link  src 192.168.1.1 
192.168.2.0/24 dev br-device_br scope link  src 192.168.2.1 
192.168.3.0/24 dev br-media_br scope link  src 192.168.3.1 
192.168.4.0/24 dev br-danger_br scope link  src 192.168.4.1 
192.168.10.0/24 dev vpn scope link  src 192.168.10.1

The route doesn't show up even after a reboot, perhaps it's invalid?

8

as you see, 192.168.10.83 is on dev VPN
so above line, interface lan, is NOT correct
please change it as i wrote above

9

Apologies, now it is

config route                  
        option interface 'vpn'
        option target '34.117.59.81'
        option gateway '192.168.10.83'


root@OpenWrt:~# ip route 
default via 173.56.93.1 dev eth0.2  src <mypublicip>
34.117.59.81 via 192.168.10.83 dev vpn 
173.56.93.0/24 dev eth0.2 scope link  src <mypublicip>
192.168.1.0/24 dev br-lan scope link  src 192.168.1.1 
192.168.2.0/24 dev br-device_br scope link  src 192.168.2.1 
192.168.3.0/24 dev br-media_br scope link  src 192.168.3.1 
192.168.4.0/24 dev br-danger_br scope link  src 192.168.4.1 
192.168.10.0/24 dev vpn scope link  src 192.168.10.1
10

so, finally, it is there

is your question answered/solved ?

11

Sadly no, it doesn't seem to be emerging on the other side.

root@OpenWrt:~# traceroute ipinfo.io
traceroute to ipinfo.io (34.117.59.81), 30 hops max, 38 byte packets
 1  192.168.10.83 (192.168.10.83)  35.135 ms  38.632 ms  37.638 ms
 2  *  *  *
 3  *  *  *
 4  *  *  *
 5  *  *  *
12

traceroute is an imperfect diagnostic tool and relies on many elements, some of which may be outside of your control. Seeing * * * can be perfectly normal depending on how devices on the other side of the VPN are configured.

A better test would be to see if the intended traffic for 34.117.59.81 actually makes it through on the port(s) you want. As you (presumably) don't control 34.117.59.81, one possible approach you could take is to run tcpdump on the remote VPN endpoint, listening for the traffic you want to verify.

13

well, your side, your router is now correctly configured
intended route is here, and it is traveling toward gateway

now, question is, other side ?
how is it configured?

maybe you could enable masquerading on VPN zone, so your package will travel with 192.168.10.1 address

14

I think unrelated to anything I've been doing here, my remote node m83 had some segfaults in its system log and now seems not to be coming back up. I'll resume this thread once I regain access to my remote node.

15

Back up faster than I thought.

I captured some traffic on m83 with tcpdump

:~$ sudo tcpdump -i wg0 -w m83.pcap

and brought the pcap file to my local machine to explore with Wireshark.

m83's routing table looks like

m83:~$ ip r                 
default via 192.168.143.1 dev eno1 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.1.0/24 dev wg0 scope link 
192.168.10.0/24 dev wg0 scope link 
192.168.143.0/24 dev eno1 proto kernel scope link src 192.168.143.235

and I found a packet initiated from a curl operation on my local host:

Screenshot from 2023-06-25 14-39-58
Screenshot from 2023-06-25 14-39-581680×42 12 KB

It looks like perhaps my masquerade is misconfigured if the source is the remote net's gateway.

16

It might be, if the displayed source was your remote net's gateway. But it isn't.

The source of that packet is 192.168.1.143, not 192.168.143.1.

That source IP address tells me that the curl attempt originated from a PC in your local network, with the IP address 192.168.1.143, and your VPN successfully sent it across to the other network.

17

Well that's an interesting, if embarrassing, coincidence - spot on.

It looks like the originating host did, in fact, get 1.143 from its local DHCP.

I'm pretty sketchy with my linux networking - is this then a question of creating a new routing rule on m83?

18

Possibly. You sniffed incoming traffic on the wg0 interface; it wouldn't hurt to also sniff the desired exit interface to see if there are corresponding outbound packets leaving that interface. The results may indicate what, if anything, might need to be adjusted.

19

It appears that m83 is not the main router at its site, it is a device on a LAN. This means that symmetric routes, if used, have to be configured in that site's main router:
192.168.10.0/24 via 192.168.143.200
192.168.1.0/24 via 192.168.143.200

The other option is to masquerade out of m83 so that Internet usage appears to originate from 192.168.143.200, then the main router (presumably 192.168.143.1) does not need another route to return it properly.

1 Like