Tom Eastep wrote: >From the list it is clear that some >people find that the SIP helpers actuall break VOIP (See Shorewall FAQ >77) while others claim that the SIP helpers are essential
Indeed - and not just with Linux devices either as SIP ALGs (Application Level Gateways) are appearing in more and more stuff now. There are two issues - one which you mention. The other part of the equation is that if you embed your local address as (say) 192.168.1.57 - the remote end will try and send packets to that address but they'll be dropped fairly quickly and never reach you. So the second part of the ALG is to fiddle with the contents of the packet and alter the address/port to suit. Personally, I prefer to disable ALGs as my experience suggest they cause more problems than they solve. For one thing, in the general case it is simply not possible for a SIP ALG to know the full topology of the entire network and it's not possible to correctly alter the packet content in all cases. The other problem is that they can sometimes have false positives and erroneously alter packets they shouldn't - this being one of the FAQs for at least one torrent application ! My preference is to use devices that can determine their public IP and the type of NAT via STUN and then craft the correct packets in the first place. That breaks on devices designed by clueless f***wits who think forcing randomisation of port mapping is a good idea - with the attitude that they don't care if it doesn't work, at least you are safe ! Yes, there is a popular and well known vendor of network equipment (both consumer and pro) that does just that, and has just that attitude. For SIP, the requirement to open up the corresponding ports isn't normally an issue. The audio is carried by UDP packets, and so when the device at one end starts sending it's packets, that inherently opens up the corresponding inbound connection for packets from the other end. You may lose a few packets until this happens, but that's just a very short pause on the beginning of a phone call. Alternatively, it's more admin but also more reliable to statically configure everything. Manually configure each SIP device to use a different port for it's SIP traffic, and a different port range for it's RTP traffic. Configure them with knowledge of their public IP, and manually configure your firewall with all the corresponding NAT mappings. What definitely doesn't work is top mix techniques. If your device does STUN and your gateway has a SIP ALG - then your correct packets sent by the device will be mangled by the ALG. There is a very real reason why SIP embeds IP address/port information in the packets. Unlike most protocols, the device doing the call setup/control is not required to be the same device that is the source or sink of any of the actual call content. Ie, it's perfectly legal for two VOIP phones to send the audio stream directly to each other with no intermediate call routing system. The "PBX" merely controls the calls and passes information to each endpoint on the progress of call setup and where each device needs to send it's media stream. Few systems are setup like this for the simple reason that it's completely borked by NAT. Leading to ... <mounts soapbox> The real answer is to persuade the world and his dog that NAT == Broken. By definition, NAT breaks rule 1 of IP connectivity that requires every device to have a globally unique and routeable address. If only as much effort was put into making IPv6 as ubiquitous as IPv4 as is put into trying to work round (eg writing ALGs to put into NAT gateways) the fundamental breakage of NAT then I think IPv6 would be a lot further on than it is. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
