[jitsi-dev] Media over tcp issue for clients behind firewall


#1

Hello everyone,

I have an issue with videobridge when I try to use 443/TCP video streams for clients behind a firewall (Please see the attached PDF diagram for more information).

I have a server with two network interfaces, eth0 for web and eth1 for media streams. I noticed that the newest version of JVB has both UDP and TCP activated. In order to bind on port 4443 and announce port 443, I set the following configuration in sip-communicator.properties with an iptables port redirection (443=>4443):
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

By default, my JVB binds on port 4443 but when I set the above configuration, TCP streams don't work. It seems that JVB doesn't take these parameters into account : TCP_HARVESTER_MAPPED_PORT and ipv6.DISABLED. Because I had to disable ipv6 manually on my server to make JVB use only ipv4.

Do you have any idea how to fix this issue?

Best regards,
Hamza KHAIT

media over tcp issue.pdf (60.4 KB)


#2

Hi,
Can you check in webrtc-internals what candidates do you see, do you
see port 4443?
Looking at your diagram why you need to do the 4443 to 443 and not
just bind jvb directly to 443.
To start jvb on privileged ports you need to install and configure
authbind, here is how you can do it:
https://github.com/jitsi/jitsi-meet/blob/master/debian/jitsi-meet.postinst#L101

Regards
damencho

···

On Wed, Oct 19, 2016 at 6:53 AM, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE <hamza.khait@i-carre.net> wrote:

Hello everyone,

I have an issue with videobridge when I try to use 443/TCP video streams for
clients behind a firewall (Please see the attached PDF diagram for more
information).

I have a server with two network interfaces, eth0 for web and eth1 for media
streams. I noticed that the newest version of JVB has both UDP and TCP
activated. In order to bind on port 4443 and announce port 443, I set the
following configuration in sip-communicator.properties with an iptables port
redirection (443=>4443):
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

By default, my JVB binds on port 4443 but when I set the above
configuration, TCP streams don't work. It seems that JVB doesn't take these
parameters into account : TCP_HARVESTER_MAPPED_PORT and ipv6.DISABLED.
Because I had to disable ipv6 manually on my server to make JVB use only
ipv4.

Do you have any idea how to fix this issue?

Best regards,
Hamza KHAIT
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hello,

Same result. I tried Authbind and now JVB is listening on 443 (on eth1).

Here are my configuration files :
- sip-communicator.properties
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

- videobridge/config
JVB_OPTS="--apis=rest,xmpp"
AUTHBIND=yes

- network config :
eth0 : 192.168.0.2 [Nginx listening on 80 and 443]
eth1 : 192.168.0.3 [JVB listening on 443 and 10000]

- webrtc-internals from the client behind firewall, under setRemoteDescription:
(Please see the attached file)

Best regards,
Hamza KHAIT

setRemoteDescription.txt (2.1 KB)

···

Le 19/10/2016 15:36, > Damian Minkov (par Internet, dépôt dev-bounces@jitsi.org) a écrit :

Hi,
Can you check in webrtc-internals what candidates do you see, do you
see port 4443?
Looking at your diagram why you need to do the 4443 to 443 and not
just bind jvb directly to 443.
To start jvb on privileged ports you need to install and configure
authbind, here is how you can do it:
https://github.com/jitsi/jitsi-meet/blob/master/debian/jitsi-meet.postinst#L101

Regards
damencho

On Wed, Oct 19, 2016 at 6:53 AM, KHAIT Hamza - > SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE > <hamza.khait@i-carre.net> wrote:

Hello everyone,

I have an issue with videobridge when I try to use 443/TCP video streams for
clients behind a firewall (Please see the attached PDF diagram for more
information).

I have a server with two network interfaces, eth0 for web and eth1 for media
streams. I noticed that the newest version of JVB has both UDP and TCP
activated. In order to bind on port 4443 and announce port 443, I set the
following configuration in sip-communicator.properties with an iptables port
redirection (443=>4443):
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

