SIP in nat configuration problem

[Miata]

We have a fortinet firewall: FortiGate 311B Firmware Version v5.2.3,build670 (GA) [Update] We are working in NAT configuration Poort 1 is used for management. Poort 2 is uplink to outside world The other ports are aggregated in one pipe with each of them having there own small subnet. third digit representing the port number. Registration is not ok, due to NAT problem I attached  195.207.5.83 : public ip on the internet side.  10.40.5.135 : local ip assigned to ALU equipment Fortinet firewall should do the NAT to translate the IP.  Attached trace is taken on the ALU equipment, public ip should not be seen in SIP reply messages sent to ALU equipment.  See packet 4 in register_nok_fortinet_problem.pcap  In packet 4 the ip in the contact header from the public side should be replaced by isam IP again. Now it is : sip.Contact == "<sip:01150900027@195.207.5.83:50177>;expires=120" It should be replaced by : sip.Contact == "<sip:01150900027@10.40.5.135:50177>;expires=120" SIP session Helper is disabled.

It seems the private IP is not translated anymore into the public ip. On the internet side we can see 10.40.5.135. I expect the public internet ip 195.207.5.83 would always be used at internet side.

Are we missing somehow a parameter in the configuration or is this still some firmware problem?

[emnoc]

Okay thanks this explain more details. Looking at this line bothers me;

8) A PBR has been configured to redirect all the voice traffic via the ISP1

How do you manage PBR for the voice-phone devices? Can you share what you did exactly in your PBR for src/protocols/destination ?

Now if what your saying is correctly understood by me, when ISP#2 is used ALL works great,  but only ISP#1 has problems & the problems are sporadic ( is that correct )?

Can you explain this line;

12) I noticed also whenever i remove the nat on the policy iphone to isp 1 policy i start getting more sip traffic but if we again put the nat not same result.

What I would try to do ; 1>  get a pcap off a span/mirror for ISP#1 and 2> look at the sip_headers. Mainly you want to look at the following;

( all of these should be in the register method )

  sip.From  username@public_address/domain

  Method: REGISTER

  Contact URI: ( this should be nat to the address  &  if nat is deployed which should be the case in  your scenario )

  Authorization  ( the type and nonce details should be here )

Take a look at those headers in the SIP messages in a pcap and see if they look correct & are fixed up to match the public-address. i don't believe the fortigate will drop any of the above and they should be fixedup with the ALG.

And I know you said ISP#1 is public-addressed but are you 100% sure the ISP#1 router is not nat'ing or changing any. ( Yes I had issues verizon nat'ing a public address in a router ......:( ) So you might want to double check the address via a whatmyipaddress type of link using a pc/laptop from the voice-vlan. I stumbled around for over 3 days with VERIZON b4 I found out they where NAT'ing my address on a CE-router. I don't think this is the case but your never 100% sure and should not assume.

Back to registers, If you get a successful register and than failures, we can play with SIP-KAs. This serves in the same sense of NAT-T for keeping firewall NAT/XLATE/SESSION tables open and not premature expiry. I find a SIP-KA of  120-180sec is normal for 99% of the time, but YMMV you can be lesser or greater but the SIP-UAS/PROXY  provider can confirm a interval if in doubt. Some hardware clients configurations might have other values that are min/max to contend with.

Get back to us on whatever you end up doing, but I think you need to inspect headers on ISP#1 and grab a pcap to ensure the SIP-header is fixed up correct.

[Johan_Witters]

Normally on 5.2.3 for SIP connections to the outside world it would be enough to activate the default VOIP profile on the security policy and have NAT enabled. On older releases you had to disable sessions helpers etc, but that's no longer needed. Also, the use of PBR's is no problem if these routes are configured correctly. We use this kind of setup a lot for our customers, providing internet and other services on 1 line, and use PBR's to route the SIP traffic to a 2nd internet connection.

If there is a problem with the SIP fixup you should have problems with all external calls. You would see signalling working correctly (ringing etc), but you would get no speech or one-way speech.

If the issue is not constant, there might be a problem with your ISP or SIP provider...

[Silver]

Hi Emnoc,

Thank you for your reply.

1) PBR has been configured to redirect all the Voice traffic to ISP 1.

2) Yes when using ISP 2 for sip registration its working fine.

3) With the ISP 1 sometime it can register and get disconnect

Find  attached the pbr config.

Thanks

[emnoc]

That should work. I'm curious is the ADSL gateway list a ADSL modem ? is the address correct? What happens if you  place a static route for the SIP provider directly thru the port#3 and avoid PBR for a test. Does the SIP REGISTER and calls work?

If the next-hop gateway is a ADSL modem than maybe it's creating problems with pinholes and mapping of src/dest-ports.