Shorewall users - Oct 2007 - How do I configure shorewall to work with VoIP SIP?

Kenneth Burgener wrote:
>I am experiencing a problem getting my home firewall to work with my
>BroadVoice VoIP connection.  I use the Sipura SPA-2100 ATA (Analog
>Telephone Adapter) that came with my BroadVoice account.  This happened
>when I tried to replace my Linksys WRT54G Wireless-G Broadband Router
>with a Linux Shorewall Firewall.
>
>My initial setup was this:
>
>Internet <-> Comcast Modem <-> *Linksys Router* <-> Sipra
ATA
>
>I want to swap the Linksys Router with a Linux Shorewall Firewall like this:
>
>Internet <-> Comcast Modem <-> *Linux Shorewall* <->
Switch <-> Sipra ATA
>
>I used the most basic Shorewall configuration, and my internal PCs can
>access outbound, and the DNATed traffic (HTTP) can find its way in fine.
>
>The symptoms I am experiencing are:
>1. I can make a call inbound or outbound to my cell phone, and either
>phone rings.
>2. If I dial out from my home phone to my cell phone I can hear audio
>from my cell phone on the home phone speaker, but not the other way.
>3. If I dial in from my cell phone, I cannot hear audio from either
>direction.
>
>I watched /var/log/messages, and occasionally I would see a packet
>dropped similar to this:
>
>Oct 27 11:20:56 fw kernel: Shorewall:net2fw:DROP:IN=eth0
OUT>MAC=00:a0:c9:1a:fa:5c:00:01:5c:24:29:c2:08:00 SRC=24.64.26.203
>DST=67.164.192.73 LEN=512 TOS=0x00 PREC=0x20 TTL=66 ID=56131 PROTO=UDP
>SPT=24850 DPT=1028 LEN=492
>
>Oct 27 11:22:49 fw kernel: Shorewall:net2fw:DROP:IN=eth0
OUT>MAC=00:a0:c9:1a:fa:5c:00:01:5c:24:29:c2:08:00 SRC=24.64.52.70
>DST=67.164.192.73 LEN=512 TOS=0x00 PREC=0x20 TTL=64 ID=61945 PROTO=UDP
>SPT=24105 DPT=1026 LEN=492
>
>But I am not even sure these are related, as these dropped packets
don''t
>seem to appear exactly when I think they should.  They seem to appear in
>a regular interval, as maybe some sort of SIP ping?
>
>Any ideas what might be causing this?  Why would it "magically"
work
>with the Linksys Router (I did not specify any port forwarding or port
>triggering to get the Sipra to work).
How is your VoIP adapter configured ?

SIP is a pain to make work with NAT - basically NAT breaks anything 
that embeds IP addresses and/or port numbers in the data. Guess what 
SIP does ?

It could be that the Linksys has  SIP helper built in. A helper will 
examine the contents of certain traffic, and fiddle with the data to 
make things work. For example, the phone says it is at address 
10.10.10.225 (I''m guessing that''s the address from your rules
file)
which isn''t the public address it can be found at. So the helper 
changes that to the public address before sending the packet out to 
the SIP registrar.

Alternatively, the phone is using something like STUN (Simple 
Traversal of UDP through NAT) which uses an external server to 
determine what the network looks like.

Or, the phone could be using uPNP to have the router setup the right 
port forwards for it without you knowing. My personal opinion is that 
uPNP is fundamentally incompatible with a secure network as it allows 
any device to make itself publicly accessible from the internet !

Or you are using a NAT proxy which ignores what the phone says is 
it''s address & port(s) and just looks at the packet headers to work
that out.

Lastly it''s possible to manually configure everything, but
you''ve
said that isn''t the case.



You may or may not have a SIP helper module - I believe it comes as 
an option with later kernels. Having a SIP helper in place when the 
phone is doing it''s own thing (eg by STUN) will break things.

If you don''t have a SIP helper, then STUN should work very nicely.