By default, my JVB binds on port 4443 but when I set the above
configuration, TCP streams don't work. It seems that JVB doesn't take these
parameters into account : TCP_HARVESTER_MAPPED_PORT and ipv6.DISABLED.
Because I had to disable ipv6 manually on my server to make JVB use only
ipv4.

Do you have any idea how to fix this issue?

Best regards,
Hamza KHAIT
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hi,

Yep this is strange you can see that in the remote description there
are no public addresses for your jvb.
So if the jvb is behind nat you need to configure the addresses, the
public and the internal one.
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address
And then you must see in the remote description the internal and the
external address and it should be fine.

Regards
damencho

···

On Wed, Oct 19, 2016 at 9:33 AM, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE <hamza.khait@i-carre.net> wrote:

Hello,

Same result. I tried Authbind and now JVB is listening on 443 (on eth1).

Here are my configuration files :
- sip-communicator.properties
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

- videobridge/config
JVB_OPTS="--apis=rest,xmpp"
AUTHBIND=yes

- network config :
eth0 : 192.168.0.2 [Nginx listening on 80 and 443]
eth1 : 192.168.0.3 [JVB listening on 443 and 10000]

- webrtc-internals from the client behind firewall, under
setRemoteDescription:
(Please see the attached file)

Best regards,
Hamza KHAIT

Le 19/10/2016 15:36, > Damian Minkov (par Internet, dépôt > dev-bounces@jitsi.org) a écrit :

Hi,
Can you check in webrtc-internals what candidates do you see, do you
see port 4443?
Looking at your diagram why you need to do the 4443 to 443 and not
just bind jvb directly to 443.
To start jvb on privileged ports you need to install and configure
authbind, here is how you can do it:

https://github.com/jitsi/jitsi-meet/blob/master/debian/jitsi-meet.postinst#L101

Regards
damencho

On Wed, Oct 19, 2016 at 6:53 AM, KHAIT Hamza - >> SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE >> <hamza.khait@i-carre.net> wrote:

Hello everyone,

I have an issue with videobridge when I try to use 443/TCP video streams
for
clients behind a firewall (Please see the attached PDF diagram for more
information).

I have a server with two network interfaces, eth0 for web and eth1 for
media
streams. I noticed that the newest version of JVB has both UDP and TCP
activated. In order to bind on port 4443 and announce port 443, I set the
following configuration in sip-communicator.properties with an iptables
port
redirection (443=>4443):
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

By default, my JVB binds on port 4443 but when I set the above
configuration, TCP streams don't work. It seems that JVB doesn't take
these
parameters into account : TCP_HARVESTER_MAPPED_PORT and ipv6.DISABLED.
Because I had to disable ipv6 manually on my server to make JVB use only
ipv4.

Do you have any idea how to fix this issue?

Best regards,
Hamza KHAIT
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

The jvb server is not behind NAT. we only have exchange of routing tables within the testing infrastructure. Thus the clients and jvb are not in the same subnet but we can still reach the jvb server. should I still add NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS ? I'm wondering why it worked automatically with 4443 and not 443...

Best regards,
Hamza

···

Le 19/10/2016 16:43, > Damian Minkov (par Internet, dépôt damencho@damencho.com) a écrit :

Hi,

Yep this is strange you can see that in the remote description there
are no public addresses for your jvb.
So if the jvb is behind nat you need to configure the addresses, the
public and the internal one.
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address
And then you must see in the remote description the internal and the
external address and it should be fine.

Regards
damencho

On Wed, Oct 19, 2016 at 9:33 AM, KHAIT Hamza - > SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE > <hamza.khait@i-carre.net> wrote:

Hello,

Same result. I tried Authbind and now JVB is listening on 443 (on eth1).

Here are my configuration files :
- sip-communicator.properties
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

- videobridge/config
JVB_OPTS="--apis=rest,xmpp"
AUTHBIND=yes

- network config :
eth0 : 192.168.0.2 [Nginx listening on 80 and 443]
eth1 : 192.168.0.3 [JVB listening on 443 and 10000]

- webrtc-internals from the client behind firewall, under
setRemoteDescription:
(Please see the attached file)

