Basic setup question - gateway <> hub connectivity

[atakacs]

Pretty new to this product so I might be missing something obvious. Please bear with me

This pertains to support ticket #04446330

We want to use VeeamPN to connect multiple "remote offices" to a central hub, which I guess is a typical use case for this product (in a self hosted approach - not in Azure / AWS).

So to start with I have deployed a Hub appliance in our central office and a single gateway. The setup was fairly straightforward as per documentation and we have the following "architecture":



Although the tunnel went up promptly my problem is that the gateway machine can't seem to "talk" to the hub

Code: Select all

root@localhost:~# traceroute 172.16.215.98
traceroute to 172.16.215.98 (172.16.215.98), 64 hops max
  1   172.16.107.254  0.629ms  0.611ms  0.644ms
  2   85.195.*.*  1.367ms  1.207ms  1.087ms
  3   82.197.*.*  1.578ms  1.190ms  1.214ms
  4   *  *  *
  5   *  *  *
  6   *  *  *

While the hub does connect to the gateway

Code: Select all

root@localhost:~# traceroute 172.16.107.254
traceroute to 172.16.107.254 (172.16.107.254), 64 hops max
  1   10.211.0.2  5.966ms  5.178ms  5.290ms
  2   172.16.107.254  5.949ms  6.105ms  5.896ms
root@localhost:~#

On the gateway my packets are egressing to the LAN gateway and then the public internet, which is obviously not the desired outcome.

This is on the appliances themselves - we have not started to look into routing / etc. Simply for each node so "see" the other end.

Any suggestion / pointer most appreciated ?

[HannesK]

Hello,
looks like the "route back" is missing (I don't know how often I forgot about that in my early days of setting up site-to-site VPNs .)

172.16.107.254 should have a static route to 172.16.215.0/24 via 172.16.107.235 (opposite direction is required on the central hub site)

you can also set the static route I mentioned earlier directly on your PCs, but that does not scale. I would always do that on the default gateways of the networks / locations.

For troubleshooting I always recommend tcpdump with simple ICMP packages. There your can see on every component, where the packet gets lost (which is where the routing entry is missing).

Best regards,
Hannes

[atakacs]

Thanks for your pointer - will look into it ASAP.

That being said isn't VeeamPN supposed to take care of this "out out the box" ?

[HannesK]

as I mentioned... that's something the network admin needs to manage (I often failed at that)

A VPN gateway can only do that, if it is the default gateway (VeeamPN is not the default gateway)

[atakacs]

Ok I am still not convinced tbh...

Again, we are speaking here of the gateway and hub machines (not other hosts on the same subnet, which obviously need those extra routes).

My understanding is that when the VPN tunnel is built automatic routes are dynamically added on both sides so that the traffic will go through the tunnel. At least that's my understanding and what I have observed thus far.

[HannesK]

My understanding is that when the VPN tunnel is built automatic routes are dynamically added on both sides so that the traffic will go through the tunnel

that works, if the tunnels are managed by the default gateway. that is usually the case, if the firewall ( = default gateway) also manages VPN tunnels (which is probably the case at most production environments)

Maybe I just do not understand your question

[atakacs]

well maybe I am not understanding how VeeamPN is supposed to work

Anyway, this is my current situation on the gateway machine

Code: Select all

root@localhost:~# ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:9b:7d:d8 brd ff:ff:ff:ff:ff:ff
    inet 172.16.107.235/24 brd 172.16.107.255 scope global ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe9b:7dd8/64 scope link
       valid_lft forever preferred_lft forever
4: wg.veeampn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.211.0.2/16 scope global wg.veeampn
       valid_lft forever preferred_lft forever
root@localhost:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 ens160
10.210.0.0      0.0.0.0         255.255.0.0     U     0      0        0 wg.veeampn
10.211.0.0      0.0.0.0         255.255.0.0     U     0      0        0 wg.veeampn
172.16.107.0    0.0.0.0         255.255.255.0   U     0      0        0 ens160
root@localhost:~#

So my local IP is 172.16.107.235 and I have a further IP 10.211.0.2/16 assigned via the gateway to hub tunnel.

Now, still being within the context of the gateway (client) and server (hub) machines, if I want to reach the subnet behind the hub host (subnet 172.16.215.0/24, the host itself being on 172.16.215.98) I guess I have to manually enter a route for 172.16.215.0/24 while on the hub, for some reason, I don't have to do anything as there is apparently already a route auto added as I would have expected on BOTH sides of the tunnel

Code: Select all

root@localhost:~# ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:b7:a7:c3 brd ff:ff:ff:ff:ff:ff
    inet 172.16.215.98/24 brd 172.16.215.255 scope global dynamic ens160
       valid_lft 73728sec preferred_lft 73728sec
    inet6 fe80::20c:29ff:feb7:a7c3/64 scope link
       valid_lft forever preferred_lft forever
3: tun.veeampn: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/none
    inet 10.210.0.1/16 brd 10.210.255.255 scope global tun.veeampn
       valid_lft forever preferred_lft forever
    inet6 fe80::7cce:c674:3a37:a07f/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
4: wg.veeampn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.211.0.1/16 scope global wg.veeampn
       valid_lft forever preferred_lft forever
root@localhost:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 ens160
10.210.0.0      0.0.0.0         255.255.0.0     U     0      0        0 tun.veeampn
10.211.0.0      0.0.0.0         255.255.0.0     U     0      0        0 wg.veeampn
172.16.107.0    0.0.0.0         255.255.255.0   U     0      0        0 wg.veeampn
172.16.215.0    0.0.0.0         255.255.255.0   U     0      0        0 ens160
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 ens160

I am ok to add that static route except that Netplan doesn't "know" of 10.211.0.2 (as it is, presumably, an dynamic IP added by the VPN tunnel).

All in all this is WAY more complicated that I'd have expected... I would have expected that to be a basic part of this whole package and I feel I am missing out on something...

So, again, my question: why does the gateway / client machine not auto configure with proper to access the hub subnet and, whever the reason, what would be the correct netplan syntax in my case ?

[HannesK]

hmm, as for the routes on the VeeamPN machines, that looks interesting. I will try to reproduce it, but that can take some time.

[HannesK]

Hello,
sorry for the delay. I had some issues with my lab.

When I look at your routing table at the gateway machine, then I assume that you did not add 172.16.215.0/24 as Hub Site.

from my central hub:


At least that's what I always forget



Best regards,
Hannes