Port 80 already in use error

[Cody7172]

Hello! When testing the latest version, I see a message that constantly says that port 80 for the redirect is already busy. But it’s definitely not busy, because the address on which port 80 is trying to listen for the redirect is the internal address of the dynamic Wireguard interface, the gateway itself. And despite this, http redirection still works

wag | 2023/11/08 08:52:14 Started listening: wag | Tunnel Listener: 10.100.1.1:443 wag | Public Listener: 0.0.0.0:4567 wag | 2023/11/08 08:52:14 HTTP redirect to TLS webserver tunnel listener failed: listen tcp 10.100.1.1:80: bind: address already in use

[NHAS]

Hmmm, cant really see how this could be happening with the redirection handler still working with that error message. Unless you have something listening on *:80 which would interfere with it

[NHAS]

As I cant replicate this on my end and dont have any more information Im going to have to close this bug sorry! If you have any more information on it, or find a way to replicate just reopen it :)

[Weisteck]

Hi, I have the same problem, I test wag on Linux machine-name 5.15.0-105-generic #115-Ubuntu SMP Mon Apr 15 09:52:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux with the wag version : v7.3.2-2-g8f38706.

My config.json is :

{
    "Socket": "/tmp/wag.sock",
    "Proxied": false,
    "ExposePorts": [
        "443/tcp",
        "100-200/udp"
    ],
    "NAT": true,
    "HelpMail": "test@mail.fr",
    "Lockout": 5,
    "ExternalAddress": "myexternaladdress.test",
    "MaxSessionLifetimeMinutes": 1440,
    "SessionInactivityTimeoutMinutes": 60,
    "DownloadConfigFileName": "wg0.conf",
    "ManagementUI": {
        "ListenAddress": "192.68.1.1:5184",
        "Enabled": true,
        "CertPath": "/etc/letsencrypt/live/mycert/fullchain.pem",
        "KeyPath": "/etc/letsencrypt/live/mycert/privkey.pem"
    },
    "Webserver": {
        "Public": {
            "ListenAddress": "192.68.1.1:8080",
            "CertPath": "/etc/letsencrypt/live/mycert/fullchain.pem",
            "KeyPath": "/etc/letsencrypt/live/mycert/privkey.pem"
        },
        "Tunnel": {
            "Port": "4433",
            "CertPath": "/etc/letsencrypt/live/mycert/fullchain.pem",
            "KeyPath": "/etc/letsencrypt/live/mycert/privkey.pem"
        }
    },
    "Authenticators": {
        "DefaultMethod": "oidc",
        "Issuer": "WAG",
        "Methods": [
            "oidc"
        ],
        "DomainURL": "https://192.68.1.1:4433",
        "OIDC": {
            "IssuerURL": "https://mytest.test/auth/realms/",
            "ClientSecret": "clientsecret",
            "ClientID": "clientid"
        },
        "PAM": {
            "ServiceName": ""
        }
    },
    "Wireguard": {
        "DevName": "wg0",
        "ListenPort": 51820,
        "PrivateKey": "<privatekey>",
        "Address": "192.68.1.1/24",
        "MTU": 1420
    },
    "DatabaseLocation": "devices.db",
    "Acls": {
        "Policies": {
            "*": {
                "Mfa": [
                    "10.10.10.0/24"
                ]
            }
        }
    }
}

Looking a bit I saw that the iptables rule for port 80 doesn't get deleted after stopping wag. This may be related.

[NHAS]

Hi @Weisteck,

I am no longer maintaining the 7.3.2 version of wag. Primarily because Im getting ready to fully release version 8 which uses etcd.

Good catch on the iptables rule not being deleted, I've added that to the most recent commit on unstable.

As for why its emitting that error, you can safely ignore it as long as you're not trying to have an automatic redirect from port 80 -> your tls port.

[Weisteck]

Hi @NHAS, thanks for your reply, I don't see any milestones on your github, do you have a vision for what's next? :cat:

[NHAS]

Currently whats happening is Im test running all the changes I've made with moving over to etcd so that wag can do clustering with very little effort.

Then after that it'll be moving away from eBPF to pure go, and in-between that probably and doing some things with websockets to make session persistence a bit better.

In the far future (because I hate web dev) probably a better admin UI

[ymazzer]

Hi @NHAS,

Thanks for the clarification. Will etcd be mandatory?

Currently whats happening is Im test running all the changes I've made with moving over to etcd so that wag can do clustering with very little effort.

Then after that it'll be moving away from eBPF to pure go, and in-between that probably and doing some things with websockets to make session persistence a bit better.

In the far future (because I hate web dev) probably a better admin UI

[NHAS]

Yes, it will be the only way to store data.

However just like sqlite it will be built into wag and managed by wag.

[NHAS]

I am still yet to run in to this myself. As I cant replicate it Im going to have to close it again unless someone can give me some 100% replication steps