Best regards,
Hamza KHAIT

Le 19/10/2016 15:36, > Damian Minkov (par Internet, dépôt >> dev-bounces@jitsi.org) a écrit :

Hi,
Can you check in webrtc-internals what candidates do you see, do you
see port 4443?
Looking at your diagram why you need to do the 4443 to 443 and not
just bind jvb directly to 443.
To start jvb on privileged ports you need to install and configure
authbind, here is how you can do it:

https://github.com/jitsi/jitsi-meet/blob/master/debian/jitsi-meet.postinst#L101

Regards
damencho

On Wed, Oct 19, 2016 at 6:53 AM, KHAIT Hamza - >>> SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE >>> <hamza.khait@i-carre.net> wrote:

Hello everyone,

I have an issue with videobridge when I try to use 443/TCP video streams
for
clients behind a firewall (Please see the attached PDF diagram for more
information).

I have a server with two network interfaces, eth0 for web and eth1 for
media
streams. I noticed that the newest version of JVB has both UDP and TCP
activated. In order to bind on port 4443 and announce port 443, I set the
following configuration in sip-communicator.properties with an iptables
port
redirection (443=>4443):
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

By default, my JVB binds on port 4443 but when I set the above
configuration, TCP streams don't work. It seems that JVB doesn't take
these
parameters into account : TCP_HARVESTER_MAPPED_PORT and ipv6.DISABLED.
Because I had to disable ipv6 manually on my server to make JVB use only
ipv4.

Do you have any idea how to fix this issue?

Best regards,
Hamza KHAIT
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Hum, if its not behind nat why you bind it to a local ip only.
So jvb listens and uses the ipaddress only of eth1:
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
So you need to remove that rule, so it can bind and use the interface
with public address.

Regards
damencho

···

On Wed, Oct 19, 2016 at 10:06 AM, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE <hamza.khait@i-carre.net> wrote:

The jvb server is not behind NAT. we only have exchange of routing tables
within the testing infrastructure. Thus the clients and jvb are not in the
same subnet but we can still reach the jvb server. should I still add
NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS ? I'm wondering
why it worked automatically with 4443 and not 443...

Best regards,
Hamza

Le 19/10/2016 16:43, > Damian Minkov (par Internet, dépôt > damencho@damencho.com) a écrit :

Hi,

Yep this is strange you can see that in the remote description there
are no public addresses for your jvb.
So if the jvb is behind nat you need to configure the addresses, the
public and the internal one.

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address
And then you must see in the remote description the internal and the
external address and it should be fine.

Regards
damencho

On Wed, Oct 19, 2016 at 9:33 AM, KHAIT Hamza - >> SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE >> <hamza.khait@i-carre.net> wrote:

Hello,

Same result. I tried Authbind and now JVB is listening on 443 (on eth1).

Here are my configuration files :
- sip-communicator.properties
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

- videobridge/config
JVB_OPTS="--apis=rest,xmpp"
AUTHBIND=yes

- network config :
eth0 : 192.168.0.2 [Nginx listening on 80 and 443]
eth1 : 192.168.0.3 [JVB listening on 443 and 10000]

- webrtc-internals from the client behind firewall, under
setRemoteDescription:
(Please see the attached file)

Best regards,
Hamza KHAIT

Le 19/10/2016 15:36, > Damian Minkov (par Internet, dépôt >>> dev-bounces@jitsi.org) a écrit :

Hi,
Can you check in webrtc-internals what candidates do you see, do you
see port 4443?
Looking at your diagram why you need to do the 4443 to 443 and not
just bind jvb directly to 443.
To start jvb on privileged ports you need to install and configure
authbind, here is how you can do it:

https://github.com/jitsi/jitsi-meet/blob/master/debian/jitsi-meet.postinst#L101

Regards
damencho

On Wed, Oct 19, 2016 at 6:53 AM, KHAIT Hamza - >>>> SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE >>>> <hamza.khait@i-carre.net> wrote:

Hello everyone,

