[ previous ] [ next ] [ threads ]
 From:  "Soren Vanggaard Jensen" <svanggaard at hotmail dot com>
 To:  Matthias dot Kessler at RZ dot Uni dash Augsburg dot DE
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] SIP Problem
 Date:  Thu, 02 Mar 2006 05:38:29 +0000
Hi Matthias,

If the problem is fragmentation i really have no clue on how to handle it. 
It sounds really strange. In my setup i have approx. 15 SIP klients and 5+ 
VoIP providers. I've never seen this problem.

See also 

Please take a look on the MTU settings in you monowall and in your modem if 
any. Set it to default values (typically 1500 for DSL connection, 1492 for 
PPP). This may help.

In general the SIP packages sent btw. the SIP entities should not be 
fragmented since they are really small. Large SIP packages will cause 
degration of audio quality.

Søren Vanggaard Jensen

>From: Matthias Kessler <Matthias dot Kessler at RZ dot Uni dash Augsburg dot DE>
>To: Soren Vanggaard Jensen <svanggaard at hotmail dot com>
>CC: m0n0wall at lists dot m0n0 dot ch
>Subject: Re: [m0n0wall] SIP Problem
>Date: Wed, 01 Mar 2006 23:48:45 +0100
>Hash: SHA1
>Soren Vanggaard Jensen schrieb:
> > Hi Matthias,
>Hello Soren,
>thank you for your help.
> > It's normally quite difficult to do tracing/sniffing on the WAN side of
> > a firewall. So my advice would be to dig into the SIP protocol and
> > understand this instead.
> >
> > I think that your monowall closes inbound ports due to timeouts in the
> > nat translation table. One solution is to do port forwarding to your
> > internal SIP client. However, a lot of effort has been put into
> > devoloping protocols to enable seemless NAT traversal. My advice is that
> > you use these protocols instead.
>I think that there is no timeout problem. I already did port forwarding
>rules for the needed ports but that didn't help.
>Now I think I found the problem. The incoming UDP packets are fragmented
>and only one part gets translated to the local IP address. See here:
>17:20:08.612482 ng0 @0:23 b -> PR udp len
>20 (756) (frag 45742:736@744+) IN
>17:20:08.608072 ng0 @0:23 b -> PR udp len 20
>(143) (frag 45742:123@1480) IN
>(The address is my SIP box)
> > 1) Disable any SIP related portforwarding that you've set up in your
> > firewall -if any.
> > 2) Enable STUN on your SIP client
> > 3) Enable keep-alive packages from your SIP client
>I did this all with no success... Same problem as above!
> > 4) Enable "rport" on your SIP client if possible
> > 5) reset the nat firewall state table (the simple way is to reboot the
> > firewall)
> > 6) Reset your SIP client to force a re-registration
> >
> > Now you should be up and running again. If not, then let me know.
>So do you (or anyone else on this list) know how to handle those
>fragmented packets? A simple "UDP any to any with allow fragmented" did
>not resolve the problem. I already tried this. Is there an option to do
>the NAT after _ALL_ fragments have been received?
>Thank you for the help,
>Version: GnuPG v1.4.2 (MingW32)
>Comment: GnuPT 2.5.5 by EQUIPMENTE.DE
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch