Asterisk PBX over Watchguard BOVPN VoIP Issues
Hi Guys,
Been having this problem for months and I can't seem to find the issue. Watchguard Support have been helping but TCP Dumps aren't showing the issue.
Setup:
Two sites both running M290's
1GB leased line at both sites, different ISP's
Virtual Interface (BOVPN) between the two.
3 Subnet networks passed over the VI. 1 PC Network, 1 Linux Network, 1 Phone VoIP Network
At Site 1 has a Asterisk PBX SIP Server
At Site 2 60xVoIP phones connect to this PBX over the VPN
SIP-ALG is disabled on both Fireboxes
Policy on both Fireboxes allowing any port to the PBX IP through the tunnel.
TCP MTU Probing set to always enable, on both WG's
DF bit Enabled on the BOVPN, set to Clear on both WG's
The Problem:
Most of the time phones work OK. However more than 20 times a day phones at Site 2 will ring with a internal or external call, the user answers, shows as answered, but no one on the other line. Hangs up, and the phone starts ringing again. Sometimes, if the user picks up the call, waits around 10secs, they can finally hear the other person.
TCP Dumps simply show ICMP phone unreachable when these problems occur.
No issues with the PC or Linux network through the virtual interface.
Phones at Site 1 where the PBX is located, don't have this issue.
Hoping maybe someone out there knows what I might be missing.
Comments
For the record, what Fireware are these units running ?
ICMP phone unreachable - suggests to me that the BOVPN is at that time not traversing traffic.
How often does your BOVPN tunnel rekey?
v12.10.2.B692269 on both. No idea how often it rekeys. Where can I check ? I see the next rekey is 1hr 22mins from System manager.
You can see the rekey value(s) in the Phase 2 setting that you are using for your BOVPN.
The default is normally 8 hours, but yours could be customized to a different number of hours and/or based also on Traffic in kilobytes.
A Traffic Value selected can cause rekeys often at busy times.
Verify each endpoint's Phase 2 settings.
The try to verify that the tunnel is not rekeying often, by checking FSM regularly.
If it isn't rekeying often, then rekey is not the cause, and it just removes that as a possible cause.
IKE Diagnostic logging should also show rekeys in Traffic Monitor.
Also, V12.10.3 is out.
Nothing obvious in the Release Notes that may address your issue.
Its a virtual interface, and I see no settings for Rekey times in phase 2 !?
There is a Phase 2 name specified in your VI VPN setting.
Then look at that Phase 2 name in the Phase 2 proposals list.
It will show the rekey values being used.
Got it, 8 hours. But the phones drop out all the time, not every 8hrs.
So - doesn’t seem to be a rekey cause
No
Hi @Brans
Based on your description, it sounds like the phone's are able to talk via SIP, but there are issues with the actual RTP streams set up during a call.
-If SIP-ALG policies aren't in use, the firewall won't be doing anything to the traffic aside from allowing it or denying it. If the traffic leaves an external interface and matches a NAT rule, the firewall may also NAT it.
-If default BOVPN allow rules were left, you'll generally have a wide open packet filter for any TCP/UDP/ICMP traffic via an Any packet filter.
Are there any firewall deny logs that might suggest the firewall is what is blocking this connection? The firewall won't go from denying a piece of traffic to suddenly allowing it without a rule change. This suggests there's something else happening. If so, what is the reason for the deny?
My suspicion would be to check where the actual RTP (voice stream) traffic is going when it's not working.
I suspect that it might be trying to open a connection via the internet, or is trying to open a connection to some other server that is unreachable before it finally gives up and tries the private IP.
-James Carson
WatchGuard Customer Support
No deny's in the TCP dumps. All I see around the time of the issue is ICMP unreachable. We are going to try 2 x Drayteks just to rule out the Watchguards.