I have an issue with videobridge when I try to use 443/TCP video
streams
for
clients behind a firewall (Please see the attached PDF diagram for more
information).

I have a server with two network interfaces, eth0 for web and eth1 for
media
streams. I noticed that the newest version of JVB has both UDP and TCP
activated. In order to bind on port 4443 and announce port 443, I set
the
following configuration in sip-communicator.properties with an iptables
port
redirection (443=>4443):
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
org.ice4j.ipv6.DISABLED=true

By default, my JVB binds on port 4443 but when I set the above
configuration, TCP streams don't work. It seems that JVB doesn't take
these
parameters into account : TCP_HARVESTER_MAPPED_PORT and ipv6.DISABLED.
Because I had to disable ipv6 manually on my server to make JVB use
only
ipv4.

Do you have any idea how to fix this issue?

Best regards,
Hamza KHAIT
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Hi,

I'm working with Hamza on this.

The ip address on eth1 is a "public" address as we're on a test plateform (server and clients are in the same network). That's the reason why our candidates are in a private network.

The purpose of using org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1 is to separate the web (with nginx TCP 443) from media (jvb on TCP 443 and UDP 10000). So we set up nginx to listen on eth0 and jvb to listen on eth1 (see the attached file).

We built this architecture cause we were unlucky trying to use only one network interface for all with previous versions of Jitsi. Finally it's easier for everyone to understand and to administrate.

Regards,
Julien

media over tcp issue.pdf (60.4 KB)

···

Le 19/10/2016 17:14, > Damian Minkov (par Internet, dépôt dev-bounces@jitsi.org) a écrit :

Hum, if its not behind nat why you bind it to a local ip only.
So jvb listens and uses the ipaddress only of eth1:
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
So you need to remove that rule, so it can bind and use the interface
with public address.

Regards
damencho


#8

Hum, so the remote description in the client is correct, receiving
that "public" address. And you say it is not working, it cannot
connect over tcp?
Can you check the jvb logs when you attempt, and the client logs, also
webrtc-internals dump can also help debugging this.
So you confirm clients can connect from their network to 192.168.0.3:443, right?

Regards
damencho

···

On Wed, Oct 19, 2016 at 10:57 AM, DELAMARRE Julien - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE <Julien.DELAMARRE@i-carre.net> wrote:

Hi,

I'm working with Hamza on this.

The ip address on eth1 is a "public" address as we're on a test plateform
(server and clients are in the same network). That's the reason why our
candidates are in a private network.

The purpose of using org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1 is to
separate the web (with nginx TCP 443) from media (jvb on TCP 443 and UDP
10000). So we set up nginx to listen on eth0 and jvb to listen on eth1 (see
the attached file).

We built this architecture cause we were unlucky trying to use only one
network interface for all with previous versions of Jitsi. Finally it's
easier for everyone to understand and to administrate.

Regards,
Julien

Le 19/10/2016 17:14, > Damian Minkov (par Internet, dépôt > dev-bounces@jitsi.org) a écrit :

Hum, if its not behind nat why you bind it to a local ip only.
So jvb listens and uses the ipaddress only of eth1:
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
So you need to remove that rule, so it can bind and use the interface
with public address.

Regards
damencho

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

When you enabled jvb directly to use 443 port, you removed that
iptables rule, right?

···

On Wed, Oct 19, 2016 at 11:08 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hum, so the remote description in the client is correct, receiving
that "public" address. And you say it is not working, it cannot
connect over tcp?
Can you check the jvb logs when you attempt, and the client logs, also
webrtc-internals dump can also help debugging this.
So you confirm clients can connect from their network to 192.168.0.3:443, right?

Regards
damencho

On Wed, Oct 19, 2016 at 10:57 AM, DELAMARRE Julien - > SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE > <Julien.DELAMARRE@i-carre.net> wrote:

Hi,

I'm working with Hamza on this.

The ip address on eth1 is a "public" address as we're on a test plateform
(server and clients are in the same network). That's the reason why our
candidates are in a private network.

