On 04/12/2011 08:15 PM, Simon Hobson wrote:
> [email protected] wrote:
>
>> I'm using Shorewall 4.0.6 on a Debian Etch server with kernel 2.6.24.
>> The server is running asterisk 1.6 with few IP Phones registered to the
>> asterisk, on the internal Interface eth0. The server has indeed a public
>> interface eth1 used by asterisk to connect to external SIP providers.
>> Now, I simply can't prevent an external IP Phone from registering on my
>> asterisk on interface eth1.
>> I tried to stop the UDP traffic with this rule (rules file):
>>
>> DROP  net:XX.XX.XX.XX      fw      udp     1024:65535
>>
>> Where XX.XX.XX.XX is the public ip addres of the IP Phone. How could it be?
>>
>> The interface file looks like:
>>
>> net     eth1            detect          tcpflags,nosmurfs
>> loc     eth0            detect          tcpflags,nosmurfs
>>
>> The policy file looks like:
>>
>> $FW             all             ACCEPT
>> net             $FW             DROP            info
>> net             loc             DROP            info
>> net             all             DROP            info
>> all             all             REJECT          info
> Firstly, you only need to block port 5060 to stop SIP (assuming you
> aren't running a non-standard port). Also be aware that SIP can use
> TCP as well as UDP.
Yep, you are right. But I like to drop all the SIP (and RTP) traffic ;)

> But I see that your policies will drop the traffic anyway, so a drop
> rule is redundant.
>
> As Tom has already pointed out, if the phone had a connection active
> before you invoked the firewall then that connection will remain
> open. Also check your rules file for anything that might be
> explicitly permitting the traffic.
>
> Lastly, check that you don't have anything configured on your
> Asterisk setup that might be sending outbound SIP packets to the
> device - that would be enough to create an open connection which
> would permit inbound traffic as well.
>
You are right again. I have some some external account registered to 
voip providers and generating udp traffic of course. Now I understand 
where I was wrong!
Thanks again!

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to