github-starred/olm
2
0
Fork 0
mirror of https://github.com/fosrl/olm.git synced 2026-03-08 23:03:12 -05:00
Code Issues 9 Packages Projects Releases 7 Wiki Activity

Olm doesn't create an interface on Linux. #5

New Issue
Open
opened 2025-11-19 07:03:55 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-19 07:03:55 -06:00
Owner
Copy Link

Originally created by @victornavorskie on GitHub (Aug 12, 2025).

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.

Image
Originally created by @victornavorskie on GitHub (Aug 12, 2025). 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. <img width="977" height="160" alt="Image" src="https://github.com/user-attachments/assets/041d078d-db05-47f5-9533-d918fd4ac441" />
GiteaMirror commented 2025-11-19 07:03:56 -06:00
Author
Owner
Copy Link

@victornavorskie commented on GitHub (Aug 13, 2025):

● 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!
@victornavorskie commented on GitHub (Aug 13, 2025): ``` ● 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! ```
GiteaMirror commented 2025-11-19 07:03:56 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Aug 13, 2025):

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?

https://github.com/fosrl/newt/issues/101

@oschwartz10612 commented on GitHub (Aug 13, 2025): 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? https://github.com/fosrl/newt/issues/101
GiteaMirror commented 2025-11-19 07:03:57 -06:00
Author
Owner
Copy Link

@victornavorskie commented on GitHub (Aug 14, 2025):

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

@victornavorskie commented on GitHub (Aug 14, 2025): i give it a try with v1.4.1 and olm v1.1.0 noting change i cant find the Olm interface on client
GiteaMirror commented 2025-11-19 07:03:57 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Aug 14, 2025):

Could you post your newt logs?

@oschwartz10612 commented on GitHub (Aug 14, 2025): Could you post your newt logs?
GiteaMirror commented 2025-11-19 07:03:58 -06:00
Author
Owner
Copy Link

@victornavorskie commented on GitHub (Aug 14, 2025):

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
@victornavorskie commented on GitHub (Aug 14, 2025): ``` 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 ```
GiteaMirror commented 2025-11-19 07:03:58 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Aug 16, 2025):

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!

@oschwartz10612 commented on GitHub (Aug 16, 2025): 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!
GiteaMirror commented 2025-11-19 07:03:58 -06:00
Author
Owner
Copy Link

@victornavorskie commented on GitHub (Aug 18, 2025):

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

Image and those ports in VPS are opend Image and again here is the logs Image Image 
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
Image Image And when I try to ping it with my 192.168.0.x address, I get a timeout.
@victornavorskie commented on GitHub (Aug 18, 2025): Thanks for the reply. I have already configured the site and created two resources from it. <img width="1529" height="237" alt="Image" src="https://github.com/user-attachments/assets/b45c4f63-8be1-4540-89f5-92e2c3c81749" /> and those ports in VPS are opend <img width="1005" height="89" alt="Image" src="https://github.com/user-attachments/assets/2d3a2762-958a-4bae-9d57-686c7eb9dfa8" /> and again here is the logs <img width="1226" height="777" alt="Image" src="https://github.com/user-attachments/assets/ebe7b33b-ba39-49e6-9fc8-d8befaf88041" /> <img width="1421" height="1182" alt="Image" src="https://github.com/user-attachments/assets/0bb485e9-aedb-4ec1-8d9c-3c1ca6992730" /> ``` 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 ``` <img width="1513" height="58" alt="Image" src="https://github.com/user-attachments/assets/7a8823ea-be7a-4e0c-a5e2-5e12d8409f66" /> <img width="1375" height="492" alt="Image" src="https://github.com/user-attachments/assets/c8e8b523-3e20-4e88-a965-b2aa15c1fc2c" /> And when I try to ping it with my 192.168.0.x address, I get a timeout.
GiteaMirror commented 2025-11-19 07:03:58 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Aug 23, 2025):

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: 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.

@oschwartz10612 commented on GitHub (Aug 23, 2025): 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.
GiteaMirror commented 2025-11-19 07:03:59 -06:00
Author
Owner
Copy Link

@HearthCore commented on GitHub (Oct 9, 2025):

Subnet routing is defined differently in most other applications, and the documentation is indeed confusing.

Basically, you take a site and add proxies resources to it- then you connect to that sites port.

So when you want SSH, you'd add a resource on the local newt client and define the ports, then it's accessible via newts/pangolin IPv4:port

So 192.168.2.2:22 (ssh server) at 100.64.0.2:2222 (newt-site pangolin ipv4)

@HearthCore commented on GitHub (Oct 9, 2025): Subnet routing is defined differently in most other applications, and the documentation is indeed confusing. Basically, you take a site and add proxies resources to it- then you connect to that sites port. So when you want SSH, you'd add a resource on the local newt client and define the ports, then it's accessible via newts/pangolin IPv4:port So 192.168.2.2:22 (ssh server) at 100.64.0.2:2222 (newt-site pangolin ipv4)
GiteaMirror commented 2025-11-19 07:03:59 -06:00
Author
Owner
Copy Link

@HearthCore commented on GitHub (Oct 9, 2025):

To be clear, I would love functioning site routing instead of this type of proxy- as an option at least.

But I do admire the feature set, it's weird to basically have this before general subnet routing, but I'll is indeed in its training wheels, right?

@HearthCore commented on GitHub (Oct 9, 2025): To be clear, I would love functioning site routing instead of this type of proxy- as an option at least. But I do admire the feature set, it's weird to basically have this before general subnet routing, but I'll is indeed in its training wheels, right?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/olm#5
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?