The purpose of using org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1 is to
separate the web (with nginx TCP 443) from media (jvb on TCP 443 and UDP
10000). So we set up nginx to listen on eth0 and jvb to listen on eth1 (see
the attached file).

We built this architecture cause we were unlucky trying to use only one
network interface for all with previous versions of Jitsi. Finally it's
easier for everyone to understand and to administrate.

Regards,
Julien

Le 19/10/2016 17:14, > Damian Minkov (par Internet, dépôt >> dev-bounces@jitsi.org) a écrit :

Hum, if its not behind nat why you bind it to a local ip only.
So jvb listens and uses the ipaddress only of eth1:
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
So you need to remove that rule, so it can bind and use the interface
with public address.

Regards
damencho

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Hello Damian,

Yes the iptables rule is disabled. Here attached you'll find jvb logs while attempting to connect to Jitsi Meet from a client behind firewall (iptables -A OUTPUT -p udp --dport 10000 -j DROP). The clients ip is 172.20.41.65 and the server's hostname is myJistiServer.mydomaine

webrtc-internals hasn't changed. I still have :
a=candidate:1 1 ssltcp 2130706431 192.168.251.62 443 typ host generation 0
a=candidate:2 1 udp 2130706431 192.168.251.62 10000 typ host generation 0

I can reach 192.168.0.3:443 from 172.20.41.65 using telnet/netcat... but I can't get any media stream over 192.168.0.3:443.

Best regads,
Hamza

jvb.log (80.8 KB)

···

Le 19/10/2016 18:09, > Damian Minkov (par Internet, dépôt dev-bounces@jitsi.org) a écrit :

When you enabled jvb directly to use 443 port, you removed that
iptables rule, right?

On Wed, Oct 19, 2016 at 11:08 AM, Damian Minkov <damencho@jitsi.org> > wrote:

Hum, so the remote description in the client is correct, receiving
that "public" address. And you say it is not working, it cannot
connect over tcp?
Can you check the jvb logs when you attempt, and the client logs, also
webrtc-internals dump can also help debugging this.
So you confirm clients can connect from their network to 192.168.0.3:443, right?

Regards
damencho

On Wed, Oct 19, 2016 at 10:57 AM, DELAMARRE Julien - >> SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE >> <Julien.DELAMARRE@i-carre.net> wrote:

Hi,

I'm working with Hamza on this.

The ip address on eth1 is a "public" address as we're on a test plateform
(server and clients are in the same network). That's the reason why our
candidates are in a private network.

The purpose of using org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1 is to
separate the web (with nginx TCP 443) from media (jvb on TCP 443 and UDP
10000). So we set up nginx to listen on eth0 and jvb to listen on eth1 (see
the attached file).

We built this architecture cause we were unlucky trying to use only one
network interface for all with previous versions of Jitsi. Finally it's
easier for everyone to understand and to administrate.

Regards,
Julien

Le 19/10/2016 17:14, > Damian Minkov (par Internet, dépôt >>> dev-bounces@jitsi.org) a écrit :

Hum, if its not behind nat why you bind it to a local ip only.
So jvb listens and uses the ipaddress only of eth1:
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
So you need to remove that rule, so it can bind and use the interface
with public address.

Regards
damencho

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hi again,

So you have a wrong ip address in the webrtc-internals remote
candidates, or it is a typo?
So it seems the connection failed between Pair failed:
192.168.0.3:443/tcp/host -> 172.20.41.65:9/tcp/host (stream.RTP), also
the low port seems suspicious to me.
You can try running tcpdump on the server and check what is going on
with that connection, do you see anything suspicious.
I have no idea currently, if anybody want to chime in and see anything else.

Regards
damencho

···

On Thu, Oct 20, 2016 at 4:40 AM, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE <hamza.khait@i-carre.net> wrote:

Hello Damian,

Yes the iptables rule is disabled. Here attached you'll find jvb logs while
attempting to connect to Jitsi Meet from a client behind firewall (iptables
-A OUTPUT -p udp --dport 10000 -j DROP). The clients ip is 172.20.41.65 and
the server's hostname is myJistiServer.mydomaine

