HTTP error! status: undefined #22

@TyDooo commented on GitHub (May 30, 2025):

The exitNodes table is located within an SQLite database file. It is located in the db/ directory next to your pangolin configuration file.

Something like this should work to read from the database:

sqlite3 /var/lib/fossorial/config/db/db.sqlite "SELECT * FROM exitNodes"

In the output, the last column should match the value in the --reachableAt argument. If it matches, then you should be all good. Otherwise you need to change the value in the column to match the argument.

This may have been an issue specific to my setup though. So if it all works on your end then you don't need to worry about this :p

@TyDooo commented on GitHub (May 30, 2025): The `exitNodes` table is located within an SQLite database file. It is located in the `db/` directory next to your pangolin configuration file. Something like this should work to read from the database: ```bash sqlite3 /var/lib/fossorial/config/db/db.sqlite "SELECT * FROM exitNodes" ``` In the output, the last column should match the value in the `--reachableAt` argument. If it matches, then you should be all good. Otherwise you need to change the value in the column to match the argument. This may have been an issue specific to my setup though. So if it all works on your end then you don't need to worry about this :p

GiteaMirror commented

@oschwartz10612 commented on GitHub (May 31, 2025):

^^^^ this is likely the issue. When the gerbil registers this value gets set. If you are not using docker make sure that the Pangolin api can reach the Gerbil API over this URL.

@oschwartz10612 commented on GitHub (May 31, 2025): ^^^^ this is likely the issue. When the gerbil registers this value gets set. If you are not using docker make sure that the Pangolin api can reach the Gerbil API over this URL.

GiteaMirror commented

@jackrosenberg commented on GitHub (May 31, 2025):

This helps a lot, i'm onto the next issue!! It looks like newt's wg connection isn't being created properly. running root@edge_server# ip a | grep wg on the yields nothing
root@edge_server# ~/./newt --id ... --secret <...> --endpoint https:/<dashboardurl>

INFO: 2025/05/31 17:13:21 Sent registration message
INFO: 2025/05/31 17:13:21 Received registration message
INFO: 2025/05/31 17:13:21 Received: {Type:newt/wg/connect Data:map[endpoint:<dashboardurl>:51820 publicKey:... serverIP:100.89.128.1 targets:map[tcp:[] udp:[]] tunnelIP:100.89.128.4]}
INFO: 2025/05/31 17:13:21 WireGuard device created. Lets ping the server now...
INFO: 2025/05/31 17:13:21 Ping attempt 1
INFO: 2025/05/31 17:13:21 Pinging 100.89.128.1
WARN: 2025/05/31 17:13:31 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/05/31 17:13:31 Starting ping check
INFO: 2025/05/31 17:13:31 Ping attempt 2

gerbil conf:

    gerbil = {
     start_port = 51820;
     base_endpoint = <dashboardurl>;
     block_size = 24;
     site_block_size = 30;
     subnet_group = "100.89.128.1/24";
     use_subdomain = true;
    };

@jackrosenberg commented on GitHub (May 31, 2025): This helps a lot, i'm onto the next issue!! It looks like newt's wg connection isn't being created properly. running `root@edge_server# ip a | grep wg` on the yields nothing `root@edge_server# ~/./newt --id ... --secret <...> --endpoint https:/<dashboardurl>` ``` INFO: 2025/05/31 17:13:21 Sent registration message INFO: 2025/05/31 17:13:21 Received registration message INFO: 2025/05/31 17:13:21 Received: {Type:newt/wg/connect Data:map[endpoint:<dashboardurl>:51820 publicKey:... serverIP:100.89.128.1 targets:map[tcp:[] udp:[]] tunnelIP:100.89.128.4]} INFO: 2025/05/31 17:13:21 WireGuard device created. Lets ping the server now... INFO: 2025/05/31 17:13:21 Ping attempt 1 INFO: 2025/05/31 17:13:21 Pinging 100.89.128.1 WARN: 2025/05/31 17:13:31 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout INFO: 2025/05/31 17:13:31 Starting ping check INFO: 2025/05/31 17:13:31 Ping attempt 2 ``` `gerbil conf:` ``` gerbil = { start_port = 51820; base_endpoint = <dashboardurl>; block_size = 24; site_block_size = 30; subnet_group = "100.89.128.1/24"; use_subdomain = true; }; ```

