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/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
