Wireguard as default gw

Installing and Using OpenWrt
5

The other end is another RPi that sits in 192.168.1.0/24.
ISP1's router has antother port forwardind for it.

[Interface]
Address = 10.10.10.3/24
ListenPort = 51821
PrivateKey = <PrivateKey>

PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
AllowedIPs = 10.10.10.2/32
PublicKey = <PrivateKey>
6

Would you be willing to try 'reversing' your connection...

currently, the OpenWrt router is listening for the connection from the Pi. If you did it the other way, it might work better.

7

Unfortunately, I cannot do that because of the ISP's routers.
I can manage (open ports) only ISP1's...

8

Ok... understood.

Let me think about this some more. I'm not sure why it would fail to handshake with the allowed IPs set to 0.0.0.0/0.

9

What happens if you turn on masquerading on your OpenWrt wan zone? Is there a specific reason why you currently have that disabled?

(do this in conduction with setting the allowed IPs to 0.0.0.0/0)

10

I know, it has me puzzle too.

I first thought it might be something with the openwrt router (although it has just been flashed and upgraded to OpenWrt 21.02.2 r16495-bf0c965af0 recently...) and started playing with another old dsl modem I had around, also flashed to openwrt, but this second one does not have wan port and it had to be set up differently, I guess. It is a Comtrend AR-5387 un.

But I have a feeling it might be related to the default gw 0.0.0.0 may be clashing with the port forward needed to start the tunnel??.

11

I haven't turn masquerading on WAN only because I want 100% of the traffic sent through the VPN, and therefore masquerading behind 10.10.10.1.

12

That's possible... but actually it really only should affect outbound traffic.

13

You can safely turn on masquerading on the WAN... once the tunnel is up, everything will (nominally) go through the tunnel as long as the allowed IPs = 0.0.0.0/0. Try the masquerading and see if it works.

14

I just gave it a go, and the tests give me the very same results I got without enabling masq on wan.

15

Bummer. Ok. I’ll continue thinking.

1 Like
16

I always suggest to recheck the routes (while allowed ips - 0.0.0.0/0 should assure they are injected with the right priority) so just post ip ro to check.

Next step is always to check if the package is leaving the interface tcpdump -n -i wireguard_wg0

If package is not leaving the interface it means that either routing is wrong or package is blocked by firewall (for that enable logging on the firewall).

17

Good point,

This is the routing table out of my last test.
The default route is obvioulsly not what I want

# ip r
default via 192.168.1.1 dev eth0.2 
10.10.10.1 dev wg0 scope link 
192.168.2.0/24 dev wg0 scope link 
192.168.17.0/24 dev br-lan scope link  src 192.168.17.1 
192.168.1.0/24 dev eth0.2 scope link  src 192.168.1.254

An this is the routing table when I revert back to list allowed_ips '0.0.0.0/0'

# ip r
default dev wg0 scope link 
192.168.17.0/24 dev br-lan scope link  src 192.168.17.1 
192.168.1.0/24 dev eth0.2 scope link  src 192.168.1.254

The routing table looks better to me, but no Handshake now.
tcpdump from openwrt shows c

# tcpdump -n -i wg0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
09:33:37.148097 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 92
09:33:42.268465 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 92
09:33:48.028253 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 92
09:33:53.147997 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 92
09:33:58.190346 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 92

And when I ping the other end of the tunnel 10.10.10.2 from a different ssh session

# ping 10.10.10.2
PING 10.10.10.2 (10.10.10.2): 56 data bytes

I wet this in tcpdump

...
09:33:58.190346 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 92
09:33:58.190346 IP 10.23.5.6.50123 > 80.161.179.178.59682: UDP, length 92
09:34:03.388300 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 92
09:34:06.345844 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 0, length 64
09:34:07.347342 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 1, length 64
09:34:08.348883 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 2, length 64
09:34:09.350355 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 3, length 64
09:34:09.361950 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 148
09:34:10.350792 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 4, length 64
09:34:11.351213 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 5, length 64
09:34:12.351637 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 6, length 64
09:34:13.352054 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 7, length 64
09:34:14.352472 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 8, length 64
09:34:14.888157 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 148
09:34:15.352959 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 9, length 64
09:34:16.353388 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 10, length 64
09:34:17.353808 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 11, length 64
09:34:18.354234 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 12, length 64
09:34:19.354656 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 13, length 64
09:34:20.264331 IP 10.10.10.1.51820 > some_public_ip.59682: UDP, length 148
09:34:20.355077 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 14, length 64
09:34:21.355504 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 15, length 64
09:34:22.355939 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 16585, seq 16, length 64

And I end up canceling the ping command

# ping 10.10.10.2
PING 10.10.10.2 (10.10.10.2): 56 data bytes
^C
18

Ok, looks like that you also loose the route to the other side to establish the tunnel.
So you would need a fixed route to the public IP of the WG peer and point it to your WAN GW
There are several ways of doing that, suggest to search forum. Here is one solution

19

Thanks, @faser
Makes sense, but wouldn't this situation be the case in any full (0.0.0.0/0) tunnel, wether openwrt is part of the equation or not?
Another problem is that the other end does not have a predictable IP, that's why I forward ports in ISP1's router.
The route you are suggesting would have to be dynamic and based on destination port being udp/51820 and source IP not in 10.10.10.1/24 range, wouldn't it?

20

It would be, therefore a script (e.g. wg-quick) add respective routes/rules to make the vpn server still reachable.
https://manpages.debian.org/unstable/wireguard-tools/wg-quick.8.en.html

Yes therefore it might be easier to work with firewall rules and multiple GWs easier.

21

mmm, I see.

I'm just surprised there is not a generic solution in openwrt to this situation yet, as seems to me I am not doing something too weird here.

I'll get my head around all the documentation you pointed out and report back.

Regards,

22

Maybe there is, but I am not aware off. Generally for road warrior setup (that's what I call what you are trying to get) openvpn is the better solution. I use wireguard only for site-to-site VPN.

23

With tcpdump I can see the incoming handshakes from the remote peer.

If I set the tunnel that "works"
AllowedIPs = 10.10.10.1/32, 192.168.17.0/24
I can see the communication between peers

# tcpdump -n -i any udp port 51820
01:58:58.957660 IP public_ip.42737 > 192.168.1.254.51820: UDP, length 148
01:58:58.981970 IP 192.168.1.254.51820 > public_ip.42737: UDP, length 92

If I set the tunnel that "doesn't work"
AllowedIPs = 0.0.0.0/0
I can see the communication between peers being "asymetric".

# tcpdump -n -i any udp port 51820
02:14:00.053064 IP public_ip.42737 > 192.168.172.254.51820: UDP, length 148
02:14:00.077433 IP 10.10.10.1.51820 > public_ip.42737: UDP, length 92

The response with source IP 10.10.10.1 doesn't seem right.
To fix it, I added the following route manually

# ip route add public_ip/32 via 192.168.1.1 dev eth0.2

And after a few seconds, magic happens

# tcpdump -n -i any udp port 51820
03:01:25.806255 ethertype IPv4, IP public_ip.42737 > 192.168.172.254.51820: UDP, length 128
03:01:25.806255 IP public_ip.42737 > 192.168.172.254.51820: UDP, length 128
03:01:26.720308 IP 192.168.172.254.51820 > public_ip.42737: UDP, length 128

And now it also works from a client.

Now I need to figure out how to make this permanent. I'll have to create some sort of script that gets the public IP and creates the route. :upside_down_face:

24

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