[jitsi-dev] Firewalls blocking fragmented ip packets


#1

Hi all,
   I only want to inform you all that I just discovered that there are some
firewalls (for example Comodo Firewall) that block fragmented ip datagrams as
their default setting.
In this case (I have discovered it on my pc, unfortunately) audio and video
sessions are difficult to create. In particular, only some packets can be
exchanged between the caller and the callee, so the calling could be disturbed
or, in some cases (a lot of cases, in my experience), fail at all.
So, if any of you have problems to make and receive call you could try to
perform this check.
I want also to say that this is not a bug in sip communicator (or I don't think
so), this problem is only caused by a too strict default firewall configuration.
Hope this helps someone.

Regards,
Daniel


#2

I am one of the devs with the m0n0wall project, and that is default behavior with most good firewalls for good reason. That said, it is easy to bypass for limited traffic. It may be worth looking into a way to do without needing fragmented packets, however.

      Lee

···

On 01/30/2011 05:17 PM, dzmail90-voip@yahoo.it wrote:

Hi all,
    I only want to inform you all that I just discovered that there are some
firewalls (for example Comodo Firewall) that block fragmented ip datagrams as
their default setting.
In this case (I have discovered it on my pc, unfortunately) audio and video
sessions are difficult to create. In particular, only some packets can be
exchanged between the caller and the callee, so the calling could be disturbed
or, in some cases (a lot of cases, in my experience), fail at all.
So, if any of you have problems to make and receive call you could try to
perform this check.
I want also to say that this is not a bug in sip communicator (or I don't think
so), this problem is only caused by a too strict default firewall configuration.
Hope this helps someone.


#3

Hi all,
thank you for your answers.
It is a bit complicated using SIP Communicator, or whatever SIP client with IP
protocol (with XMPP Jingle is the same).
Firewalls blocking fragmented packets means that the SIP network and protocol is
not really usable and affordable. People cannot use SIP, because they aren't
sure about the fact that the packets will be forwarded to the destination or
not, so every call is like a roulette. I'm afraid I have to state that in this
situation secure network is incompatible with multimedia communications such as
SIP or XMPP Jingle.
After this, now something that is constructive:
1) Emil, you wrote something about using TCP. So, how to use TCP? What are
disadvantages of this method?
2) Does break something using the don't fragment bit in ip packets? If not, SIP
Communicator should use it.
3) Trying to discover the path with the maximum MTU allowed could be useful. Is
it implemented?
I want only to remark that a lot of people could have this problem, and maybe
they thought about how bad SIP Communicator is. When releasing an 1.0 version we
should look to the non expert users too, and they will not understand why
firewall is blocking their callings (uh, what is firewall? It's something to
eat?). They expect SIP Communicator (Jitsi) working out-of-the-box, in any
circumstances. We should think about it. Changing something is needed: changing
SIP Communicator, changing SIP protocol, changing IP protocol (ok, this was
done, but we cannot wait the moment when everyone will use IPv6. It seems that
it's better not having addresses for everyone than using the new IP version).
So, what's next?

Best wishes,

Daniel

----- Messaggio originale -----

···

Da: Emil Ivov <emcho@sip-communicator.org>
A: "dzmail90-voip@yahoo.it" <dzmail90-voip@yahoo.it>
Cc: "dev@jitsi.java.net" <dev@jitsi.java.net>
Inviato: Lun 31 gennaio 2011, 06:44:12
Oggetto: [jitsi-dev] Re: Firewalls blocking fragmented ip packets

Hey Daniel,

This is indeed a known issue. Two possible work-arounds are:

1) disabling whatever codecs you do not need so that invitation packets won't be
fragmented
3) using TCP

Hope this helps,
Emil

--sent from my mobile


#4

As someone who writes firewalls, I have to take exception to this. :slight_smile: The problem really is shortcuts. The OS really should do MTU discovery, and that should fix the problem. Some OSs do this well, and others... This is why so many times you have to set the OS MTU manually. And really, try explaining that to your grandmother, on a cell phone while she is at a hotel with support in India...

But the quickest fix is lowing the MTU, and then there are no fragments.

      Lee

···

On 02/02/2011 05:31 PM, dzmail90-voip@yahoo.it wrote:

Firewalls blocking fragmented packets means that the SIP network and protocol is
not really usable and affordable. People cannot use SIP, because they aren't
sure about the fact that the packets will be forwarded to the destination or
not, so every call is like a roulette. I'm afraid I have to state that in this
situation secure network is incompatible with multimedia communications such as
SIP or XMPP Jingle.


#5

Lee Sharp wrote, On 02/03/2011 02:19 AM (EEST):

···

On 02/02/2011 05:31 PM, dzmail90-voip@yahoo.it wrote:

Firewalls blocking fragmented packets means that the SIP network and
protocol is
not really usable and affordable. People cannot use SIP, because they
aren't
sure about the fact that the packets will be forwarded to the
destination or
not, so every call is like a roulette. I'm afraid I have to state that
in this
situation secure network is incompatible with multimedia
communications such as
SIP or XMPP Jingle.

As someone who writes firewalls, I have to take exception to this. :slight_smile:
The problem really is shortcuts. The OS really should do MTU discovery,

And the no OS can do that if some stupid firewall is dropping all ICMP
silently... :wink:


#6

Hey Daniel,

I understand this is frustrating, but, believe it or not, this is not
quite the responsibility of SC/Jitsi. Read on.

На 03.02.11 00:31, dzmail90-voip@yahoo.it написа:

1) Emil, you wrote something about using TCP. So, how to use TCP?

Best case is: your provider supports it and indicates that TCP is the
default transport in the corresponding DNS NAPTR records. In this case
SIP communicator would automatically choose TCP and the user won't be
bothered with it.

