Olm doesn't create an interface on Linux.

[victornavorskie]

I tried OLM on both a VPS and a laptop running Ubuntu and ArchLinux. It appears that no interface is created, and there are no errors in the logs.
Pangolin shows 0 traffic and there are no errors.

[victornavorskie]

● olm.service - Olm
     Loaded: loaded (/etc/systemd/system/olm.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2025-08-13 11:27:04 UTC; 5min ago
   Main PID: 2499670 (olm)
      Tasks: 7 (limit: 980)
     Memory: 6.1M
        CPU: 696ms
     CGroup: /system.slice/olm.service
             └─2499670 /usr/local/bin/olm --id xxxx--secret xxx-x--xx---x --endpoint https://pangolin.xx.de>
--interface olm --log-level TRACE

Aug 13 11:27:04 ubuntu systemd[1]: Started Olm.
Aug 13 11:27:04 ubuntu olm[2499670]: INFO: 2025/08/13 11:27:04 Websocket Connected
Aug 13 11:27:05 ubuntu olm[2499670]: INFO: 2025/08/13 11:27:05 Sent registration message
Aug 13 11:27:05 ubuntu olm[2499670]: INFO: 2025/08/13 11:27:05 Sent initial ping message

from newt with ACCEPT_CLIENTS=true

INFO: 2025/08/13 11:39:12 Newt version 1.4.0
INFO: 2025/08/13 11:39:12 Websocket connected
INFO: 2025/08/13 11:39:12 Requesting exit nodes from server
INFO: 2025/08/13 11:39:12 Received ping message
INFO: 2025/08/13 11:39:13 Received registration message
INFO: 2025/08/13 11:39:13 Connecting to endpoint: pangolin.xxx.de
INFO: 2025/08/13 11:39:13 Initial connection test successful!
INFO: 2025/08/13 11:39:13 Tunnel connection to server established successfully!

[oschwartz10612]

There is a current issue where the ACCEPT_CLIENTS env var is not working. Fixing in the next release shortly. For now the --accept-clients should work. Could you give that a try?

fosrl/newt#101

[victornavorskie]

i give it a try with v1.4.1 and olm v1.1.0 noting change i cant find the Olm interface on client

[oschwartz10612]

Could you post your newt logs?

[victornavorskie]

INFO: 2025/08/14 08:24:01 Newt version 1.4.1
INFO: 2025/08/14 08:24:02 Setting up clients with netstack...
INFO: 2025/08/14 08:24:02 Websocket connected
INFO: 2025/08/14 08:24:02 Requesting exit nodes from server
INFO: 2025/08/14 08:24:02 Requesting WireGuard configuration from remote server
INFO: 2025/08/14 08:24:02 Received ping message
INFO: 2025/08/14 08:24:02 Received registration message
INFO: 2025/08/14 08:24:02 Connecting to endpoint: pangolin.ralreem.de
INFO: 2025/08/14 08:24:02 Starting UDP hole punch routine to 194.164.206.84:21820
INFO: 2025/08/14 08:24:02 Initial connection test successful!
INFO: 2025/08/14 08:24:02 Tunnel connection to server established successfully!
INFO: 2025/08/14 08:24:02 Started tcp proxy to beszel:8090
INFO: 2025/08/14 08:24:02 Started tcp proxy to jellyfin:8096
INFO: 2025/08/14 08:24:02 Started tcp proxy to gitea-app:3000
INFO: 2025/08/14 08:24:02 Started udp proxy to 127.0.0.1:56826
INFO: 2025/08/14 08:24:04 Received WireGuard clients configuration from remote server
INFO: 2025/08/14 08:24:04 Stopping UDP holepunch
INFO: 2025/08/14 08:24:04 WireGuard netstack device created and configured
INFO: 2025/08/14 08:24:04 [WGTester] Server started on 0.0.0.0:56827
INFO: 2025/08/14 08:24:04 Peer 9Dne+vObedMHR2DzNlkeGfmZdSAm+R4SS2XuZ7yc= added successfully
INFO: 2025/08/14 08:24:04 No targets updated, no netstack replacement needed
INFO: 2025/08/14 08:24:04 Started tcp proxy to beszel:8090
INFO: 2025/08/14 08:24:56 Peer 9Dne+vObedMHR2DzNlkeGfmZdSAm+R4SS2XuZ7yc== removed successfully
INFO: 2025/08/14 08:24:56 Peer jJnjIhnZMX+GWaiaZ788DJfdf7KUYCrhdLdJHzON+KR4= added successfully

[oschwartz10612]

Okay looks like its listening for clients thats good! If Olm is getting stuck on `Sent initial ping message` then that usually means that it is not getting sent config from the server. Could you check two things for me: 1. You have the site configured on the client. Click on the client -> make sure the site shows up in the list 2. Make sure UDP port 21820 is open and exposed on the VPS 3. Connect and show the pangolin logs. We should see some output complaining if it is trying ti send a site down and failing for some reason Let me know what you find!

[victornavorskie]

Thanks for the reply.
I have already configured the site and created two resources from it.

and those ports in VPS are opend and again here is the logs

services:
  pangolin:
    image: fosrl/pangolin:latest # https://github.com/fosrl/pangolin/releases
    container_name: pangolin
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./config:/app/config
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001/api/v1/"]
      interval: "3s"
      timeout: "3s"
      retries: 15

  gerbil:
    image: fosrl/gerbil:latest # https://github.com/fosrl/gerbil/releases
    container_name: gerbil
    restart: unless-stopped
    depends_on:
      pangolin:
        condition: service_healthy
    command:
      - --reachableAt=http://gerbil:3003
      - --generateAndSaveKeyTo=/var/config/key
      - --remoteConfig=http://pangolin:3001/api/v1/gerbil/get-config
      - --reportBandwidthTo=http://pangolin:3001/api/v1/gerbil/receive-bandwidth
    volumes:
      - ./config/:/var/config
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    ports:
      - 21820:21820/udp
      - 51820:51820/udp
      - 443:443 # Port for traefik because of the network_mode
      - 80:80 # Port for traefik because of the network_mode

And when I try to ping it with my 192.168.0.x address, I get a timeout.

[oschwartz10612]

Ahh okay it does look like olm is connected now at the bottom of the logs! This is good! It think it could just be because you actually cant ping that 192 address through the tunnel when configured this way. You should be able to ping the 100.90.128.0 address (the address of the side) because this is IP assigned to the interface on both sides of the tunnels. We probably need some better documentation around this... Basically the raw resources you create with a source port are accessible on 100.90.128.0:<source ip> and will be sent to the destination target you define. Does that make sense? This is because its getting proxied out of the internal site IP to the destination on your network.