Need help for configure server link - or "this worked before!"

Pritunl
1

Hello :slight_smile:
Unable to use server link anymore.

Debian 11
pritunl v1.32.3732.84
Enterprise subscription

We have the following setup.
1 server in the office 1 server in the data centre Both servers have been connected to each other via a link for many months. A route has been created on the office server (10.100.0.0/22) to access the private network (10.10.1.0/24) in the data centre. However, this has recently stopped working.
The route is forwarded to the clients as expected:

➜ ~ ip route show (client)
10.10.1.0/24 dev wg0 scope link

However, the traffic is not routed via the server link but via the router of the VPN server

➜ ~ traceroute 10.10.1.19 (client)
traceroute to 10.10.1.19 (10.10.1.19), 30 hops max, 60 byte packets
1 10.100.58.1 (10.100.58.1) 8.224 ms 8.346 ms 8.322 ms
2 10.100.0.1 (10.100.0.1) 8.504 ms 8.476 ms 8.670 ms
3 * * *

The route is not displayed on the server itself, but this will not be one of the routes created in the pritunl gui:

image
image1248×942 48.8 KB

➜ ~ ip route show (office server)
default via 10.100.0.1 dev ens18 onlink
10.100.0.0/22 dev ens18 proto kernel scope link src 10.100.1.70
10.100.56.0/24 dev tun8 proto kernel scope link src 10.100.56.1
10.100.58.0/24 dev wg8 proto kernel scope link src 10.100.58.1
192.168.231.0/24 via 10.100.56.1 dev tun8
192.168.232.0/24 via 10.100.56.1 dev tun8

What have I overlooked or which configuration is wrong and why did it work before and not anymore?

2

Check the link output next to the server output for error messages.

3

I can see a message auth failed when I restart the DC server

[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:49 OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:49 library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.10
[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:49 TCP/UDP: Preserving recently used remote address: [AF_INET]89.244.102.82:16298
[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:49 UDP link local: (not bound)
[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:49 UDP link remote: [AF_INET]<office-IP>:16298
[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:49 [60ddc289a17a553210e8cc3e] Peer Connection Initiated with [AF_INET]<office-IP>:16298
[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:50 AUTH: Received control message: AUTH_FAILED
[zzDatacenter<->Zebra-VPN] 2024-02-06 13:44:50 SIGTERM[soft,auth-failure] received, process exiting
4

Get the authentication error from the top right logs.

6

found it :slight_smile:

[vpn-dc][2024-02-07 08:22:13,764][INFO] Starting vpn server
  server_id        = "61ad221b569f00f7eab5b1f4"
  instance_id      = "65c32fa50818249e14fad1db"
  instances        = []
  instances_count  = 0
  route_count      = 0
  network          = "192.168.231.0/24"
  network6         = "fd00:c0a8:e700::/64"
  dynamic_firewall = false
  route_dns        = false
  device_auth      = false
  host_id          = "<id>"
  host_address     = "<someip>"
  host_address6    = "fe80::be24:11ff:fe5c:2f8"
  host_networks    = ["<someip>", "10.10.1.0/24"]
  cur_timestamp    = "2024-02-07 07:22:13.764422"
  libipt           = false
[vpn-dc][2024-02-07 08:22:13,765][WARNING] Stopping duplicate instance, check date time sync
  server_id   = "id"
  instance_id = "id"
[Berlin][2024-02-07 08:22:21,577][INFO] Authenticating user
  user_name = "host_id"
  factors   = []
[Berlin][2024-02-07 08:22:21,824][ERROR] Error in authorizer callback
Traceback (most recent call last):
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/clients/clients.py", line 1345, in callback
    self.allow_client(client_data, org, user,
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/clients/clients.py", line 998, in allow_client
    client_conf, network_links = self.generate_client_conf(
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/clients/clients.py", line 157, in generate_client_conf
    for route in link_usr_svr.get_routes(include_default=False):
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/server/server.py", line 667, in get_routes
    if self.route_dns and include_dns_routes:
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/mongo/object.py", line 47, in __getattr__
    raise ValueError('Cannot get unloaded field %r' % name)
ValueError: Cannot get unloaded field 'route_dns'
  server_id   = "60b4cf2701e9b419b00a7458"
  instance_id = "65c27bf299d8d64ca2ec6312"
7

This is fixed in v1.32.3801.41 currently in the unstable repository.

8

Thanks for the fast fix but unfortunately this did not worked so well :slight_smile:

I did the update on the Datacenter host and now pritunl does not start anymore. I don’t see any entries in pritunl.log but in the web ui log

[Berlin][2024-02-09 10:58:50,517][ERROR] Exception on /server/61ad221b569f00f7eab5b1f4/operation/start [PUT]
Traceback (most recent call last):
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 2190, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 1486, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 1484, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 1469, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/auth/app.py", line 10, in _wrapped
    return call(*args, **kwargs)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/handlers/server.py", line 1362, in server_operation_put
    svr.start()
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/server/server.py", line 1689, in start
    raise ServerStartError('Server start timed out', {
pritunl.exceptions.ServerStartError: Server start timed out. {'server_id': ObjectId('61ad221b569f00f7eab5b1f4')}
[Berlin][2024-02-09 10:58:50,517][ERROR] Exception on /server/61ad221b569f00f7eab5b1f4/operation/start [PUT]
Traceback (most recent call last):
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 2190, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 1486, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 1484, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/flask/app.py", line 1469, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/auth/app.py", line 10, in _wrapped
    return call(*args, **kwargs)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/handlers/server.py", line 1362, in server_operation_put
    svr.start()
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/server/server.py", line 1689, in start
    raise ServerStartError('Server start timed out', {
pritunl.exceptions.ServerStartError: Server start timed out. {'server_id': ObjectId('61ad221b569f00f7eab5b1f4')}
9

That error occurs when none of the hosts attach to a server respond to a start event. Verify the correct hosts are attached. If it’s a MongoDB 7 database this is a known issue. Running sudo pritunl clear-message-cache then restarting the hosts will correct the issue. To prevent it from occurring again the database will need to be downgraded to MongoDB 6.

10

Hey,

the servers seem to be attached, at least the web ui tells me so. I did run the command you provided and restarted both linked hosts but pritunl does not start with the same error in the UI or no error in pritul.log or pritunl_journal.log.
As the database we use Mongodb cloud in version 6.0.13

So what I did:

  • Update via apt
  • run pritunl clear-message-cache
  • reboot hosts