Hey there,
we have problems with SIP calls via Speedfusion VPN.
Our Setting:
We have a Peplink MAX HD4 MBX connected to a Peplink Balance 580 via a SpeedfusionVPN connection. A second tunnel is configured in the VPN link settings, which serves as an audio tunnel. For this purpose, we have created a rule for UDP port 5060 in the outbound policies.
If we call a SIP codec in the network of the MBX HD4 from a SIP codec in the hub’s network, then a working connection is established. If we try the whole thing the other way around, it’s not working. The call arrives at the SIP codec in the HUB’s network and can also be accepted, but the return path then fails.
The SIP decoder on the HD4-network’s side does not come up.
A check with Wireshark confirmed that SIP traffic was no longer arriving on the HD4-network’s site. We also tried various other outbound policy settings (larger UDP port range, DSCP EF,…) but nothing helped so far. The response from the HUB’s network does not arrive in the HD4’s network.
Has anyone experienced something similar or does anyone have an idea?
Thanks so far
Simon
You mean a sub-tunnel right? So you can enable Wan Smoothing to ensure the VoIP traffic perhaps?
OK so routing from hub to peer is working - excellent.
But we know the hub can route to the peer network… is the SIP invite from the Peer network announcing the wrong IP? Have you disabled SIP ALG on the HD4? Perhaps it is rewriting the SIP invite.
That routes the SIP traffic, what about the RTP traffic? In the past where I have hosted IP PBX in the cloud I tend to set an outbound policy based on the PBX IP so all VoIP traffic goes via the SpeedFusion tunnel.
Right. WAN Smoothing is enabled.
Yes, we are running Compatibility Mode for SIP in the Service Passthrough Support Settings. That should disable the SIP ALG.
For a test we already included the whole Port Range from 5004 to 20000, that should include all possible SIP and RTP Ports but didn’t change anything. One direction worked, the other not.
I assume what you mean is that SIP Signaling is failing. Many times people say SIP but in reality it is RTP that is failing.
First thing I would do is review those outbound policies at both ends and add one for communication that matches src/dst of each device and send it down the same subtunnel. The idea being that I would want to test PING between src and dst in both directions and make sure there is communication.
After ICMP is confirmed I would test a SIP call from the HD4 network to the hub and do a packet capture at both ends. Do not worry about RTP at this point. You simply want to make sure the SIP Protocol is making its way back and forth without issue (SIP INVITE, 200OK, BYE).
If you made it this far and confirm SIP is OK, but RTP (Audio) is failing, you have to dig into the Wireshark capture to determine if the device sending the SIP Invite is populating an unexpected IP in the connection address section of the Session Description Protocol. Many times the endpoint “auto discovers” the public IP and uses that instead of the LAN IP, which will certainly cause the audio to fail.
2 Likes