webrtc-internals hasn't changed. I still have :
a=candidate:1 1 ssltcp 2130706431 192.168.251.62 443 typ host generation 0
a=candidate:2 1 udp 2130706431 192.168.251.62 10000 typ host generation 0

I can reach 192.168.0.3:443 from 172.20.41.65 using telnet/netcat... but I
can't get any media stream over 192.168.0.3:443.

Best regads,
Hamza

Le 19/10/2016 18:09, > Damian Minkov (par Internet, dépôt > dev-bounces@jitsi.org) a écrit :

When you enabled jvb directly to use 443 port, you removed that
iptables rule, right?

On Wed, Oct 19, 2016 at 11:08 AM, Damian Minkov <damencho@jitsi.org> >> wrote:

Hum, so the remote description in the client is correct, receiving
that "public" address. And you say it is not working, it cannot
connect over tcp?
Can you check the jvb logs when you attempt, and the client logs, also
webrtc-internals dump can also help debugging this.
So you confirm clients can connect from their network to 192.168.0.3:443,
right?

Regards
damencho

On Wed, Oct 19, 2016 at 10:57 AM, DELAMARRE Julien - >>> SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE >>> <Julien.DELAMARRE@i-carre.net> wrote:

Hi,

I'm working with Hamza on this.

The ip address on eth1 is a "public" address as we're on a test
plateform
(server and clients are in the same network). That's the reason why our
candidates are in a private network.

The purpose of using org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1 is to
separate the web (with nginx TCP 443) from media (jvb on TCP 443 and UDP
10000). So we set up nginx to listen on eth0 and jvb to listen on eth1
(see
the attached file).

We built this architecture cause we were unlucky trying to use only one
network interface for all with previous versions of Jitsi. Finally it's
easier for everyone to understand and to administrate.

Regards,
Julien

Le 19/10/2016 17:14, > Damian Minkov (par Internet, dépôt >>>> dev-bounces@jitsi.org) a écrit :

Hum, if its not behind nat why you bind it to a local ip only.
So jvb listens and uses the ipaddress only of eth1:
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
So you need to remove that rule, so it can bind and use the interface
with public address.

Regards
damencho

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#12

This is definitely strange, as the ICE state goes from Running to Terminated. This is never supposed to happen. Are you running a modified version of jitsi-videobridge or ice4j?

Can you enable more detailed logs and also include a tcpdump from tcp/443 on the bridge?

Port 9 (discard) is used for active candidates (when the endpoint will initiate the TCP connection, with an unspecified port). It is probably normal to see it listed in some places.

Regards,
Boris

···

On 20/10/16 04:40, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE wrote:

Hello Damian,

Yes the iptables rule is disabled. Here attached you'll find jvb logs
while attempting to connect to Jitsi Meet from a client behind firewall
(iptables -A OUTPUT -p udp --dport 10000 -j DROP). The clients ip is
172.20.41.65 and the server's hostname is myJistiServer.mydomaine

webrtc-internals hasn't changed. I still have :
a=candidate:1 1 ssltcp 2130706431 192.168.251.62 443 typ host generation
0
a=candidate:2 1 udp 2130706431 192.168.251.62 10000 typ host generation
0

I can reach 192.168.0.3:443 from 172.20.41.65 using telnet/netcat... but
I can't get any media stream over 192.168.0.3:443.


#13

Thanks for the answer.

Yes, 192.168.251.62 was a typo sorry.. the actual address is 192.168.0.3

I will see the port 9 connection and let you know.

Thank you.

Regards,
Hamza

···

Le 20/10/2016 16:51, > Damian Minkov (par Internet, dépôt damencho@damencho.com) a écrit :

Hi again,

So you have a wrong ip address in the webrtc-internals remote
candidates, or it is a typo?
So it seems the connection failed between Pair failed:
192.168.0.3:443/tcp/host -> 172.20.41.65:9/tcp/host (stream.RTP), also
the low port seems suspicious to me.
You can try running tcpdump on the server and check what is going on
with that connection, do you see anything suspicious.
I have no idea currently, if anybody want to chime in and see anything else.

