wireguard can not route 0.0.0.0/0

[RainCrowSP]

I'm running into a very strange problem. Running wireguard alone, with allowed ip = 0.0.0.0/0 is normal, running wireguard over phantun, allowed ip = 10.0.0.0/0 (my vpn internal IP) is also normal, but once I run wireguard over phantun, with allowed ip = 0.0.0.0/0, the network will not work. I don't know if this is a phantun problem or a wireguard problem, but I really need help, thanks.

[RainCrowSP]

Here is my config of wireguard:

[Interface]
PrivateKey = clientkey
DNS = 1.1.1.1
Address = 10.0.0.70/24
MTU = 1400

# start stop phantun
PreUp = iptables -t nat -A POSTROUTING -o eth0 -s 192.168.200.2 -j MASQUERADE
PreUp = RUST_LOG=info phantun_client --local 127.0.0.1:28888 --remote serverip:port &> /var/log/phantun_client.log &
PreUp = sleep 3
PostDown = iptables -t nat -D POSTROUTING -o eth0 -s 192.168.200.2 -j MASQUERADE
PostDown = killall phantun_client || true

[Peer]
PublicKey = serverkey
AllowedIPs = 10.0.0.0/24, 192.168.31.0/24
Endpoint = 127.0.0.1:28888
PersistentKeepalive = 25

It works fine. But if I change AllowedIPs = 0.0.0.0/0，the network will down. If I connect server without phantun, the setting AllowedIPs = 0.0.0.0/0 will work perfect.

[wenewzhang]

ip route can help you

[bjin]

wg-quick uses ip rule for global routing, something like

ip -4 route add 0.0.0.0/0 dev client table FWMARK
ip -4 rule add not fwmark FWMARK table FWMARK
ip -4 rule add table main suppress_prefixlength 0

which means you need to add additional rules to bypass all phantun traffics as well:

ip -4 rule add ipproto tcp to PHANTUN_REMOTE_IP dport PHANTUN_REMOTE_PORT table main pref 100

[RainCrowSP]

Thanks a lot, I'll try it out and report the results.

[RainCrowSP]

Unfortunately, it still doesn't work. I think the answer is very close. I am also trying to modify the routing. Now my ip rule shows

root@armbian:~# ip rule
0:      from all lookup local
98:     from all lookup main suppress_prefixlength 0
99:     not from all fwmark 0xca6c lookup 51820
100:    from all to SERVERIP ipproto tcp dport SERVERPORT lookup main
32766:  from all lookup main
32767:  from all lookup default

My ip route shows

root@armbian:~# ip route
default via 192.168.1.1 dev eth0 proto static metric 100 
10.0.0.0/24 dev phantun_wg0 proto kernel scope link src 10.0.0.70 
169.254.0.0/16 dev eth0 scope link metric 1000 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.70 metric 100 
192.168.31.0/24 dev phantun_wg0 scope link 
192.168.200.2 dev tun0 proto kernel scope link src 192.168.200.1 

[dndx]

If you just need to bypass the IP address of Phantun server then static route should be enough. No need for complex PBR setup with ip rule:

ip route add 11.22.33.44/32 via <GATEWAY_IP> dev <DEVICE>

Because /32 is longer than /0, so the new route will take precedence.

[RainCrowSP]

Thanks for your help! After I try this command, I can ping my server IP. But other IPs still not work. Even my servers wireguard IP get no reply.

If you just need to bypass the IP address of Phantun server then static route should be enough. No need for complex PBR setup with ip rule:

ip route add 11.22.33.44/32 via <GATEWAY_IP> dev <DEVICE>

Because /32 is longer than /0, so the new route will take precedence.

[jwangac]

You can try modifying AllowedIPs to exclude private addresses and your server's address. Use this calculator or Python's "ipaddress.IPv4Network" library for such calculations:

https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/

Set "Allowed IPs" to "0.0.0.0/0". Set Disallowed IPs to "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16", followed by your server's IP address. Calculate and append "10.0.0.0/24, 192.168.31.0/24" (your vpn internal IP) to the end of the results.

For example, if your server's IP is 11.22.33.44, the result is

AllowedIPs = 0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/12, 11.16.0.0/14, 11.20.0.0/15, 11.22.0.0/19, 11.22.32.0/24, 11.22.33.0/27, 11.22.33.32/29, 11.22.33.40/30, 11.22.33.45/32, 11.22.33.46/31, 11.22.33.48/28, 11.22.33.64/26, 11.22.33.128/25, 11.22.34.0/23, 11.22.36.0/22, 11.22.40.0/21, 11.22.48.0/20, 11.22.64.0/18, 11.22.128.0/17, 11.23.0.0/16, 11.24.0.0/13, 11.32.0.0/11, 11.64.0.0/10, 11.128.0.0/9, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, 172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3, 10.0.0.0/24, 192.168.31.0/24

[dndx]

@RainCrowSP If you do a ip r g <IP OF YOUR SERVER>, do you see the correct route being selected?

[RainCrowSP]

Thanks @jwangac , your method is very successful, but my server IP is a dynamic IP, I have to reset it every time I encounter IP changes.

[RainCrowSP]

@dndx In the end, I succeeded according to your method. Maybe there was a problem with the previous settings. The route obtained at the beginning was wrong. After resetting, it succeeded. This problem has been perfectly solved! Thanks to the author for his enthusiastic answer.

@RainCrowSP If you do a ip r g <IP OF YOUR SERVER>, do you see the correct route being selected?

[dndx]

@RainCrowSP Sounds great!