WireGuard – Resolving UDP2RAW Routing Issues for TCP Port on Server

ip-routingroutingwireguard

I have successfully made a connection to wireguard through TCP using udp2raw.

The abstract is:

  My local MAC               Server Via TCP             Wireguard On the Server
127.0.0.1:3333 (UDP) <---> 52.55.198.100:70 (TCP) <----> 52.55.198.100:64731 (UDP)

And I connect to 127.0.0.1:3333 (via the wireguard client on MacOS) now and it works, well not exactly.

The thing is that it didn't work at first, I excluded the server's ip from allowedips.

For this purpose I used:

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

For allowed ips I had:

::/0, 1.0.0.0/8, 2.0.0.0/8, 3.0.0.0/8, 4.0.0.0/6, 8.0.0.0/7, 11.0.0.0/8, 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, 1.1.1.1/32, 1.0.0.1/32

Which is basically the default excluding local ips.

And in Disallowed IPs I added 52.55.198.100 and here was the end result:

0.0.0.0/3, 32.0.0.0/4, 48.0.0.0/6, 52.0.0.0/11, 52.32.0.0/12, 52.48.0.0/14, 52.52.0.0/15, 52.54.0.0/16, 52.55.0.0/17, 52.55.128.0/18, 52.55.192.0/22, 52.55.196.0/23, 52.55.198.0/26, 52.55.198.64/27, 52.55.198.96/30, 52.55.198.101/32, 52.55.198.102/31, 52.55.198.104/29, 52.55.198.112/28, 52.55.198.128/25, 52.55.199.0/24, 52.55.200.0/21, 52.55.208.0/20, 52.55.224.0/19, 52.56.0.0/13, 52.64.0.0/10, 52.128.0.0/9, 53.0.0.0/8, 54.0.0.0/7, 56.0.0.0/5, 64.0.0.0/2, 128.0.0.0/1, ::/0

And here's whole my client's config :

[Interface]
PrivateKey = Gsss
Address = 10.66.66.19/32, fd42:42:42::19/128
DNS = 1.1.1.1, 1.0.0.1
MTU = 1280

[Peer]
PublicKey = Lsss
PresharedKey = fsss
AllowedIPs = 0.0.0.0/3, 32.0.0.0/4, 48.0.0.0/6, 52.0.0.0/11, 52.32.0.0/12, 52.48.0.0/14, 52.52.0.0/15, 52.54.0.0/16, 52.55.0.0/17, 52.55.128.0/18, 52.55.192.0/22, 52.55.196.0/23, 52.55.198.0/26, 52.55.198.64/27, 52.55.198.96/30, 52.55.198.101/32, 52.55.198.102/31, 52.55.198.104/29, 52.55.198.112/28, 52.55.198.128/25, 52.55.199.0/24, 52.55.200.0/21, 52.55.208.0/20, 52.55.224.0/19, 52.56.0.0/13, 52.64.0.0/10, 52.128.0.0/9, 53.0.0.0/8, 54.0.0.0/7, 56.0.0.0/5, 64.0.0.0/2, 128.0.0.0/1, ::/0
Endpoint = 127.0.0.1:3333

It works.

The Problem

Well everything works except I can't access my server anymore when the vpn is on, ssh doesn't work all the website on the server won't load for me, basically I can't access nothing from the server anymore , as soon as I turn on the VPN.

One interesting point is that, if I connect to ssh, then turn the vpn on it won't get disconnected by it and I can continue to use it, I can't open a new ssh however, I guess that's how this is connected right? tcp port 70 got open before this ran and that's why it works still.

I think I probably should add a route to keep only 52.55.198.100:70 excluded not everything else from the server as well. (Somehow keep this one address on my own interface (eth0) and everything else as usual through (wg0))

I have two clients a MacOS and another Ubuntu my main system is MacOS but I would love a solution that would work on Ubuntu as well.

If this can be solved from the server-side I'm open to it as well!
Actually prefer that so I don't have to deal with two clients just one server.

Here are my firewall rules on the server (csf)

#!/bin/bash
#/usr/sbin/iptables -t nat -A POSTROUTING -o ens192 -s 10.66.66.1/24 -j MASQUERADE

