Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
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

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

PCNSE NSE StrongSwan
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
    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.

    Johan Witters

    Network & Security Engineer

    FCNSP V4/V5

     

    BKM NV

    Johan Witters Network & Security Engineer FCNSP V4/V5 BKM NV
    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

    emnoc
    Esteemed Contributor III

    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.

     

     

     

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    emnoc
    Esteemed Contributor III

    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.

     

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    Labels
    Top Kudoed Authors