GiteaMirror commented

2025-11-19 07:12:08 -06:00

@TyDooo commented on GitHub (May 31, 2025):

I don't think Newt creates a new network interface; only Gerbil should do that. Could you try restarting your VPS? I initially had the same issue where Newt was unable to ping the server. Rebooting the VPS and the Newt instance fixed it.

@TyDooo commented on GitHub (May 31, 2025): I don't think Newt creates a new network interface; only Gerbil should do that. Could you try restarting your VPS? I initially had the same issue where Newt was unable to ping the server. Rebooting the VPS and the Newt instance fixed it.

GiteaMirror commented

@jackrosenberg commented on GitHub (Jun 4, 2025):

Okay rebooting fixes almost everything! I still can't get the services to connect

root@edge_server# ./newt --id {if} --secret {secret} --endpoint https://{dashboardUrl}

INFO: 2025/06/04 19:52:56 Sent registration message
INFO: 2025/06/04 19:52:56 Received registration message
INFO: 2025/06/04 19:52:56 Received: {Type:newt/wg/connect Data:map[endpoint:{dashboardUrl}:51820 publicKey:{...} serverIP:100.89.128.1 targets:map[tcp:[62968:localhost:8096 57669:localhost:3002] udp:[]] tunnelIP:100.89.128.4]}
INFO: 2025/06/04 19:52:56 WireGuard device created. Lets ping the server now...
...
INFO: 2025/06/04 19:52:56 Started tcp proxy from 100.89.128.4:62968 to localhost:8096
INFO: 2025/06/04 19:52:56 Started tcp proxy from 100.89.128.4:57669 to localhost:3002
...
INFO: 2025/06/04 19:58:27 Received: {Type:newt/tcp/add Data:map[targets:[55601:localhost:2283]]}
INFO: 2025/06/04 19:58:27 Started tcp proxy from 100.89.128.4:55601 to localhost:2283

then i create a resource that points from p.{baseDomain} to localhost:2283
and when accessing p.{baseDomain}:
Internal Server Error

curl-ing from the vps proves the tunnel is working though!
root@vps # curl 100.89.128.4:55601

<!doctype html>
<html>
  <head>
    <!-- (used for SSR) -->
    <!-- metadata:tags -->

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" />
    <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />
    ...

there are no errors in the logs of pangolin, gerbil or traefik
Whats going on here?

@jackrosenberg commented on GitHub (Jun 4, 2025): Okay rebooting fixes almost everything! I still can't get the services to connect `root@edge_server# ./newt --id {if} --secret {secret} --endpoint https://{dashboardUrl}` ``` INFO: 2025/06/04 19:52:56 Sent registration message INFO: 2025/06/04 19:52:56 Received registration message INFO: 2025/06/04 19:52:56 Received: {Type:newt/wg/connect Data:map[endpoint:{dashboardUrl}:51820 publicKey:{...} serverIP:100.89.128.1 targets:map[tcp:[62968:localhost:8096 57669:localhost:3002] udp:[]] tunnelIP:100.89.128.4]} INFO: 2025/06/04 19:52:56 WireGuard device created. Lets ping the server now... ... INFO: 2025/06/04 19:52:56 Started tcp proxy from 100.89.128.4:62968 to localhost:8096 INFO: 2025/06/04 19:52:56 Started tcp proxy from 100.89.128.4:57669 to localhost:3002 ... INFO: 2025/06/04 19:58:27 Received: {Type:newt/tcp/add Data:map[targets:[55601:localhost:2283]]} INFO: 2025/06/04 19:58:27 Started tcp proxy from 100.89.128.4:55601 to localhost:2283 ``` then i create a resource that points from p.{baseDomain} to localhost:2283 and when accessing p.{baseDomain}: Internal Server Error curl-ing from the vps proves the tunnel is working though! `root@vps # curl 100.89.128.4:55601` ``` <!doctype html> <html> <head>   <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" /> <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" /> ... ``` there are no errors in the logs of pangolin, gerbil or traefik Whats going on here?