Regards
damencho

On Thu, Oct 20, 2016 at 4:40 AM, KHAIT Hamza - > SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE > <hamza.khait@i-carre.net> wrote:

Hello Damian,

Yes the iptables rule is disabled. Here attached you'll find jvb logs while
attempting to connect to Jitsi Meet from a client behind firewall (iptables
-A OUTPUT -p udp --dport 10000 -j DROP). The clients ip is 172.20.41.65 and
the server's hostname is myJistiServer.mydomaine

webrtc-internals hasn't changed. I still have :
a=candidate:1 1 ssltcp 2130706431 192.168.251.62 443 typ host generation 0
a=candidate:2 1 udp 2130706431 192.168.251.62 10000 typ host generation 0

I can reach 192.168.0.3:443 from 172.20.41.65 using telnet/netcat... but I
can't get any media stream over 192.168.0.3:443.

Best regads,
Hamza

Le 19/10/2016 18:09, > Damian Minkov (par Internet, dépôt >> dev-bounces@jitsi.org) a écrit :

When you enabled jvb directly to use 443 port, you removed that
iptables rule, right?

On Wed, Oct 19, 2016 at 11:08 AM, Damian Minkov <damencho@jitsi.org> >>> wrote:

Hum, so the remote description in the client is correct, receiving
that "public" address. And you say it is not working, it cannot
connect over tcp?
Can you check the jvb logs when you attempt, and the client logs, also
webrtc-internals dump can also help debugging this.
So you confirm clients can connect from their network to 192.168.0.3:443,
right?

Regards
damencho

On Wed, Oct 19, 2016 at 10:57 AM, DELAMARRE Julien - >>>> SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE >>>> <Julien.DELAMARRE@i-carre.net> wrote:

Hi,

I'm working with Hamza on this.

The ip address on eth1 is a "public" address as we're on a test
plateform
(server and clients are in the same network). That's the reason why our
candidates are in a private network.

The purpose of using org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1 is to
separate the web (with nginx TCP 443) from media (jvb on TCP 443 and UDP
10000). So we set up nginx to listen on eth0 and jvb to listen on eth1
(see
the attached file).

We built this architecture cause we were unlucky trying to use only one
network interface for all with previous versions of Jitsi. Finally it's
easier for everyone to understand and to administrate.

Regards,
Julien

Le 19/10/2016 17:14, > Damian Minkov (par Internet, dépôt >>>>> dev-bounces@jitsi.org) a écrit :

Hum, if its not behind nat why you bind it to a local ip only.
So jvb listens and uses the ipaddress only of eth1:
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth1
So you need to remove that rule, so it can bind and use the interface
with public address.

Regards
damencho

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#14

Hello Boris,

No, I'm using Jitsi Meet without any modification (from apt-get install jitsi-meet).

On my computer I set an iptables rule to block the udp traffic and test media over tcp :
sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443

Then I run "sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443" and connect to Jitsi Meet through Chrome (version 53.0.2785.116). tcpdump doesn't show anything and returns the following result after I exit :
:~$ sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443
tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

I also tried the following configurations with one network interface (192.168.0.3) :
- Nginx listening on 8443 instead of 443 - JVB on 4443/tcp. Result => media streams work fine.
- Nginx listening on 8443 instead of 443 - JVB on 443/tcp. Result => No media streams.

Something is wrong with the media over 443 but I couldn't figure it out...

Regards,
Hamza

···

Le 20/10/2016 19:52, > Boris Grozev (par Internet, dépôt dev-bounces@jitsi.org) a écrit :

On 20/10/16 04:40, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET > MESSAGERIE wrote:

This is definitely strange, as the ICE state goes from Running to
Terminated. This is never supposed to happen. Are you running a
modified version of jitsi-videobridge or ice4j?

Can you enable more detailed logs and also include a tcpdump from
tcp/443 on the bridge?

Port 9 (discard) is used for active candidates (when the endpoint will
initiate the TCP connection, with an unspecified port). It is probably
normal to see it listed in some places.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