I don''t think your Linux box will be running uPNP



I tend to configure SIP devices in one of two ways :

1) Don''t do anything special in the firewall, and let the phone work 
it out by using STUN. STUN will allow it to figure out the public 
address, port mapping, and what type of NAT is present. The way Linux 
handles this is fairly STUN friendly. The phone does not need to be 
at a fixed address, and your internet connection can also be dynamic.

2) If you have a static public address, and configure your phone at a 
static address, manually forward the ports used (5060 for the SIP, 
and some other ports for RTP) to the phone. You will need to tell the 
phone it''s public address so it can use the public address in SIP 
messages - the ones I''ve used allow this.

Ports used will be UDP 5060 for SIP (unless you change it), and some 
other ports for RTP. There is no standard (10001-20000 are used by 
Asterisk), so look in the phone config to see what it''s configured 
for. Open up a block of four ports starting at the base port 
specified for RTP - the phone may need more than one channel 
available if you use any features like transfer or conferencing.


Also, in case there is a SIP helper lurking somewhere, try running 
the phone on a different port (eg 5061) which will bypass the helper.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Hello,

Let me first start by saying Shorewall is awesome, and I use it
everywhere from single box firewall, to home network firewall, even to
our corporate firewall.

I am experiencing a problem getting my home firewall to work with my
BroadVoice VoIP connection.  I use the Sipura SPA-2100 ATA (Analog
Telephone Adapter) that came with my BroadVoice account.  This happened
when I tried to replace my Linksys WRT54G Wireless-G Broadband Router
with a Linux Shorewall Firewall.

My initial setup was this:

Internet <-> Comcast Modem <-> *Linksys Router* <-> Sipra ATA

I want to swap the Linksys Router with a Linux Shorewall Firewall like this:

Internet <-> Comcast Modem <-> *Linux Shorewall* <-> Switch
<-> Sipra ATA

I used the most basic Shorewall configuration, and my internal PCs can
access outbound, and the DNATed traffic (HTTP) can find its way in fine.

The symptoms I am experiencing are:
1. I can make a call inbound or outbound to my cell phone, and either
phone rings.
2. If I dial out from my home phone to my cell phone I can hear audio
from my cell phone on the home phone speaker, but not the other way.
3. If I dial in from my cell phone, I cannot hear audio from either
direction.

I watched /var/log/messages, and occasionally I would see a packet
dropped similar to this:

Oct 27 11:20:56 fw kernel: Shorewall:net2fw:DROP:IN=eth0
OUTMAC=00:a0:c9:1a:fa:5c:00:01:5c:24:29:c2:08:00 SRC=24.64.26.203
DST=67.164.192.73 LEN=512 TOS=0x00 PREC=0x20 TTL=66 ID=56131 PROTO=UDP
SPT=24850 DPT=1028 LEN=492

Oct 27 11:22:49 fw kernel: Shorewall:net2fw:DROP:IN=eth0
OUTMAC=00:a0:c9:1a:fa:5c:00:01:5c:24:29:c2:08:00 SRC=24.64.52.70
DST=67.164.192.73 LEN=512 TOS=0x00 PREC=0x20 TTL=64 ID=61945 PROTO=UDP
SPT=24105 DPT=1026 LEN=492

But I am not even sure these are related, as these dropped packets
don''t
seem to appear exactly when I think they should.  They seem to appear in
a regular interval, as maybe some sort of SIP ping?

Any ideas what might be causing this?  Why would it "magically" work
with the Linksys Router (I did not specify any port forwarding or port
triggering to get the Sipra to work).

Configuration files are below...

Thank you in advance,
Kenneth Burgener



/zones
fw      firewall
net     ipv4
lan     ipv4

/interfaces
net     eth0            detect          routefilter,norfc1918,tcpflags
lan     eth1            detect          tcpflags

/masq
eth0                    eth1

