[jitsi-users] Jitsi configuration difficulty


#1

I know that this will be a configuration issue but I cannot discover
the cause at the moment. Basically we use Asterisk 11 / FreePBX 12
and we have a softphone configured in Asterisk as a device. This
device is configured to use TLS/SRTP only.

We have a remote user on a Macbook (unknown vintage) attempting to
connect via Jitsi. We have, to the best of our ability, duplicated
exactly the configuration that I use on my own Macbook Pro saving only
the device number, and which works for me. However, when this user
attempts to connect we see this in the asterisk logs:

[2015-03-17 11:30:33] ERROR[15413] chan_sip.c: 'UDP' is not a valid
transport for 'user'. we only use 'TLS'! ending call.
[2015-03-17 11:30:33] ERROR[15413] chan_sip.c: 'UDP' is not a valid
transport for 'user'. we only use 'TLS'! ending call.
[2015-03-17 11:30:33] NOTICE[15413] chan_sip.c: Registration from
'"90014" <sip:user@harte-lyne.ca>' failed for 'A.B.C.D:1024' - Device
not configured to use this transport type
[2015-03-17 11:30:33] NOTICE[15413] chan_sip.c: Registration from
'"90014" <sip:user@harte-lyne.ca>' failed for 'A.B.C.D:1024' - Device
not configured to use this transport type

I do not know where we have misconfigured Jitsi but apparently we have.

According to the user for this account the Security tab has Enable
support to encrypt set. It has SDES selected and moved to the top of
Advanced encryption settings. It also has both DTLS and ZRTP
de-selected. It has both AES ciphers enabled. It has RTP/SAVP
Mandatory set.

The default global encodings are overridden and all the video codecs
are deselected.

Still we see the request for UDP show up when they attempt to connect.
Have I overlooked something? What?

If required I have obtained the log files created by the user
immediately following a failed connection attempt.

···

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3


#2

This turns out to actually be an iMac running OS X Yosemite 10.10.?
(probably 10.10.2).

···

On Tue, March 17, 2015 12:02, James B. Byrne wrote:

We have a remote user on a Macbook (unknown vintage) attempting to
connect via Jitsi.

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3


#3

[2015-03-17 11:30:33] ERROR[15413] chan_sip.c: 'UDP' is not a valid
transport for 'user'. we only use 'TLS'! ending call.
[2015-03-17 11:30:33] ERROR[15413] chan_sip.c: 'UDP' is not a valid
transport for 'user'. we only use 'TLS'! ending call.
[2015-03-17 11:30:33] NOTICE[15413] chan_sip.c: Registration from
'"90014" <sip:user@harte-lyne.ca>' failed for 'A.B.C.D:1024' - Device
not configured to use this transport type
[2015-03-17 11:30:33] NOTICE[15413] chan_sip.c: Registration from
'"90014" <sip:user@harte-lyne.ca>' failed for 'A.B.C.D:1024' - Device
not configured to use this transport type

I do not know where we have misconfigured Jitsi but apparently we have.

According to the user for this account the Security tab has Enable
support to encrypt set. It has SDES selected and moved to the top of
Advanced encryption settings. It also has both DTLS and ZRTP
de-selected. It has both AES ciphers enabled. It has RTP/SAVP
Mandatory set.

The default global encodings are overridden and all the video codecs
are deselected.

Still we see the request for UDP show up when they attempt to connect.
Have I overlooked something? What?

How is this user connected to your network? If not through a VPN, then the SRV on your public DNS seems to be missing. Either publish _sips._tcp.harte-lyne.ca or configure the proxy manually (more secure anyway if you don't use DNSSEC).

If required I have obtained the log files created by the user
immediately following a failed connection attempt.

Ingo


#4

I see it from here, unless I mistake what you write:

dig _sips._tcp.harte-lyne.ca SRV

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.2 <<>>
_sips._tcp.harte-lyne.ca SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2611
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; QUESTION SECTION:
;_sips._tcp.harte-lyne.ca. IN SRV

;; ANSWER SECTION:
_sips._tcp.harte-lyne.ca. 300 IN SRV 10 10 5061
voinet09.hamilton.harte-lyne.ca.

;; AUTHORITY SECTION:
harte-lyne.ca. 172800 IN NS dns03.harte-lyne.ca.
harte-lyne.ca. 172800 IN NS dns04.harte-lyne.ca.
harte-lyne.ca. 172800 IN NS dns01.harte-lyne.ca.
harte-lyne.ca. 172800 IN NS dns02.harte-lyne.ca.

;; ADDITIONAL SECTION:
voinet09.hamilton.harte-lyne.ca. 172800 IN A 216.185.71.9
dns01.harte-lyne.ca. 172800 IN A 216.185.71.33
dns02.harte-lyne.ca. 172800 IN A 209.47.176.33
dns03.harte-lyne.ca. 172800 IN A 216.185.71.34
dns04.harte-lyne.ca. 172800 IN A 209.47.176.34

;; Query time: 48 msec
;; SERVER: 216.185.71.33#53(216.185.71.33)
;; WHEN: Tue Mar 17 14:29:02 2015
;; MSG SIZE rcvd: 253

What do you see?

···

On Tue, March 17, 2015 13:46, Ingo Bauersachs wrote:

[2015-03-17 11:30:33] ERROR[15413] chan_sip.c: 'UDP' is not a valid
transport for 'user'. we only use 'TLS'! ending call.
[2015-03-17 11:30:33] ERROR[15413] chan_sip.c: 'UDP' is not a valid
transport for 'user'. we only use 'TLS'! ending call.
[2015-03-17 11:30:33] NOTICE[15413] chan_sip.c: Registration from
'"90014" <sip:user@harte-lyne.ca>' failed for 'A.B.C.D:1024' -
Device
not configured to use this transport type
[2015-03-17 11:30:33] NOTICE[15413] chan_sip.c: Registration from
'"90014" <sip:user@harte-lyne.ca>' failed for 'A.B.C.D:1024' -
Device
not configured to use this transport type

I do not know where we have misconfigured Jitsi but apparently we
have.

According to the user for this account the Security tab has Enable
support to encrypt set. It has SDES selected and moved to the top of
Advanced encryption settings. It also has both DTLS and ZRTP
de-selected. It has both AES ciphers enabled. It has RTP/SAVP
Mandatory set.

The default global encodings are overridden and all the video codecs
are deselected.

Still we see the request for UDP show up when they attempt to
connect.
Have I overlooked something? What?

How is this user connected to your network? If not through a VPN, then
the SRV on your public DNS seems to be missing. Either publish
_sips._tcp.harte-lyne.ca or configure the proxy manually (more secure
anyway if you don't use DNSSEC).

If required I have obtained the log files created by the user
immediately following a failed connection attempt.

Ingo

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3


#5

How is this user connected to your network? If not through a VPN, then
the SRV on your public DNS seems to be missing. Either publish
_sips._tcp.harte-lyne.ca or configure the proxy manually (more secure
anyway if you don't use DNSSEC).

If required I have obtained the log files created by the user
immediately following a failed connection attempt.

Ingo

I see it from here, unless I mistake what you write:

dig _sips._tcp.harte-lyne.ca SRV

[...]
What do you see?

Same - now. When I wrote the previous mail the SRV wasn't there.

Ingo


#6

That is odd. I have just now, after receiving your note, altered the
zone file to remove the TTLs of 300 from those records. But the
records were all there. So the serial number now should be today's.

# dig _sips._tcp.harte-lyne.ca SRV SOA
;; Warning, extra type option

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.2 <<>>
_sips._tcp.harte-lyne.ca SRV SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20074
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;_sips._tcp.harte-lyne.ca. IN SOA

;; AUTHORITY SECTION:
harte-lyne.ca. 7200 IN SOA dns01.harte-lyne.ca.
nameservice.harte-lyne.ca. 2015031702 10800 3600 1209600 7200

;; Query time: 51 msec
;; SERVER: 216.185.71.33#53(216.185.71.33)
;; WHEN: Tue Mar 17 14:41:08 2015
;; MSG SIZE rcvd: 96

and the TTL is now the default instead of 300 seconds. Would a short
TTL have anything to do with the missing SRV record? What serial is
on the harte-lyne.ca zone file that you have cached?

···

On Tue, March 17, 2015 14:36, Ingo Bauersachs wrote:

How is this user connected to your network? If not through a VPN,
then
the SRV on your public DNS seems to be missing. Either publish
_sips._tcp.harte-lyne.ca or configure the proxy manually (more
secure
anyway if you don't use DNSSEC).

If required I have obtained the log files created by the user
immediately following a failed connection attempt.

Ingo

I see it from here, unless I mistake what you write:

dig _sips._tcp.harte-lyne.ca SRV

[...]
What do you see?

Same - now. When I wrote the previous mail the SRV wasn't there.

Ingo

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3


#7

That is odd. I have just now, after receiving your note, altered the
zone file to remove the TTLs of 300 from those records. But the
records were all there. So the serial number now should be today's.

# dig _sips._tcp.harte-lyne.ca SRV SOA
;; Warning, extra type option

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.2 <<>>
_sips._tcp.harte-lyne.ca SRV SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20074
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;_sips._tcp.harte-lyne.ca. IN SOA

;; AUTHORITY SECTION:
harte-lyne.ca. 7200 IN SOA dns01.harte-lyne.ca.
nameservice.harte-lyne.ca. 2015031702 10800 3600 1209600 7200

;; Query time: 51 msec
;; SERVER: 216.185.71.33#53(216.185.71.33)
;; WHEN: Tue Mar 17 14:41:08 2015
;; MSG SIZE rcvd: 96

and the TTL is now the default instead of 300 seconds. Would a short
TTL have anything to do with the missing SRV record?

No, rather a long TTL because the DNS server would think its cache is still
valid.

What serial is
on the harte-lyne.ca zone file that you have cached?

Default Server: google-public-dns-b.google.com
Address: 8.8.4.4

set type=SRV
_sips._tcp.harte-lyne.ca

Server: google-public-dns-b.google.com
Address: 8.8.4.4

Non-authoritative answer:
_sips._tcp.harte-lyne.ca SRV service location:
          priority = 10
          weight = 10
          port = 5061
          svr hostname = voinet09.hamilton.harte-lyne.ca

set type=SOA
_sips._tcp.harte-lyne.ca

Server: google-public-dns-b.google.com
Address: 8.8.4.4

harte-lyne.ca
        primary name server = dns01.harte-lyne.ca
        responsible mail addr = nameservice.harte-lyne.ca
        serial = 2015031702
        refresh = 10800 (3 hours)
        retry = 3600 (1 hour)
        expire = 1209600 (14 days)
        default TTL = 7200 (2 hours)

I might have made a typo before, I'm tired, but don't really think I did.
Anyway, it's there now. Does your remote user still have the problem? If so,
it's obviously not DNS, and then please send the logs.

Ingo


#8

I might have made a typo before, I'm tired, but don't really think I
did. Anyway, it's there now. Does your remote user still have the
problem?

Yes:

[...]

If so, it's obviously not DNS, and then please send the logs.

I had the user run dig in a terminal session using the DNS setup
provided by their ISP. That showed all three SRV records as expected.

Logs from the incident reported first are attached.

...
java.net.NoRouteToHostException: No route to host
...

Jitsi does try to connect over TLS, but fails. No route to host usually
means that the server is offline or otherwise unreachable - which is
obviously not the case (at least from here and now, you'll have a failed
login attempt from 178.82.24.134).

Some ideas:
- If you have fail2ban active, the user might be blocked over TCP there
- Ports 5060/5061 somehow blocked by the remote users CPE/ISP
- General connection problem, can you try "openssl s_client -connect
voinet09.hamilton.harte-lyne.ca:5061" from that client?

If the openssl command works, what happens if you configure the proxy
manually to voinet09.hamilton.harte-lyne.ca, 5061, TLS in the account
options?

By the way. I appreciate your assistance very much.

You're welcome.

Ingo

···

On Tue, March 17, 2015 15:03, Ingo Bauersachs wrote:


#9

Please keep the discussion on the list unless there is sensitive information
in (which this openssl output was not).

...
java.net.NoRouteToHostException: No route to host
...

Jitsi does try to connect over TLS, but fails. No route to host
usually
means that the server is offline or otherwise unreachable - which is
obviously not the case (at least from here and now, you'll have a
failed
login attempt from 178.82.24.134).

Some ideas:
- If you have fail2ban active, the user might be blocked over TCP
there
- Ports 5060/5061 somehow blocked by the remote users CPE/ISP
- General connection problem, can you try "openssl s_client -connect
voinet09.hamilton.harte-lyne.ca:5061" from that client?

If the openssl command works, what happens if you configure the proxy
manually to voinet09.hamilton.harte-lyne.ca, 5061, TLS in the account
options?

By the way. I appreciate your assistance very much.

You're welcome.

Ingo

This is what they get. We now know that originally there was a
firewall problem at their end. They have opened 5060-5061 for both
UDP and TCP.

It is not necessary to open any ports on the firewall _inbound_. Outbound
however must be open of course, which is normally the case unless you're in
a very restricted environment. But then you'd also need to open outbound UDP
on all ports for the actual voice traffic anyway.

However, TLS still does not work. They can connect
using UDP but not with TLS. Output from openssl follows:

[openssl success]

Did you try configuring the proxy manually in Jitsi (i.e. in the account
options, NOT the global proxy)? And is the logged error in still the same
NoRouteToHost?

Ingo

···

On Tue, March 17, 2015 15:38, Ingo Bauersachs wrote:


#10

I will not be able to test these suggestions until tomorrow as the
user is now onsite and not at the remote location. But, we will
return to the issue then.

As for configuring the proxy: what settings would we use? As far as I
can tell there is no proxy in use for their connection.

···

On Wed, March 18, 2015 06:55, Ingo Bauersachs wrote:

This is what they get. We now know that originally there was a
firewall problem at their end. They have opened 5060-5061 for both
UDP and TCP.

It is not necessary to open any ports on the firewall _inbound_.
Outbound however must be open of course, which is normally the
case unless you're in a very restricted environment. But then
you'd also need to open outbound UDP on all ports for the actual
voice traffic anyway.

However, TLS still does not work. They can connect
using UDP but not with TLS. Output from openssl follows:

[openssl success]

Did you try configuring the proxy manually in Jitsi (i.e. in the
account options, NOT the global proxy)? And is the logged error
in still the same NoRouteToHost?

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3