Is it possible that enp4s0 is not the correct interface?

I don't see any reason why 4443 would work, but 443 would fail without even attempting a connection.

Boris

···

On 21/10/16 08:51, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE wrote:

Hello Boris,

No, I'm using Jitsi Meet without any modification (from apt-get install
jitsi-meet).

On my computer I set an iptables rule to block the udp traffic and test
media over tcp :
sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443

Then I run "sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443"
and connect to Jitsi Meet through Chrome (version 53.0.2785.116).
tcpdump doesn't show anything and returns the following result after I
exit :
:~$ sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443
tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size
262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel


#16

Hello Boris,

Just a quick update on this issue.

enp4s0 is the client's interface (the new Predictable Network Interface Naming on Ubuntu 16.04).

All I can see is that the client cannot automatically switch/connect to port 443 when udp is not available. However it works with other ports, for instance jvb listening on 4443 and announcing 4444 or 4445 or 4446... maybe it's about permissions ? Authbind works well though...

I will keep you posted on any progress from our side.

Regards,
Hamza KHAIT

···

Le 21/10/2016 16:09, > Boris Grozev (par Internet, dépôt boris@sip-communicator.org) a écrit :

Is it possible that enp4s0 is not the correct interface?

I don't see any reason why 4443 would work, but 443 would fail without
even attempting a connection.

Boris
On 21/10/16 08:51, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET > MESSAGERIE wrote:

Hello Boris,

No, I'm using Jitsi Meet without any modification (from apt-get install
jitsi-meet).

On my computer I set an iptables rule to block the udp traffic and test
media over tcp :
sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443

Then I run "sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443"
and connect to Jitsi Meet through Chrome (version 53.0.2785.116).
tcpdump doesn't show anything and returns the following result after I
exit :
:~$ sudo tcpdump -vvvn dst host 192.168.0.3 and dst port 443
tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size
262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel


#17

Hi,

Hello Boris,

Just a quick update on this issue.

enp4s0 is the client's interface (the new Predictable Network Interface
Naming on Ubuntu 16.04).

All I can see is that the client cannot automatically switch/connect to
port 443 when udp is not available. However it works with other ports,
for instance jvb listening on 4443 and announcing 4444 or 4445 or
4446... maybe it's about permissions ? Authbind works well though...

In another thread Jason Thomas recently found that chrome will block attempts to use port 443 when the IP address in the local network (or when it is an RFC1918 address? I'm not sure). Maybe you are running into the same problem? See the discussion here:

http://lists.jitsi.org/pipermail/users/2016-November/011911.html

Regards,
Boris

···

On 14/11/2016 04:18, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE wrote:


#18

Dear Boris,

Many thanks to you and Jason Thomas for the clarification.

Chrome actually blocks ssltcp connections on ports <1024 within a LAN to avoid Man-In-The-Middle attacks. That's why port 4444 worked and 443 didn't. If we wanna use media over tcp on a testing platform we have to use ports >1024. It makes sense now.

Thanks again!

Best regards,
Hamza KHAIT

···

Le 14/11/2016 17:01, > Boris Grozev (par Internet, dépôt boris@sip-communicator.org) a écrit :

Hi,

On 14/11/2016 04:18, KHAIT Hamza - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE > ET MESSAGERIE wrote:

Hello Boris,

Just a quick update on this issue.

enp4s0 is the client's interface (the new Predictable Network Interface
Naming on Ubuntu 16.04).

All I can see is that the client cannot automatically switch/connect to
port 443 when udp is not available. However it works with other ports,
for instance jvb listening on 4443 and announcing 4444 or 4445 or
4446... maybe it's about permissions ? Authbind works well though...

In another thread Jason Thomas recently found that chrome will block
attempts to use port 443 when the IP address in the local network (or
when it is an RFC1918 address? I'm not sure). Maybe you are running
into the same problem? See the discussion here:

http://lists.jitsi.org/pipermail/users/2016-November/011911.html

Regards,
Boris