SIP over VPN-issue

[Fjordmonkey]

Not sure if I should post this in another section, but here goes:

Recently I've come across a very strange issue with one of my customers. They have a SIP-solution in place, which, after I set up a new firewall running 5.2.3 (the same that had the infamous IPSec for iOS-issue I posted about here earlier), breaks for a remote site after ~32 seconds.

The traffic goes something like this:

Internet - Site A Firewall - IP-phone central (Aastra 430) - IPSec Site to Site-link - Site B Firewall - User endpoint handset.

All phones to handsets at Site A works fine, both in and out. It is ONLY the handset in Site B, which talks to the Aastra-box over IPSec VPN, had exhibits the 32-second break in connection if you call TO it from either the outside or from Site A. Calling out FROM Site B works fine. I've exported a tracelog from the Aastra-unit and find an entry saying Reason: SIP ;cause=408 ;text="408 Request Timeout"

Both firewalls that are in the mix has both SIP-Helper and ALG disabled, and both firewalls run 5.2.3.

I've yet to run a packetcapture, however, since the menu-item that should have been under System - Network on the FW's simply isn't there. In the process of setting up a trace through CLI.

So: Anyone else seen something similar? Before SIP/ALG was disabled, they did have the normal voice-only-works-one-way issue.

[emnoc · Accepted solution]

SIP and SCCP Traffic is handled by the VOIP ALG/Proxy by default in FortiOS 5.2 (http://kb.fortinet.com/kb/documentLink.do?externalID=FD36175) and Disabling VoIP inspection (http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405)

In about the 20 remote sites that I managed that has aSMB firewall , I never had to execute this.

Just set a  voip-profile  on  the fwpolicy for the phone-device with dst/src-subnet defined for the  voip-server and phone lans( devices ) & ensure utm status is enabled.

I never ever seen any needs for any of the suggested modification. The sys sip diagnostic command will provide more than enough information to show you status response  for any requests.

In FortiOS 5.2 is even 10x better .

just my 2 cts

[emnoc]

That status of 408 ( assuming that's what the cause code map means ) means whatever request that you sent could not executed in the time suitable. So what's the  request before the status-code.

That might shed some light. Also are these sip devices registered with the pbx-softSwitch  and show registered?

Has this problem came up b4 or is this a new problem and with this firewall ?

As far as SIP-ALG, if you define a voice-profile this disable the session helpers if IIRC and my understandings, but I don't think this should be an issue. The SIP-ALG will need access to look at dynamic ports & sip statefull tracking of the sessions between the UAs. So I would back track to see what request generates  that response & possible recreate while running the Aastra in a monitor.

I would also debug a few devices to see what fwpolicy-id(s) are being hit ( diag debug flow )  and post what you have defined for the policies. But a generic LANA<>LANB allow should be more than enough IMHO and obviously the SIP server.

Keep us posted, but it seems like this week  has a lot of SIP related issues postings.

[Fjordmonkey]

I'll definitely keep you posted :)

I plan to do a reboot of both the handset at LANB and the Aastra-unit during the weekend, and then test again on monday. Also had a co-worker check up on the policies just to check that I hadn't gak'ed up things, but as he said: it's hard to gak policies that basically allows everything between the two sites. I'll post them over the weekend, as right now I have a date with an ice-cold beer!

The SIP-devices do show up as registered as well. The main difference between the devices at LANA and LANB is that the LANA-handsets are all digital DECT-sets, while the muppeting device at LANB is an analog device. This probably shouldn't have anything to say, but the phone-guy is looking into replacing the analog heap with a DECT just for testings sake (besides, nothing is as permanent as a temporary solution).

The specific problem has reared its ugly head once before, but back then all that was done was a reboot of LANB's Fortigate, the Aastra box and the handset. This didn't work on wednesday, but I'll give it a shot again. Might just solve the issue.

The good bit about all this, though, is that I'm learning quite a bit about troubleshooting Fortigates. Which is always good even if it's also somewhat aggrevating.

[emnoc]

Would i would do is temporary rule out the devices by maybe using a softclient  and see if the problem(s) comes or goes or stays or change.

You could also deploy a sip-protocol tester to also rule out the sip UAs ( SIPP comes into mind and is quite  simple ). This will also benchmark and stress the fortigate  which I don't think is the problem.

[link]http://sipp.sourceforge.net/[/link]

[Fjordmonkey]

Did a diag flow on the Fortigate unit at LANB today. Restart of both the Aastra-unit AND the handset did not solve things.

[Fjordmonkey]

New update:

Did some packetcaptures on the Fortigates in question when an incoming call comes through, and found something very odd: The analogue SIP-adapter (an AudioCodecs MP-112FXS) at LANB is the one sending a BYE to the Aastra-unit after 32 seconds, and also throws a SIP-error 408 which is from what I've found basically a timeout-error between either the MP112 and the Aastra, or the MP112 and the SIP-provider. Net result: call disconnects.

I am starting to lean against that it's the Fortigate 60D at LANA that's muppeting here. The handsets that the customer has at LANA are all DECTS.

Going to have a peek at SIPP and see if I can run that from a computer at LANB during the weekend once I get higher brain-functions back (3 hours of sleep due to a major Exchange-snafu = not conductive to troubleshooting firewalls)

[Fjordmonkey]

Came across two rather interesting Knowledgebase-articles about SIP and, more specifically, SIP-processing on 5.2.

SIP and SCCP Traffic is handled by the VOIP ALG/Proxy by default in FortiOS 5.2 (http://kb.fortinet.com/kb/documentLink.do?externalID=FD36175)

and

Disabling VoIP inspection (http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405)

The first article mentions changing the Default VOIP ALG-mode to kernel-helper-based, where SCCP is not processed and SIP-traffic is processed by the SIP Session Helper. If the SIP-session help is disabled (which it is in my case), no SIP processing takes place.

Going to try this out tonight and see how things behave tomorrow morning.

[Fjordmonkey]

Well, that didn't work too well.

Did a set default-voip-alg-mode kernel-helper-based at the LANA-location, with the net result that the phones shut down completely both inbound and outbound. Changed it back to Proxy-mode and it came back up.

Back to the drawing board...

[emnoc · Accepted solution]

SIP and SCCP Traffic is handled by the VOIP ALG/Proxy by default in FortiOS 5.2 (http://kb.fortinet.com/kb/documentLink.do?externalID=FD36175) and Disabling VoIP inspection (http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405)

In about the 20 remote sites that I managed that has aSMB firewall , I never had to execute this.

Just set a  voip-profile  on  the fwpolicy for the phone-device with dst/src-subnet defined for the  voip-server and phone lans( devices ) & ensure utm status is enabled.

I never ever seen any needs for any of the suggested modification. The sys sip diagnostic command will provide more than enough information to show you status response  for any requests.

In FortiOS 5.2 is even 10x better .

just my 2 cts

[gschmitt]

Just as a general info (don't have time to go into detail):

Sip traffic is encrypted by default and should not go over VPN connections.