[ previous ] [ next ] [ threads ]
 From:  <Kamil dot Wencel at hvbpensionsfonds dot de>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  AW: [m0n0wall] SIP wierdness?
 Date:  Tue, 16 Aug 2005 16:05:03 +0200
my guess is that you have registered with some external SIP provider or you
have softphones / another asterisk box registered with the asterisk box.
asterisk keeps that connections alive, so the state doesn't change in the 
state table of your m0n0 until THIS connection is reset. 
so - nothing to worry about here.

-----Ursprüngliche Nachricht-----
Von: Chris Buechler [mailto:cbuechler at gmail dot com]
Gesendet: Samstag, 13. August 2005 19:48
Cc: m0n0wall at lists dot m0n0 dot ch
Betreff: Re: [m0n0wall] SIP wierdness?

On 8/12/05, Chris Bagnall <m0n0wall at minotaur dot cc> wrote:
> I've been doing some research this evening whilst trying to get SIP working
> reliably over NAT through a client's asterisk server. The aim was to try and
> work out exactly how wide a port range needs to be open for enough RTP
> streams for their needs.
> Whilst playing around with different port ranges I noticed that disabling a
> firewall rule and hitting apply doesn't appear to disable it immediately.
> If, for example, I kill the rule allowing port 5060 inbound (SIP), it stands
> to reason I shouldn't be able to make any inbound calls successfully. This
> isn't the case - inbound calls work perfectly despite the rule not being
> present.
> Any idea what's causing this? 

my guess would be the state table, as removing a rule doesn't remove
any existing states for that rule.  Though I would think a new
connection would attempt to create a new state, I'm not familiar at
all with SIP so I don't know.

> I note that if I do the same thing, to for example, a webserver (firewall
> allowing port 80 inbound), it stops working from the outside immediately.

Because a HTTP request will have to create a new connection, and hence
state, every time.  If someone was downloading a file from you via
HTTP and you disabled the rule, it wouldn't cut off that session

> (oh, if anyone can answer the original point of all this - how wide an RTP
> range does one need - I'd be most grateful)

not a clue, sorry.  :)


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