Netscreen firewall VPN with Asterisk
Juniper NetScreen Rule configurations
5.x has SIP predefined, I defined IAX like this:
set service "IAX2" protocol udp src-port 4569-4569 dst-port 4569-4569 timeout never
Juniper NetScreen VPN Configurations 3/7/2005
I got help from Netscreen.
A little bit about my setup. NS50 on the head end, NS5XT/XP/GT on the remote ends. All the Netscreens perform NAT. The NS50 is on a permanent public IP. The remote ends are on a mix of permanent public IPs, and cable modems behind NAT, so NAT traversal was required. All the NetScreen are on resonably recent ScreenOS 5.something (didn't have the problem with ScreenOS 4 - thanks Netscreen?). I'm evaluating all this using Asterisk Stable 1.0.5. Because we use microsoft products I always have to 'set flow tcp-mss' and 'set flow path-mtu' to get Outlook working.
Changes I had to make:
All the physical interfaces need to have their bandwidth set to something other than 0, preferably same as physical interface speed. I had to remove ALL QOS settings from every policy on the 5XT/XP/GT. On Juniper's recommendation I moved all the VOIP-enabled VPN's to route-based from policy-based.
Policy Settings:
Finally, I needed four policies per device for each bi-directional tunnel (two policies for each direction). One policy is the general VPN policy, allow all, etc. The second policy is set to ignore service SIP - their predefined SIP works just fine.
This seems to be key to getting this all going:
set policy id 10051 from "Untrust" to "Trust" "Remote_addr" "local_addr" "SIP" permit log
set policy id 10051 application "IGNORE"
I think I also had to bump up some screening settings about flooding but I'm not certain now if those were necessary, watch your logs.
Notes:
It was a bear to get it going the first time. I would watch the asterisk console while I made a call to a meetme over the VPN. I would see the call setup occur and the phone would join the meetme but there would be no audio.
Now calls over the VPN work pretty well, occasionally the phones disconnect from the server momentarily from bandwidth lag.
I'm not sure the QOS settings I had in place on the NS50 needed to be removed, but you might want to remove them and add them back after VOIP worked.
Phones that have been tested to work:
- Grandstream Budgetone
- Polycom
- Uniden
- Sipura SPA-841 and ATA 2000
Comments
333SpeedVoIP Debuts VoIP Anti-blocking in Dubai
In today’s market, VoIP for business has become more and more popular and necessary than ever before.
Dubai has become a big market, many big companies need to open branch offices in the UAE allowing more profit and larger market access. Technology Issues become apparent during this process that can cripple communications for that company. The primary communications issues are with VOIP blocking policies implemented in Dubai.
Now, here is the good news, A Canada based company SpeedVoIP with their integral R&D team have work out a new way to solve this VoIP blocking issue. This new system VGCP (VoiceGuard@ Control Protocol) has now laid the path to streamline low cost telephony solutions removing country limitations.
VGCP is a proprietary layer 2 link protocol working at between IP stack and NIC driver for VoIP anti-blocking. The core patent-pending VGCP is industry's most state-of-art voice service provider class security protocol whose scalability and flexibility results in not to compromise voice quality and overhead. VGCP controls and monitors full voice signalling and media flow intelligently, meanwhile disguises sip and RTP packets into normal allowed data packets such as DNS and TFTP, and makes two-way encryption and decryption driven by user-customized policy. VGCP is fully transparent to upper SIP proxy or UA which means VoiceGuard@ can work with any 3rd party soft phone/ATA/Gateway/IP Phone/IADs and SIP Proxy or Server not like some competitors which take effect on their own device and soft switch.
Korea Telecom has implemented this solution successfully for more than one year. And it has been operational within a group of Dubai companies. The trials and implementations proves that, The VGCP solution is the best solution to solve the VoIP Blocking issue and provides stable communications platforms providing an indispensable part of the business network.
Andy Wong ~ ~
MSN: andywong-01@hotmail.com
Email: xd.wong@speed-voip.com
www.speed-voip.com
333IGNORE SIP and src-port
The reason the port would be 1241 for example would be if someone else was already using that source port (two phones). If you look at the default SIP definition in the NS, the src port is 1-65535. SIP is not really defined by a source port, only destination. As per above where they defined IAX2 to be src and destination of 4569 will work fine if neither side is behind NAT, but will fail if the the source is nat'd.
The IGNORE of SIP is specifically useful if you have a VPN where you are allowing "everything" thru anyhow, there is no need for the NS to be "watching" the SIP packets at the application layer to see what RTP ports to open, cause they are already open.
~tommy
333Netscreen re-writing ports -- causing registration probs
333why the IGNORE of SIP