https://bugs.koozali.org/show_bug.cgi?id=12496

            Bug ID: 12496
           Summary: Bind address 0.0.0.0 causes SIP authorization failures
    Classification: Contribs
           Product: SME Contribs
           Version: 10.0
          Hardware: ---
                OS: ---
            Status: CONFIRMED
          Severity: normal
          Priority: P3
         Component: smeserver-freepbx
          Assignee: te...@pialasse.com
          Reporter: jcr...@safeandsoundit.co.uk
        QA Contact: contribteam@lists.contribs.org
                CC: jcr...@safeandsoundit.co.uk
  Target Milestone: ---

I was attempting to run a Grandstream SIP phone over OpenVPN routed. All my
phones can only connect to the SIP server over VPNs. There is no 'public'
access.

The OpenVPN client was a Mikrotik Hex S (RB760iGS).

This was sitting behind a ISP router which was CGNat'd so had no public IP
address of its own.

The VPN used certificates and it came up without issues.

I had to add a route in the open vpn file and a ccd file for the particular
device so SME/OpenVPN knew where to route.

I could ssh to the VOIP /OpneVPN server and then ssh to the Mikrotik AND ssh to
the ISP phone behind the Mikrtotik

I could also ssh port forward with ssh -=L via the SME server.

Dwspite all this I the SIP phone was unable to register.

I could see the SIP packets on the Asterisk server with tcpdump, but they
received SIP/2.0 401 Unauthorized

Sample transaction:

16:38:58.725587 IP (tos 0x68, ttl 63, id 0, offset 0, flags [DF], proto UDP
(17), length 708)
    192.168.29.2.34399 > 192.168.98.1.5060: SIP, length: 680
        REGISTER sip:192.168.98.1 SIP/2.0
        Via: SIP/2.0/UDP 192.168.88.254:34399;branch=z9hG4bK789144097;rport
        Route: <sip:192.168.98.1:5060;lr>
        From: <sip:8105@192.168.98.1>;tag=1563189881
        To: <sip:8105@192.168.98.1>
        Call-ID: 886844672-2647...@bjc.bgi.ii.cfe
        CSeq: 2049 REGISTER
        Contact:
<sip:8105@192.168.88.254:34399>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-C074AD6CBFEA>"
        X-Grandstream-PBX: true
        Max-Forwards: 70
        User-Agent: Grandstream GXP2170 1.0.11.79
        Supported: path
        Expires: 3600
        X-switch-info: mac=78:9a:18:e2:9d:ce,port=bridge/ether2
        Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO,
REFER, UPDATE, MESSAGE
        Content-Length: 0

16:38:58.725740 IP (tos 0x60, ttl 64, id 40643, offset 0, flags [none], proto
UDP (17), length 555)
    192.168.29.1.5060 > 192.168.29.2.34399: SIP, length: 527
        SIP/2.0 401 Unauthorized
        Via: SIP/2.0/UDP
192.168.88.254:34399;branch=z9hG4bK789144097;received=192.168.29.2;rport=34399
        From: <sip:8105@192.168.98.1>;tag=1563189881
        To: <sip:8105@192.168.98.1>;tag=as5c69cc5b
        Call-ID: 886844672-2647...@bjc.bgi.ii.cfe
        CSeq: 2049 REGISTER
        Server: FPBX-15.0.37.4(16.30.1)
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE
        Supported: replaces, timer
        WWW-Authenticate: Digest algorithm=MD5, realm="asterisk",
nonce="4a045f86"
        Content-Length: 0

It looks like the Unauthorized packet was sending to To:
<sip:8105@192.168.98.1> but it should have gone to To:
<sip:8105@192.168.88.254>

After a lot of reading I stumbled across this article whicxh described my
issue:

https://serverfault.com/questions/392979/asterisk-sip-2-0-401-unauthorized

"Despite Asterisk offering the ability to deal with more than one address by
specifying 0.0.0.0 as your listen address, the box on which Asterisk was
present was sending invites from other aliased IPs on the server instead of the
one intended. Binding Asterisk to one IP, and connecting to that one IP,
resolves this issue entirely."

I set the bindaddr to 192.168.98.1 which is the server (dummy) internal address
and the adderss that all clients connect to, and the phone instantly
authorized.

I then had one follow up issue.

I have two trunks. One is my main trunk and was already running chan_pjsip. The
other is a backup and was using chan_sip.

It appeared that after setting the bind address the backup trunk on chan_sip
failed to register. I swapped that to chan_pjsip and it registered.

I have done some basic tests trying the SIP phones on chan_pjsip but they do
not seem happy with that, possibly due to the change of the bind address but I
can't confirm definitively right now.

(We should consider the fact that chan_sip is deprecated)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
_______________________________________________
Mail for each SME Contribs bug report
To unsubscribe, e-mail contribteam-unsubscr...@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/contribteam/

Reply via email to