/policy
# Yes I know these are accepting too much, but I am trying anything to
get this to work
lan             net             ACCEPT
lan             $FW             ACCEPT
$FW             lan             ACCEPT
$FW             net             ACCEPT
net             all             DROP            info
all             all             REJECT          info

/rules
ACCEPT         net             $FW             tcp     ssh
#
# Web traffic
DNAT            net     lan:10.10.10.3          tcp     80
#
# DESPERATE ATTEMPT #1 - DID NOT WORK
# Allow IAX2, SIP and RTP To Firewall
#DNAT            net     lan:10.10.10.225        udp    
4569,5060,10000:20000
#
# MORE DESPERATE ATTEMPT #2 - DID NOT WORK
# FORWARD *ALL* TRAFFIC
#DNAT           net     lan:10.10.10.225        udp     0:65535
#DNAT           net     lan:10.10.10.225        tcp     0:65535


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Tue, Oct 30, 2007 at 04:45:41PM -0600, Kenneth Burgener
wrote:
> Hello,
> 
> Let me first start by saying Shorewall is awesome, and I use it
> everywhere from single box firewall, to home network firewall, even to
> our corporate firewall.
> 
Welcome to the world of Shorewall :-)
> I am experiencing a problem getting my home firewall to work with my
> BroadVoice VoIP connection.  I use the Sipura SPA-2100 ATA (Analog
> Telephone Adapter) that came with my BroadVoice account.  This happened
> when I tried to replace my Linksys WRT54G Wireless-G Broadband Router
> with a Linux Shorewall Firewall.
> 
> My initial setup was this:
> 
> Internet <-> Comcast Modem <-> *Linksys Router* <-> Sipra
ATA
> 
> I want to swap the Linksys Router with a Linux Shorewall Firewall like
this:
> 
> Internet <-> Comcast Modem <-> *Linux Shorewall* <->
Switch <-> Sipra ATA
> 
> I used the most basic Shorewall configuration, and my internal PCs can
> access outbound, and the DNATed traffic (HTTP) can find its way in fine.
> 
OK.  That is good.
> The symptoms I am experiencing are:
> 1. I can make a call inbound or outbound to my cell phone, and either
> phone rings.
> 2. If I dial out from my home phone to my cell phone I can hear audio
> from my cell phone on the home phone speaker, but not the other way.
> 3. If I dial in from my cell phone, I cannot hear audio from either
> direction.
> 
> I watched /var/log/messages, and occasionally I would see a packet
> dropped similar to this:
> 
> Oct 27 11:20:56 fw kernel: Shorewall:net2fw:DROP:IN=eth0 OUT>
MAC=00:a0:c9:1a:fa:5c:00:01:5c:24:29:c2:08:00 SRC=24.64.26.203
> DST=67.164.192.73 LEN=512 TOS=0x00 PREC=0x20 TTL=66 ID=56131 PROTO=UDP
> SPT=24850 DPT=1028 LEN=492
> 
> Oct 27 11:22:49 fw kernel: Shorewall:net2fw:DROP:IN=eth0 OUT>
MAC=00:a0:c9:1a:fa:5c:00:01:5c:24:29:c2:08:00 SRC=24.64.52.70
> DST=67.164.192.73 LEN=512 TOS=0x00 PREC=0x20 TTL=64 ID=61945 PROTO=UDP
> SPT=24105 DPT=1026 LEN=492
> 
I doubt that these packets are related.  That is, unless your call is
going to/from someone in China:

$ host 24.64.52.70
70.52.64.24.in-addr.arpa domain name pointer S0106000f3d65d525.cn.shawcable.net.
> But I am not even sure these are related, as these dropped packets
don''t
> seem to appear exactly when I think they should.  They seem to appear in
> a regular interval, as maybe some sort of SIP ping?
> 
> Any ideas what might be causing this?  Why would it "magically"
work
> with the Linksys Router (I did not specify any port forwarding or port
> triggering to get the Sipra to work).
> 
> 
Hmm.
> 
> /zones
> fw      firewall
> net     ipv4
> lan     ipv4
> 
> /interfaces
> net     eth0            detect          routefilter,norfc1918,tcpflags
> lan     eth1            detect          tcpflags
> 
> /masq
> eth0                    eth1
> 
> /policy
> # Yes I know these are accepting too much, but I am trying anything to
> get this to work
> lan             net             ACCEPT
> lan             $FW             ACCEPT
> $FW             lan             ACCEPT
> $FW             net             ACCEPT
> net             all             DROP            info
> all             all             REJECT          info
> 
> /rules
> ACCEPT         net             $FW             tcp     ssh
> #
> # Web traffic
> DNAT            net     lan:10.10.10.3          tcp     80
> #
> # DESPERATE ATTEMPT #1 - DID NOT WORK
> # Allow IAX2, SIP and RTP To Firewall
> #DNAT            net     lan:10.10.10.225        udp    
> 4569,5060,10000:20000
> #
> # MORE DESPERATE ATTEMPT #2 - DID NOT WORK
> # FORWARD *ALL* TRAFFIC
> #DNAT           net     lan:10.10.10.225        udp     0:65535
> #DNAT           net     lan:10.10.10.225        tcp     0:65535
> 
Start here: http://www.shorewall.net/troubleshoot.htm

If you still have problems: http://www.shorewall.net/support.htm

Be sure and include a ''shorewall dump'' in your next message.

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Tue, Oct 30, 2007 at 04:45:41PM -0600, Kenneth Burgener
wrote:
> I use the Sipura SPA-2100 ATA (Analog
> Telephone Adapter) that came with my BroadVoice account.
This is a SIP device, and you probably have the SIP NAT problem - the
problem being that SIP is a stupid protocol. Adding the
nf_conntrack_sip module to your kernel should work around it.
> Any ideas what might be causing this?  Why would it "magically"
work
> with the Linksys Router (I did not specify any port forwarding or port
> triggering to get the Sipra to work).
Presence of the same workaround in the device''s firmware.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Andrew Suffield wrote:
> On Tue, Oct 30, 2007 at 04:45:41PM -0600, Kenneth Burgener wrote:
>> I use the Sipura SPA-2100 ATA (Analog
>> Telephone Adapter) that came with my BroadVoice account.
> 
> This is a SIP device, and you probably have the SIP NAT problem - the
> problem being that SIP is a stupid protocol. Adding the
> nf_conntrack_sip module to your kernel should work around it.

I have an ip_conntrack_sip module already loaded, but I do not see
mention of an nf_conntrack_sip module:

[root@fw ~]# lsmod | grep sip
ip_nat_sip              8129  0
ip_conntrack_sip       11313  1 ip_nat_sip
ip_nat                 20973  12
ipt_SAME,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ip_nat_tftp,ip_nat_sip,ip_nat_pptp,ip_nat_irc,ip_nat_h323,ip_nat_ftp,ip_nat_amanda,iptable_nat
ip_conntrack           53153  24
ipt_MASQUERADE,ip_nat_tftp,ip_nat_snmp_basic,ip_nat_sip,ip_nat_pptp,ip_nat_irc,ip_nat_h323,ip_nat_ftp,ip_nat_amanda,ip_conntrack_tftp,ip_conntrack_sip,ip_conntrack_pptp,ip_conntrack_netbios_ns,ip_conntrack_irc,ip_conntrack_h323,ip_conntrack_ftp,ip_conntrack_amanda,xt_helper,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state,iptable_nat,ip_nat

