Fjordmonkey
New Contributor

SIP over VPN-issue

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.

 

 

Regards

Marius Sparby, aka Fjordmonkey

Fortigate-noob extraordinaire

2 Solutions
emnoc
Esteemed Contributor III

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

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

gschmitt

wittersjohan wrote:

I would pay attention to that... packets can easily be captured and replayed in Wireshark for example... If you really have sensitive information passing over these connections, it might be interesting to put them in a tunnel.

It might, and it's only natural for us to trying to put everything we can in an IPSec tunnel but:

[ul]
  • All Lync 2010 traffic is encrypted by default. SIP signaling traffic is encrypted using TLS, and all media traffic (audio, video and application sharing) is encrypted using SRTP. Because of this, Lync traffic does not need to be routed through encryption tunnels unless your organization specifically requires dual layer encryption.[/ul]

  •  

    Lync, as an example, is designed to have an Edge server without vpn, the connection with vpn encryption can lead to spotty audio/video

    Additionally (at least lync) tries to establish a direct connection between the clients during an audio/video call, you'd have to make sure all clients can reach each other to be able to call

    View solution in original post

    13 REPLIES 13
    emnoc
    Esteemed Contributor III

    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.

     

    PCNSE 

    NSE 

    StrongSwan  

    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.

    Regards

    Marius Sparby, aka Fjordmonkey

    Fortigate-noob extraordinaire

    emnoc
    Esteemed Contributor III

    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]

     

     

    PCNSE 

    NSE 

    StrongSwan  

    Fjordmonkey
    New Contributor

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

     

     

    Regards

    Marius Sparby, aka Fjordmonkey

    Fortigate-noob extraordinaire

    Fjordmonkey
    New Contributor

    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)

    Regards

    Marius Sparby, aka Fjordmonkey

    Fortigate-noob extraordinaire

    Fjordmonkey
    New Contributor

    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.

    Regards

    Marius Sparby, aka Fjordmonkey

    Fortigate-noob extraordinaire

    Fjordmonkey
    New Contributor

    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...

    Regards

    Marius Sparby, aka Fjordmonkey

    Fortigate-noob extraordinaire

    emnoc
    Esteemed Contributor III

    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

     

    PCNSE 

    NSE 

    StrongSwan  

    gschmitt
    Valued Contributor

    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.