Skip to main content
Fjordmonkey
Fjordmonkey
New Member
May 29, 2015
Solved

SIP over VPN-issue

  • May 29, 2015
  • 10 replies
  • 48054 views

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.

 

 

Best answer by 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

    10 replies

    emnoc
    emnoc
    New Member
    May 29, 2015

    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
    FjordmonkeyAuthor
    New Member
    May 29, 2015

     

    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
    emnoc
    New Member
    May 29, 2015

    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
    FjordmonkeyAuthor
    New Member
    June 2, 2015

    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
    FjordmonkeyAuthor
    New Member
    June 5, 2015

    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
    FjordmonkeyAuthor
    New Member
    June 10, 2015

    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
    FjordmonkeyAuthor
    New Member
    June 11, 2015

    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
    emnoc
    New Member
    June 11, 2015

    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
    gschmitt
    New Member
    June 11, 2015

    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.

    Johan_Witters
    Johan_Witters
    New Member
    June 11, 2015

    gschmitt wrote:

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

    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.

    gschmitt
    gschmittAnswer
    New Member
    June 11, 2015

    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

    emnoc
    emnoc
    New Member
    June 11, 2015

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

     

     

    That's news to me, maybe the only thing that secured is the SIP_Client register with the hash+nonce, but all other aspect of the SIP signaling and then the  RTP streams is  out in the air and can be captured ande decode and even the audio stream decode.

     

     

     

     

    emnoc
    emnoc
    New Member
    June 11, 2015

    I don't know how we jumped to a lync & edge server when the OP stated the following gear at site A

     

    Aastra 430

     

    This unit supports secureRTP and TLS for signaling. So if the instruments are setup for  tls and sRTP than yes , the additional IPSEC encryption envelope is not really needed.

     

     

    Terms & ConditionsAccessibility statement