0

I have setup a wireguard connection, but I have some problems with routing. I have two locations where wireguard computers establishing VPN are behind internet provider's routers. I can be at one or another location. That means that I need to have a remote access to the other site in order to setup the VPN. VPN was successfully established, and it broke. Since I cannot login to the remote location I cannot set it up again. I have to wait to get to another location. I cannot login to a distant location because of a problem described below.

I have setup a remote SSH access to these computers, so I can access them via internet, by entering NAT into routers. I login to router address and router forwards SSH to internal address, and SSH access works fine, but there is a catch.

As soon as I bring up wg0 interface and try to establish VPN, SSH access does not work any more. I have analyzed the traffic, and the following happens. When I start SSH, router forwards it and wireguard computer receives SYN packet on eth0 interface. However, SYN, ACK packet is not sent back via eth0, but via wg0 interface, when wg0 is active. Without wg0 interface SSH work fine. SSH also works in local network 192.168.1.0/24 regardless of wg0 interface.

How can keep my SSH connectivity and use wireguard VPN connection at the same time? I have another interface lan0 on that computer, which is not connected right now. Should I connect lan0 to intranet, too and use it for SSH? I guess the problem with wireguard would remain with lan0 interface as it would be connected to same network as eth0.

Here is some additional information about connections, routes, etc.

Without wg0 interface:

wg-quick down wg0 output:

[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] nft -f /dev/fd/63

ip -4 addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 8e:b7:6b:c9:08:7d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.250/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
       valid_lft 84256sec preferred_lft 84256sec
3: lan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 8e:b7:6b:c9:08:9d brd ff:ff:ff:ff:ff:ff

ip route:

default via 192.168.1.1 dev eth0 
default via 192.168.1.1 dev eth0 proto dhcp metric 100 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.250 metric 100

ip rule:

0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default

With wg0 interface:

wg-quick up wg0 output:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.0.2/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] nft -f /dev/fd/63

ip -4 addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 8e:b7:6b:c9:08:7d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.250/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
       valid_lft 84320sec preferred_lft 84320sec
3: lan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group 
default qlen 1000
    link/ether 8e:b7:6b:c9:08:9d brd ff:ff:ff:ff:ff:ff
14: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.0.2/24 scope global wg0
       valid_lft forever preferred_lft forever

ip route:

default via 192.168.1.1 dev eth0 
default via 192.168.1.1 dev eth0 proto dhcp metric 100 
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.2 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.250 metric 100 

ip rule:

0:  from all lookup local
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default

Update: After some more testing, I found out that wg-quick sets up some ip routes and rules. I suspect that these are messing up the SSH connectivity. If I try the following commands SSH still works.

ip link add dev wg0 type wireguard
ip address add dev wg0 10.0.0.2/24
wg set wg0 private-key /root/wgprivate.key
wg set wg0 listen-port 37723
ip link set wg0 up
wg set wg0 peer <key> allowed-ips 0.0.0.0/0 persistent-keepalive 25 endpoint <remote hostname>:<remote port>

Since I do not have access to the remote site until weekend, I will try to find out, which commands in wg-quick cause the erratic behaviour. When I will have access to the remote site, I will establish VPN again without wg-quick. I did that already before, but wanted to automate it with wg-quick.

0

have a look here, but let it boil down a bit to your problem:

You can use iptables to mark the packages to the destination port 22

iptables -t mangle -A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -j MARK --set-mark 22

So you can insert a high priority rule to route these packages through eth0

ip rule add priority 32000 fwmark 22 table 22
ip route flush table 22
ip route add table 22 default dev eth0

Have not tested it, and a possible side effect could be that you are no longer able to connect port 22 via the VPN

0

After some research I found out that I do not want the routing that wg-quick makes after establishing the connection. So, the solution is pretty simple. Put a line

Table = off

in [Interface] section. That instructs wg-quick not to make ip rules and routes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.