If your provider/server does support TCP but has not configured NAPTR
records, then you need to modify your account settings and choose TCP as
the method for connecting to your proxy.

If your provider/server does not support TCP .... there's nothing SC
could do.

What are disadvantages of this method?

None that really matter. UDP is mostly used with SIP for historical
reasons.

2) Does break something using the don't fragment bit in ip packets? If not, SIP
Communicator should use it.

Using the don't fragment bit simply means that your packets will be
dropped rather than fragmented.

3) Trying to discover the path with the maximum MTU allowed could be useful. Is
it implemented?

As Lee pointed out - this is the responsibility of the operating system.
What we could do is show a warning to users when we detect this and tell
them to disable codecs. Given that this is mostly the responsibility of
the provider though I'd have to admit that this would be rather low
priority.

I want only to remark that a lot of people could have this problem, and maybe
they thought about how bad SIP Communicator is. When releasing an 1.0 version we
should look to the non expert users too, and they will not understand why
firewall is blocking their callings (uh, what is firewall? It's something to
eat?). They expect SIP Communicator (Jitsi) working out-of-the-box, in any
circumstances. We should think about it. Changing something is needed: changing
SIP Communicator, changing SIP protocol,

As it was already said: SIP works with TCP and SC supports it. If your
provider does not: you should address your questions to them :slight_smile:

As for XMPP: the problem simply does not exist. All major providers and
implementations use it with TCP (I am not even sure anyone has ever used
XMPP over UDP for anything else than research and experimentation).

changing IP protocol (ok, this was
done, but we cannot wait the moment when everyone will use IPv6. It seems that
it's better not having addresses for everyone than using the new IP version).

I am afraid I missed the point here ... or the meaning ... or both.

Cheers,
Emil


#7

Now you are just trying to hit my buttons... :slight_smile: People that block ICMP for "security" should be repeatably beat about the head with a blunt object. I breaks so many things, including least path and MTU detection... And it gives no security.

And for the record, I do not know of any firewall that disables ICMP by default. None. (Other than those that disable all, and you have to enable by hand.) I do, however, know lots of "hardening scripts" that make troubleshooting a bit of a challenge. Especially the ones with specified source ports, and clients on a NAT box with source port randomization. (Something which actually does increase security, but does mess with SIP)

So to correct your line...

"And no OS can do that if some stupid firewall admin is dropping all ICMP silently... ;)"
And yes, I agree, the admin is stupid. :slight_smile:

But now lets get back to why the CPU goes nuts all the time. :slight_smile:

      Lee

···

On 02/03/2011 01:52 AM, Aleksandar Kostadinov wrote:

And the no OS can do that if some stupid firewall is dropping all ICMP
silently... :wink:


#8

Thanks for your very kind answers.
So, it's not a problem of SC. This is good, I mean only that some people could
not understand it, but I agree there is a lot to do on SC now that implementing
a warning about this has a low priority.
About the point regarding IPv6, the standard points out that packets should be
no fragmented, so the problem will be resolved (but I remember something about
fragmenting IPv6 packets too, I'm not sure...).
Thanks again for the explanations and keep up the good work!

Regards,
Daniel

----- Messaggio originale -----

···

Da: Emil Ivov <emcho@sip-communicator.org>
A: dzmail90-voip@yahoo.it
Cc: "dev@jitsi.java.net" <dev@jitsi.java.net>
Inviato: Gio 3 febbraio 2011, 07:58:19
Oggetto: [jitsi-dev] Re: Re: Firewalls blocking fragmented ip packets

Hey Daniel,

I understand this is frustrating, but, believe it or not, this is not
quite the responsibility of SC/Jitsi. Read on.

На 03.02.11 00:31, dzmail90-voip@yahoo.it написа:

1) Emil, you wrote something about using TCP. So, how to use TCP?

Best case is: your provider supports it and indicates that TCP is the
default transport in the corresponding DNS NAPTR records. In this case
SIP communicator would automatically choose TCP and the user won't be
bothered with it.

If your provider/server does support TCP but has not configured NAPTR
records, then you need to modify your account settings and choose TCP as
the method for connecting to your proxy.

If your provider/server does not support TCP .... there's nothing SC
could do.

What are disadvantages of this method?

None that really matter. UDP is mostly used with SIP for historical
reasons.

2) Does break something using the don't fragment bit in ip packets? If not, SIP

Communicator should use it.

Using the don't fragment bit simply means that your packets will be
dropped rather than fragmented.

3) Trying to discover the path with the maximum MTU allowed could be useful. Is

it implemented?

As Lee pointed out - this is the responsibility of the operating system.
What we could do is show a warning to users when we detect this and tell
them to disable codecs. Given that this is mostly the responsibility of
the provider though I'd have to admit that this would be rather low
priority.

I want only to remark that a lot of people could have this problem, and maybe
they thought about how bad SIP Communicator is. When releasing an 1.0 version
we

should look to the non expert users too, and they will not understand why
firewall is blocking their callings (uh, what is firewall? It's something to
eat?). They expect SIP Communicator (Jitsi) working out-of-the-box, in any
circumstances. We should think about it. Changing something is needed: changing

SIP Communicator, changing SIP protocol,

As it was already said: SIP works with TCP and SC supports it. If your
provider does not: you should address your questions to them :slight_smile:

As for XMPP: the problem simply does not exist. All major providers and
implementations use it with TCP (I am not even sure anyone has ever used
XMPP over UDP for anything else than research and experimentation).

changing IP protocol (ok, this was
done, but we cannot wait the moment when everyone will use IPv6. It seems that

it's better not having addresses for everyone than using the new IP version).

I am afraid I missed the point here ... or the meaning ... or both.

Cheers,
Emil