[root@fw ~]# modprobe nf_conntrack_sip
FATAL: Module nf_conntrack_sip not found.




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Kenneth Burgener wrote:
>  > This is a SIP device, and you probably have the SIP NAT problem - the
>>  problem being that SIP is a stupid protocol.
<rant>On a matter of personal opinion, it''s not the SIP
that''s
stupid, it works ''just fine'' on an unbroken network ! Where
NAT is
involved, the network is fundamentally broken and there are no 
workarounds for what it does that are 100% reliable - all that can be 
said is that it works ''well enough'' for enough people enough
of the
time for people to be fooled into thinking it''s a good idea. 
Meanwhile, by ''fixing'' the problem of available addresses,
it''s
delayed the uptake of IPv6 by many, many years and thus delayed for 
many years to come the real solution to a lack of addresses. Bear in 
mind that I''ve yet to see a SIP device that supports IPv6 so
we''re
now stuck with the problem even if every ISP in the world turned on 
IPv6 today.</rant>
>  Adding the
>>  nf_conntrack_sip module to your kernel should work around it.
>
>I have an ip_conntrack_sip module already loaded, but I do not see
>mention of an nf_conntrack_sip module:
That could well be the problem then.

My guess is that the phone device is doing STUN or something to find 
out what address & ports to use in the SIP messages - then the SIP 
helper mangles the packet and breaks things.

Try :

1) Don''t load the ip_conntrack_sip module

2) Reconfigure the phone to not do network detection (typically turn off STUN)

3) Reconfigure the phone to use a different port (eg 5061) so that 
the SIP helper doesn''t kick in.

1 & 3 are avoiding the gateway doing anything to the packets, 2 is 
stopping the phone correcting for the NAT and letting the gateway do 
it.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Kenneth Burgener wrote:
>Andrew Suffield wrote:
>>  I subscribe only to the "NAT is awkward" school, not the
"NAT is evil"
>>  one, but SIP''s a pretty stupid protocol even without NAT.
There''s just
>>  no good excuse for the way it scatters traffic through unrelated ports
>>  - it would have worked just as well if it had used only one port. Even
>>  without NAT, it''s a nuisance for stateful firewalls.
>
>Good thing there is IAX!

At the risk of starting a war ...

SIP does stuff that IAX can''t - specifically, SIP was designed to 
have the data and control as separate channels. That way, your 
registrar/pbx/whatever you want to call it does NOT have to also pass 
all the traffic. Eg, you can have your control in one places, but the 
voice (or video, or ...) traffic does not have to go through it.

I would see this as essential if (for example) deploying VoIP across 
a WAN with limited bandwidth. It would allow you to have calls 
between people in the same office NOT traversing the WAN, or to have 
calls between people in two offices not having to go via the main 
site. All this without having an exchange in each site.


With IAX2, there is only one route the data can go - and that''s 
to/from the box doing the control.

Don''t forget that it''s quite possible for there to be more
than one
call routing device between end users - eg phone a could be logged 
into one VoIP provider, while phone b is logged into another, and in 
between the two providers have peered by going through a third. So 
the call setup control in this case could well go through three 
providers, while the voice/video/whatever data need only go direct 
between end users.


Remove NAT and SIP works quite well - even through firewalls as long 
as each end will allow outbound traffic and the corresponding inbound 
traffic. The outbound traffic from phone a to phone b will open up 
the firewall at a, while the outbound traffic from b to a will open 
up the firewall at b. After the first two packets are exchanged, the 
link is complete and voice will flow.

As long as both firewall can a) cope with the concept of "udp traffic 
is flowing (or did so very recently) = connection in use" and b) only 
allow traffic from the outside that is the exact reverse path for an 
outbound flow, then there is little security risk.


What screws it up bigtime is phone a being told to talk to phone b at 
192.168.27.5:8003 !


