WSS via Nginx/443 shows 127.0.0.1 and bypasses Fail2Ban

VitalPBX
1

Dear Team,

I would like to report an issue/concern regarding SIP WebSocket (WSS) registrations through the Nginx reverse proxy.

I have observed the following behavior on VitalPBX system:

1. Direct WSS connection on port 8089

When an extension registers using:

wss://mydomain.com:8089/ws

the registration/contact information shows the actual public IP address of the client device.

If incorrect SIP credentials are repeatedly submitted from this client, Fail2Ban is able to identify and block the client’s public IP as expected.

2. WSS connection through Nginx on port 443

When the same extension registers using:

wss://mydomain.com/ws

which is reverse-proxied by Nginx to Asterisk on 127.0.0.1:8088, the registration/contact information shows:

127.0.0.1

instead of the actual public IP address of the client.

More importantly, I tested this with intentionally incorrect SIP credentials. When multiple unauthorized registration attempts are made through the /ws endpoint on port 443, the client’s public IP is not blocked by Fail2Ban.

It appears that, because the WebSocket connection is reverse-proxied through Nginx, Asterisk/PJSIP is seeing the connection as originating from 127.0.0.1. Since 127.0.0.1 is trusted/whitelisted by Fail2Ban, the original public IP cannot be blocked by the existing Fail2Ban protection.

For reference, my Nginx /ws configuration is:

location /ws {
    proxy_pass http://127.0.0.1:8088/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Could you please confirm:

  1. Is this expected behavior for the VitalPBX WSS reverse-proxy implementation?

  2. Is there a supported configuration that allows Asterisk/PJSIP and its security/Fail2Ban mechanism to retain the original client’s public IP when registering through /ws on port 443?

  3. If the original IP cannot be passed to PJSIP through the reverse proxy, how does VitalPBX recommend protecting the /ws endpoint against SIP registration brute-force attacks?

  4. Is this behavior addressed in the newer releases, particularly the changes related to custom HTTPS ports and reverse-proxied SIP WebSocket connections?

I would appreciate your guidance, as this is a security concern for any VitalPBX installation using the reverse-proxied WSS endpoint.

Regards,
Hemant

1 Like