/usr/sbin/iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE
/usr/sbin/iptables -A INPUT -i wg0 -j ACCEPT
/usr/sbin/iptables -A FORWARD -i wg0 -j ACCEPT
/usr/sbin/iptables -A FORWARD -o wg0 -j ACCEPT
/usr/sbin/iptables -A FORWARD -i wg0 -o ens192 -m state --state RELATED,ESTABLISHED -j ACCEPT
/usr/sbin/iptables -A FORWARD -i ens192 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT

— Update

I think the answer is here:
https://www.procustodibus.com/blog/2022/02/wireguard-over-tcp/#point-to-internet

But since I have access to MacOS only right now I can't test it.

# route public IP of Endpoint B through LAN gateway
PreUp = ip route add 203.0.113.2 via 192.168.1.1 dev eth0
PostDown = ip route del 203.0.113.2 via 192.168.1.1 dev eth0

What is the alternative of those ip commands for MacOS?

I tried something like this:

route add -host 54.81.143.201 -interface en0

for the above thanks to https://superuser.com/a/756146/1006908
it doesn't solve the problem I just need port 70 (tcp) to be on interface en0, but it makes everything on it.

Workaround:

If I add the route, connect to Wireguard, then remove the route everything including ssh, and websites will work for me.

But it's obviously not sane and it didn't work for Ubuntu at all.

Best Answer

You can simply expose host network by adding 192.168.1.0/24 (or similar) in the AllowedIPs configuration of the client.

Then you can connect to your server and rest of the host network using their private ip without any problem. Note that traffic forwarding has to be enabled in server:

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

Related Solutions

VPN Router – VPN Router Not Replying to ARP Requests

The solution was to replace
/sbin/ip rule add from 192.168.0.0/24 table 200
with
ip rule add iif eth1 table 200
We dont want only packets from 192.168.0.0/24 to use routing table 200 but every packet from interface eth1.

Wireguard – How to Route All Traffic Through Wireguard Peer

You should probably start with using Table=off in the wg-quick conf on both S and P. The value of AllowedIPs= will not cause changes to the routes / policy routing rules on them then.

EDIT: Actually it should be fine to leave Table= untouched on P unless you need AllowedIPs= of S on it to be 0.0.0.0/0 instead of 192.168.60.0/24 for some reasons, e.g. need traffics originates from itself to be routed S. You don't need to mess with the routes and routing rules on P yourself since even the prefix in Address=192.168.60.2/24 should get the necessary route configured. The next paragraph probably does not apply to what you need -- although it might gives you some extra insights on how things work.

And you should probably use an additional IP subnet for S and P, e.g. 192.168.59.0/30. This will save you the hassle of needing extra ip rule. Remember to add the subnet route for 192.168.60.0/24 on P though, as with Table=off, only prefix routes will be added by the kernel for the prefix(es) in the Address= field(s). Make good use of PostUp= (and PreDown=) btw.

I don't suppose you want to route traffics that originates from S itself to P, so you probably want the following ip rule instead:

# ip rule add iif wg0 from 192.168.60.0/24 lookup 200

If you really need want to route e.g. traffics other than the ssh and wireguard server replies to P, you can additionally have:

# ip rule add iif lo lookup 200
# ip rule add iif lo ipproto tcp sport 22 lookup main
# ip rule add iif lo ipproto udp sport 51820 lookup main

Note: you can't just match with from 192.168.60.1 added in the first rule and omit the other two, because for non-replying traffics, the source address is often (if not always) chosen based on the decided route -- it's not set yet at this point.

Note that the order of the command normally determines the priority, so make sure you add the "superset" rule before the "subset" rules, otherwise the latter will be overridden by the former.

Also it's best to keep table 200 empty until all the desire rules are in position, otherwise remote access of the host could be cut off.

Finally nexthop makes no sense in route to an L3 tunnel:

# ip route add default dev wg0 table 200

P.S. Make sure you didn't just allow IP forwarding in the firewall but also enable it with sysctl.

The Problem

Best Answer

Related Solutions

VPN Router – VPN Router Not Replying to ARP Requests

Wireguard – How to Route All Traffic Through Wireguard Peer

Related Topic