That''s my 2d anyway.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Tue, Oct 30, 2007 at 10:03:46PM -0600, Kenneth Burgener
wrote:
> Andrew Suffield wrote:
> > On Tue, Oct 30, 2007 at 04:45:41PM -0600, Kenneth Burgener wrote:
> >> I use the Sipura SPA-2100 ATA (Analog
> >> Telephone Adapter) that came with my BroadVoice account.
> > 
> > This is a SIP device, and you probably have the SIP NAT problem - the
> > problem being that SIP is a stupid protocol. Adding the
> > nf_conntrack_sip module to your kernel should work around it.
> 
> 
> I have an ip_conntrack_sip module already loaded, but I do not see
> mention of an nf_conntrack_sip module:
Same thing, they changed the name. You must have the slightly less
common configuration where the SIP device implements the workaround.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Wed, Oct 31, 2007 at 07:55:28AM +0100, Simon Hobson
wrote:
> 
> >  > This is a SIP device, and you probably have the SIP NAT problem
- the
> >>  problem being that SIP is a stupid protocol.
> 
> <rant>On a matter of personal opinion, it''s not the SIP
that''s
> stupid, it works ''just fine'' on an unbroken network !
Where NAT is
> involved, the network is fundamentally broken and there are no 
> workarounds for what it does that are 100% reliable - all that can be 
> said is that it works ''well enough'' for enough people
enough of the
> time for people to be fooled into thinking it''s a good idea. 
> Meanwhile, by ''fixing'' the problem of available
addresses, it''s
> delayed the uptake of IPv6 by many, many years and thus delayed for 
> many years to come the real solution to a lack of addresses. Bear in 
> mind that I''ve yet to see a SIP device that supports IPv6 so
we''re
> now stuck with the problem even if every ISP in the world turned on 
> IPv6 today.</rant>
I subscribe only to the "NAT is awkward" school, not the "NAT is
evil"
one, but SIP''s a pretty stupid protocol even without NAT.
There''s just
no good excuse for the way it scatters traffic through unrelated ports
- it would have worked just as well if it had used only one port. Even
without NAT, it''s a nuisance for stateful firewalls.

Also, I have to work with a hardware PBX that scatters the SIP control
and audio streams through different IP addresses, and that''s just
inexcusable.
> My guess is that the phone device is doing STUN or something to find 
> out what address & ports to use in the SIP messages - then the SIP 
> helper mangles the packet and breaks things.
That''s not the default configuration for this device, so it
wasn''t my
first guess, but with this extra information it seems likely.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Andrew Suffield wrote:
> I subscribe only to the "NAT is awkward" school, not the
"NAT is evil"
> one, but SIP''s a pretty stupid protocol even without NAT.
There''s just
> no good excuse for the way it scatters traffic through unrelated ports
> - it would have worked just as well if it had used only one port. Even
> without NAT, it''s a nuisance for stateful firewalls.

Good thing there is IAX!


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Wed, Oct 31, 2007 at 04:56:54PM +0100, Simon Hobson
wrote:
> SIP does stuff that IAX can''t - specifically, SIP was designed to 
> have the data and control as separate channels. That way, your 
> registrar/pbx/whatever you want to call it does NOT have to also pass 
> all the traffic. Eg, you can have your control in one places, but the 
> voice (or video, or ...) traffic does not have to go through it.
> 
> I would see this as essential if (for example) deploying VoIP across 
> a WAN with limited bandwidth. It would allow you to have calls 
> between people in the same office NOT traversing the WAN, or to have 
> calls between people in two offices not having to go via the main 
> site. All this without having an exchange in each site.
This feature is not related to SIP''s port scattering. It''s
called a
"reinvite", and what happens is:

Phone A contacts the PBX, and sends a message asking to set up a call
to a given extension.

The PBX says "Here''s the IP address of your target. Go away."

Phone A contacts the given IP address, which is the address of phone
B, and sends another message asking to set up a call. It then proceeds
as if phone A was given that address by the user in the first place,
and the PBX is no longer involved.

