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

[Johan_Witters]

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 · Accepted solution]

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]

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]

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.