VoIP problem

[#1]

Hi all I have a Quintum Technologies VoIP system. It uses H323 and a plethora of UDP/TCP ports. It used to be behind a Linux with IPTables firewall doing static NAT, now it' s behind a Fortigate-60 doing static NAT. I enabled the very same services that were before, now the system can only make calls, but not receive. So, I modified the policies so that ANY traffic could get in and out of my VoIP system. The problem remains. As far as I know, the Quintum is well configured (it used to work just fine), so the problem should be related to my Fortigate Firewall. Given that I enabled ANY traffic in and out, it probably has something to do with NAT... Any ideas, thoughts, other tests that could be done?

[#2]

[Deleted by Admins]

[#3]

The firewall is blocking UDP ports in NAT mode even when " ANY" is selected as the service type??? That sounds awful Sorry for being repetitive, but are you sure? I almost went crazy with that. Thanks for the info...

[#4]

Nicolas, - Look at the message i posted for VoIP earlier, might give you a clue. http://support.fortinet.com/forum/m.asp?m=6323&p=1&tmode=1&smode=1&key=&language= - I don' t know what the Quintum approach is for VoIP or how they' re technology works. Although i can tell you on Cisco gateways (like Cisco 2621) the call es compound by 2 legs, where the leg back out (answer) is an independent ip data stream originated on the voice gateway receiving the call, and they' re put together again by the call manager who originated the call, usually the VoIP provider. - On my configurations what i usually do is permit ANY between the NATed ip of the voice gateway and the ip ranges of the provider. According to IANA, H323 uses: h323gatedisc 1718/tcp h323gatedisc h323gatedisc 1718/udp h323gatedisc h323gatestat 1719/tcp h323gatestat h323gatestat 1719/udp h323gatestat h323hostcall 1720/tcp h323hostcall h323hostcall 1720/udp h323hostcall - Although I' ve heard of Quintum, I haven' t worked with it before and i don' t know how standard or propietary their technology is. When it comes to voice i' d recommend to use Cisco since they' re been on the VoIP market for longer than other brands. - What is the call setup process on this Quintum boxes? What kind of call manager is it? what kind of client gateways do they use? Maybe there' s some detail you' ve overlooked or something else, it happens sometimes.

[#5]

Quintum uses a bunch of ports to connect. But I insist on the following: I enabled ALL traffic to pass in and out, even then the thing wouldn' t work! So it mustn' t be port-related, right???

[#6]

Hi all, I had exactly the same issue with a Fortigate50A. FGT50A is DSL client with PPPoE. FGT50A WAN IP is static. My company asked me to perform tests on H323 capabilities through the FGT50A. I' ve tried to send H323 calls from many equipments and always the same trouble. The called party hears me but I do not hear it. I' ve tried MultiVoIP from MultiTech, VoiceGateEth from Digicom, Avaya SOE and other gateways. All of these do not work with FGT50A. The problem seems to be due to the NAT. Once Call Setup has been received by the called party, dynamic UDP ports have to be opened and managed in the NAT table of the FGT. These ports are used for Audio packets traffic(RTP) To manage these ports, the FGT needs to " look" into the body of the Q931/H225.0 message. There is a parameter tsapIdentifier which set the port number for the UDP audio exchange. If the router like the FGT50A doesn' t look or doesn' t understand this parameter, it will not be able to open right port and write the correct entry in its NAT table. I hope FGT tech support will provide maint. release will enhance the VoIP pass through feature. If you' ll get info I will pleased to be informed. n.rayner@alliancetelecom.fr

[#7]

Thanks Rainer. As far as I can see then, it' s a problem related to the way the Fortiget manages NAT, isn' t it? Then I hope too this will be addressed soon. How annoying.

[#8]

" Any" service just means standard ports upto 1024.... If your application uses any ports above 1024....then you will have to define it under custom and add it in the rule

[#9]

Yay! How could I know? Thanks for the tip...Thanks a lot.

[#10]

The problem is actually with the H232 protocol. It' s encapsulation does not provide for very sensible NAT positioning. Basically put, it will end up trying to connect back to the _private_ ip space on the nat side of the firewall.