I have encountered an extreme situation while configuring a new voip server. The voip server is now moved from local hosting to cloud, as such all phones internally go through boundary and NAT. Using two test phones, plugged in locally and connected to the remote server, when I call one from the other the connection is established and there is fine two-way communication, so no NAT issue. However, after about 20-30 seconds the whole network starts lagging. As I ping 8.8.8.8, the latency (measured from other devices connected to the network, or even from the router itself) goes up from 8ms to 2000ms+ and only resumes normal operation when I disconnect the phone call.
The two phones are connected to a CRS (6.37), connected to a Hex (6.36.3) as router (UPDATE both now updated to 6.37.3). Both have firewall service-port sip disabled (tested with enabled too). Both show normal resources and no major change in pps or throughput.
So my question is basically, how can a SIP call effectively cause denial-of-service? And how do I fix this?
I don’t have any queues, and as for firewall it worked fine for the past many months - only the SIP caused this issue, and only externally when NATing, as previously and even now internal server (going through ipsec) works fine.
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
Hi,
Really need a capture of your WAN interface to diagnose this.
For instance, it could be that not all the SIP traffic is successfully traversing the firewall, causing many re-transmissions which are hitting the firewall.
This is unlikely, but possible depending on your SIP server setup.
Are you saying that my SIP server may be DoSing me? That makes perfect sense, I’ll create a rule to see that. What would you recommend? Netflow and wireshark? Or just log the firewall drops?
I would start with a packet sniffer capture of the WAN interface when you get the slow down.
This will show if the server is causing the problem or not.
OK I’ve checked it, packet sniffer to wireshark, and seemingly there is nothing out of order. I can see the call being established, SRTP packets with sequence rising both ways throughout the call, even when the ping to external server is already times out. Only thing around the time when the lag begins (20s into the call) is a CLASSIC-STUN Binding request, but guess thats normal. I’d save and upload, but not sure if that would be of any help, and also for some reason wireshark has save grayed out, never tried streaming before.
OK, it would be useful so see if the ICMP packets get delayed on the way out or in.
For example, if you can see ICMP with immediate replies back but on your PC you get large delays then it’s the router’s firewall introducing it.
But if you see the same lengthy delays in replies on the WAN interface then it’s something upstream that is causing the problem.
@tslytsly
I was pinging from the router itself to 8.8.8.8, and the delay was same way measurable on WAN port. Upstream then? My ISP? What I could try is to connect out on VPN and see if the issue persists over that.
@savage
Flow control is set to off on all interfaces.