The entire control layer is transferred - you don''t have control going
to the PBX and audio going to the target phone. There''s no reason why
IAX couldn''t do the same thing (although offhand I don''t know
if it
does).
> Remove NAT and SIP works quite well - even through firewalls as long
> as each end will allow outbound traffic and the corresponding
> inbound traffic. The outbound traffic from phone a to phone b will
> open up the firewall at a, while the outbound traffic from b to a
> will open up the firewall at b. After the first two packets are
> exchanged, the link is complete and voice will flow.
It ''works'' FSVO ''works''. The problem is
phones that implement
silence-suppression: until both ends have generated noise, there are
no first two packets, so the whole thing just sits there. This gives
you a round of "Hello? Hello? Can you hear me?" at the start of each
call. You have to configure the firewall to explicitly pass the
inbound audio channel just to work around this.


But this is meandering offtopic, so I''ll leave it there.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenneth Burgener wrote:
> Andrew Suffield wrote:
>> On Tue, Oct 30, 2007 at 04:45:41PM -0600, Kenneth Burgener wrote:
>>> I use the Sipura SPA-2100 ATA (Analog
>>> Telephone Adapter) that came with my BroadVoice account.
>> This is a SIP device, and you probably have the SIP NAT problem - the
>> problem being that SIP is a stupid protocol. Adding the
>> nf_conntrack_sip module to your kernel should work around it.
> 
> 
> I have an ip_conntrack_sip module already loaded, but I do not see
> mention of an nf_conntrack_sip module:
On the flip side, note that we''ve seen cases where loading
ip_conntrack_sip has actually _broken_ working SIP installations.

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHKOUsO/MAbZfjDLIRArHRAJ9YSimpCQAFc7G7ixIe/EK7aG7HVgCfYF4b
WDM2xQu85rxTiKQDVVZJMMg=u34X
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Tom Eastep wrote:
> On the flip side, note that we''ve seen cases where loading
> ip_conntrack_sip has actually _broken_ working SIP installations.
> 
> -Tom


How do I no load ip_conntrack_sip?  I didn''t manually load it in the
first place.  I assume it is either built into the OS to auto load, or
shorewall is loading the module.

I tried a
 $ modprobe -r ip_conntrack_sip

which appears to have unloaded the module, but then my network
connection stopped working.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Kenneth Burgener wrote:
> Tom Eastep wrote:
>> On the flip side, note that we''ve seen cases where loading
>> ip_conntrack_sip has actually _broken_ working SIP installations.
>>
>> -Tom
> 
> 
> 
> How do I no load ip_conntrack_sip?  I didn''t manually load it in
the
> first place.  I assume it is either built into the OS to auto load, or
> shorewall is loading the module.
> 
> I tried a
>  $ modprobe -r ip_conntrack_sip
> 
> which appears to have unloaded the module, but then my network
> connection stopped working.
Shorewall FAQ 59.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Oct 31, 2007, at 3:27 PM, Tom Eastep wrote:
>
> On the flip side, note that we''ve seen cases where loading
> ip_conntrack_sip has actually _broken_ working SIP installations.

That reminds me..

To work around the ip_nat_sip problem, I first appended ''rmmod ip_nat  
sip &> /dev/null'' to our start file.  It was a great solution,
or so I
thought, because it didn''t require modification of anything outside  
of /etc/shorewall and survived shorewall upgrades performed via yum  
update.

Then one day, the problem mysteriously returned and I discovered that  
someone had issued a ''shorewall check'' on the router, which
had loaded
the ip_nat_sip module but did not ran the start file.  I understand  
that shorewall check should not run the start file, but is it  
necessary that it loads the modules file?  It seems that something  
like shorewall check should produce no side effects.

-Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Brian Camp wrote:
> I understand  
> that shorewall check should not run the start file, but is it  
> necessary that it loads the modules file?  It seems that something  
> like shorewall check should produce no side effects.
The ''check'' command validates the configuration against the
capabilities
of iptables and the kernel. It can''t do that without loading the
necessary modules.

