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.
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:
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
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.
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.
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.
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)
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.
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.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.