GiteaMirror commented

2025-11-19 07:12:08 -06:00

@TyDooo commented on GitHub (Jun 4, 2025):

It looks as if Traefik isn’t receiving the expected routing rules.
Could you please verify what Pangolin is sending?

curl -s http://localhost:3001/api/v1/traefik-config | jq

@TyDooo commented on GitHub (Jun 4, 2025): It looks as if Traefik isn’t receiving the expected routing rules. Could you please verify what Pangolin is sending? ```bash curl -s http://localhost:3001/api/v1/traefik-config | jq ```

GiteaMirror commented

2025-11-19 07:12:08 -06:00

@jackrosenberg commented on GitHub (Jun 4, 2025):

root@vps# curl -s http://localhost:3001/api/v1/traefik-config | jq

{
  "http": {
    "middlewares": {
      "badger": {
        "plugin": {
          "badger": {
            "apiBaseUrl": "http://pangolin:3001/api/v1",
            "userSessionCookieName": "p_session_token",
            "accessTokenQueryParam": "p_token",
            "resourceSessionRequestParam": "p_session_request"
          }
        }
      },
      "redirect-to-https": {
        "redirectScheme": {
          "scheme": "https"
        }
      }
    },
    "routers": {
      "1-router": {
        "entryPoints": [
          "websecure"
        ],
        "middlewares": [
          "badger"
        ],
        "service": "1-service",
        "rule": "Host(`jfn.{baseUrl}`)",
        "tls": {
          "certResolver": "letsencrypt"
        }
      },
      "1-router-redirect": {
        "entryPoints": [
          "web"
        ],
        "middlewares": [
          "redirect-to-https"
        ],
        "service": "1-service",
        "rule": "Host(`jfn.{baseUrl}`)"
      },
      "2-router": {
        "entryPoints": [
          "websecure"
        ],
        "middlewares": [
          "badger"
        ],
        "service": "2-service",
        "rule": "Host(`p.{baseUrl}`)",
        "tls": {
          "certResolver": "letsencrypt"
        }
      },
      "2-router-redirect": {
        "entryPoints": [
          "web"
        ],
        "middlewares": [
          "redirect-to-https"
        ],
        "service": "2-service",
        "rule": "Host(`p.{baseUrl}`)"
      }
    },
    "services": {
      "1-service": {
        "loadBalancer": {
          "servers": [
            {
              "url": "http://100.89.128.4:62968"
            }
          ]
        }
      },
      "2-service": {
        "loadBalancer": {
          "servers": [
            {
              "url": "http://100.89.128.4:55601"
            }
          ]
        }
      }
    }
  }

"apiBaseUrl": "http://pangolin:3001/api/v1"
should probably be localhost:3001/api/v1, since the pangolin interface doesn't exist

@jackrosenberg commented on GitHub (Jun 4, 2025): `root@vps# curl -s http://localhost:3001/api/v1/traefik-config | jq` ``` { "http": { "middlewares": { "badger": { "plugin": { "badger": { "apiBaseUrl": "http://pangolin:3001/api/v1", "userSessionCookieName": "p_session_token", "accessTokenQueryParam": "p_token", "resourceSessionRequestParam": "p_session_request" } } }, "redirect-to-https": { "redirectScheme": { "scheme": "https" } } }, "routers": { "1-router": { "entryPoints": [ "websecure" ], "middlewares": [ "badger" ], "service": "1-service", "rule": "Host(`jfn.{baseUrl}`)", "tls": { "certResolver": "letsencrypt" } }, "1-router-redirect": { "entryPoints": [ "web" ], "middlewares": [ "redirect-to-https" ], "service": "1-service", "rule": "Host(`jfn.{baseUrl}`)" }, "2-router": { "entryPoints": [ "websecure" ], "middlewares": [ "badger" ], "service": "2-service", "rule": "Host(`p.{baseUrl}`)", "tls": { "certResolver": "letsencrypt" } }, "2-router-redirect": { "entryPoints": [ "web" ], "middlewares": [ "redirect-to-https" ], "service": "2-service", "rule": "Host(`p.{baseUrl}`)" } }, "services": { "1-service": { "loadBalancer": { "servers": [ { "url": "http://100.89.128.4:62968" } ] } }, "2-service": { "loadBalancer": { "servers": [ { "url": "http://100.89.128.4:55601" } ] } } } } ``` `"apiBaseUrl": "http://pangolin:3001/api/v1"` should probably be localhost:3001/api/v1, since the pangolin interface doesn't exist

GiteaMirror commented

@TyDooo commented on GitHub (Jun 4, 2025):

Indeed, make sure the value of internal_hostname in the Pangolin config is set to localhost.

@TyDooo commented on GitHub (Jun 4, 2025): Indeed, make sure the value of `internal_hostname` in the Pangolin config is set to `localhost`.

GiteaMirror commented

@jackrosenberg commented on GitHub (Jun 4, 2025):

Works like a charm! Thanks so much for your help!!!

@jackrosenberg commented on GitHub (Jun 4, 2025): Works like a charm! Thanks so much for your help!!!

GiteaMirror commented

@jackrosenberg commented on GitHub (Jul 6, 2025):

I don't think Newt creates a new network interface; only Gerbil should do that. Could you try restarting your VPS? I initially had the same issue where Newt was unable to ping the server. Rebooting the VPS and the Newt instance fixed it.

Any idea on what this reboot reloads btw? It would be nice to not need to reboot after install. @TyDooo @oschwartz10612

@jackrosenberg commented on GitHub (Jul 6, 2025): > I don't think Newt creates a new network interface; only Gerbil should do that. Could you try restarting your VPS? I initially had the same issue where Newt was unable to ping the server. Rebooting the VPS and the Newt instance fixed it. Any idea on what this reboot reloads btw? It would be nice to not need to reboot after install. @TyDooo @oschwartz10612

GiteaMirror commented

@oschwartz10612 commented on GitHub (Jul 6, 2025):

Hard to say but I think restarting newt just re initiates the connection workflow that sometimes does not recover well when it looses connection to the vps. There are some changes coming to newt that should improve its reconnect and uptime performance!

@oschwartz10612 commented on GitHub (Jul 6, 2025): Hard to say but I think restarting newt just re initiates the connection workflow that sometimes does not recover well when it looses connection to the vps. There are some changes coming to newt that should improve its reconnect and uptime performance!

GiteaMirror commented

@jackrosenberg commented on GitHub (Jul 6, 2025):

Oh I mean the vps. Is there some wireguard thing that can be manually refreshed?

@jackrosenberg commented on GitHub (Jul 6, 2025): Oh I mean the vps. Is there some wireguard thing that can be manually refreshed?

GiteaMirror commented

@oschwartz10612 commented on GitHub (Jul 6, 2025):

Yeah rebooting is kind of nuclear haha. You can just use docker and restart the gerbil container or do docker compose down and then docker compose up -d to restart the stack. This will restart wg.

@oschwartz10612 commented on GitHub (Jul 6, 2025): Yeah rebooting is kind of nuclear haha. You can just use docker and restart the gerbil container or do `docker compose down` and then `docker compose up -d` to restart the stack. This will restart wg.

GiteaMirror commented

@jackrosenberg commented on GitHub (Jul 6, 2025):

Uhhh haha soo I run Pangolin and friends without docker, thru NixOs. I've tried restarting all systemd services with with Network in the name already.

@jackrosenberg commented on GitHub (Jul 6, 2025): Uhhh haha soo I run Pangolin and friends without docker, thru NixOs. I've tried restarting all systemd services with with Network in the name already.

GiteaMirror commented

@jackrosenberg commented on GitHub (Aug 10, 2025):

@oschwartz10612, any idea what service/other thing this could be ?

@jackrosenberg commented on GitHub (Aug 10, 2025): @oschwartz10612, any idea what service/other thing this could be ?

GiteaMirror commented