Would you rather have ''shorewall start'' fail after a
successful ''check''
when the required modules aren''t available? I think not...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Brian Camp wrote:
> On Oct 31, 2007, at 3:27 PM, Tom Eastep wrote:
> 
>> On the flip side, note that we''ve seen cases where loading
>> ip_conntrack_sip has actually _broken_ working SIP installations.
> 
> That reminds me..
> 
> To work around the ip_nat_sip problem, I first appended ''rmmod
ip_nat
> sip &> /dev/null'' to our start file.  It was a great
solution, or so I
> thought, because it didn''t require modification of anything
outside
> of /etc/shorewall and survived shorewall upgrades performed via yum  
> update.

Brian,

I like your solution and I will be trying it with my phone tonight.

I am curious if you also removed "ip_conntrack_sip"?  Did you also do
a
DNAT forward of ports "4569,5060,10000:20000"?

Thanks,
Kenneth

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Problem fixed, see below...

Brian Camp wrote:
> On Oct 31, 2007, at 3:27 PM, Tom Eastep wrote:
> 
>> On the flip side, note that we''ve seen cases where loading
>> ip_conntrack_sip has actually _broken_ working SIP installations.
> 
> That reminds me..
> 
> To work around the ip_nat_sip problem, I first appended ''rmmod
ip_nat
> sip &> /dev/null'' to our start file.  It was a great
solution, or so I
> thought, because it didn''t require modification of anything
outside
> of /etc/shorewall and survived shorewall upgrades performed via yum  
> update.


I just wanted to let those that have been following this issue, or come
across this problem in the future, know that this solution fixed the
problem.  I am now able to make inbound and outbound calls.

It looks like the good people at Broadvoice setup the Sipura device to
work around NAT, and shorewall (sip connection tracking to be specific),
trying to be helpful, worked against this.

All I did to solve this problem is add the following lines to my
/etc/shorewall/start file:

 rmmod ip_nat_sip &> /dev/null
 rmmod ip_conntrack_sip &> /dev/null

I did no port forwarding, or any other fancy stuff.


Thanks everyone,
Kenneth

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Indeed,

It should be posted somewhere in big and in bold: if you''re using a SIP
device within your private network, and you have its NAT capabilities
turned-on, make sure to disable the SIP-NAT capabilities on the firewall.

It''s a common problem with a lot of firewall products out there that do
SIP
rewriting in order to make the protocol ''nat friendly''.

Depending on the implementation used with iptables (ip_conntrack_sip),  it
may be  better to use the onboard nat features of your SIP ATA/phone because
features like SIP REINVITE (peer-to-peer streaming), don''t always work
quite
well with firewall-based implementations and you may encounter situations
where the caller hears you, but you don''t hear him, or vice-versa.

Kris

On 11/10/07, Kenneth Burgener <kenneth@mail1.ttak.org>
wrote:
>
> Problem fixed, see below...
>
> Brian Camp wrote:
> > On Oct 31, 2007, at 3:27 PM, Tom Eastep wrote:
> >
> >> On the flip side, note that we''ve seen cases where
loading
> >> ip_conntrack_sip has actually _broken_ working SIP installations.
> >
> > That reminds me..
> >
> > To work around the ip_nat_sip problem, I first appended
''rmmod ip_nat
> > sip &> /dev/null'' to our start file.  It was a great
solution, or so I
> > thought, because it didn''t require modification of anything
outside
> > of /etc/shorewall and survived shorewall upgrades performed via yum
> > update.
>
>
>
> I just wanted to let those that have been following this issue, or come
> across this problem in the future, know that this solution fixed the
> problem.  I am now able to make inbound and outbound calls.
>
> It looks like the good people at Broadvoice setup the Sipura device to
> work around NAT, and shorewall (sip connection tracking to be specific),
> trying to be helpful, worked against this.
>
> All I did to solve this problem is add the following lines to my
> /etc/shorewall/start file:
>
> rmmod ip_nat_sip &> /dev/null
> rmmod ip_conntrack_sip &> /dev/null
>
> I did no port forwarding, or any other fancy stuff.
>
>
> Thanks everyone,
> Kenneth
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/