4

I have a server A with a VPN configured to another server B. Currently, server A can ping server B by using the VPN address 10.12.0.1.

I would like to route all HTTPS traffic via server B and let other traffic use default interface.

To do that, I inspired from this unix stackexchange answer and have run the following commands:

# define route echo "200 myroute" >> /etc/iproute2/rt_tables # seems necessary sysctl -w net.ipv4.conf.wg1.rp_filter=2 # actual routing ip route add table 200 10.12.0.0/24 dev wg1 src 10.12.0.10 ip route add table 200 default via 10.12.0.1 # actual rule telling HTTPS traffic to use table 200 ip rule add iif lo ipproto tcp dport 443 lookup 200

Then, I run curl https://1.1.1.1 (or any other host) and I get the error Failed to connect to 1.1.1.1 port 443: No route to host. When I remove the rule, everything works again.

I guess my routing for table 200 is not correct but it seems to match the one from the original answer and the ones for the default interface.

Do you know how I can investigate and debug the issue?

Thank you

Additionnal information:

$ ip route show table 200 default via 10.12.0.1 dev wg1 10.12.0.0/24 dev wg1 scope link src 10.12.0.10 
$ ip route show dev wg1 10.12.0.0/24 proto kernel scope link src 10.12.0.10 
$ ip route get 1.1.1.1 ipproto tcp dport 443 1.1.1.1 via 10.12.0.1 dev wg1 table 200 src 10.12.0.10 uid 1001 cache 
$ ip route default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202 10.12.0.0/24 dev wg1 proto kernel scope link src 10.12.0.10 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202

The VPN is a Wireguard VPN. When configured to route all traffic through the VPN, everything works.

Improve this question

1 Answer 1

Reset to default
3

The "no route to host" error is likely due to trying to connect to a host (1.1.1.1) not included in your WireGuard AllowedIPs setting. Assuming you're using wg-quick, do this:

As step 1, in Server A's WireGuard configuration, adjust the AllowedIPs setting in the [Peer] section for Server B to include the IP addresses (or blocks of IP addresses) that you want to connect to.

Instead of 1.1.1.1, let's say that from Server A you wanted to be able to connect to any HTTPS server in the 192.0.2.0/24 block (and in particular there was a server at 192.0.2.123 that you are testing with). Let's also say you've initially set up your AllowedIPs setting on Server A for Server B to include the 10.12.0.0/24 block. Change this setting to the following:

AllowedIPs = 10.12.0.0/24, 192.0.2.0/24

Get rid of the routes and rules you previously set for table 200 on Server A, restart WireGuard (eg sudo wg-quick down wg1; sudo wg-quick up wg1), and test out this change by running the following:

$ curl -k https://192.0.2.123

That should at least get you beyond the "no route to host" error. If you're still getting errors with just that, you probably need to adjust your firewall/routing rules on Server B to allow it to forward packets from Server A to 192.0.2.0/24.

As step 2, in the [Interface] section of Server A's WireGuard configuration, add the following setting:

Table = 200

This will direct wg-quick to add the routes it creates automatically for you to your custom 200 routing table, instead of to your main table. Restart WireGuard again, and check your routing tables:

$ ip route default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202 $ ip route show table 200 10.12.0.0/24 dev wg1 scope link 192.0.2.0/24 dev wg1 scope link

Now add your special HTTPS policy rule:

$ sudo ip rule add iif lo ipproto tcp dport 443 lookup 200

And test it out:

$ curl -k https://192.0.2.123

As step 3, assuming you still want to be able to connect directly from Server A to Server B through WireGuard for services other than HTTPS (like SSH etc), add another policy rule on Server A for all connections to the 10.12.0.0/24 block:

$ sudo ip rule add to 10.12.0.0/24 table 200 priority 201

Now you should be able to use WireGuard to connect from Server A to Server B again:

$ ssh 10.12.0.1
Improve this answer
1
  • Sorry, my original account was deleted so I cannot mark the answer as accepted. Thank you for your answer, this was indeed the issue (and the advice on Table parameter is perfect). Commented Jun 10, 2021 at 7:54

You must log in to answer this question.