[Note: this is a draft]
We have for over one month been battling a major integration issue with one of our roaming partners.
This was a SIP integration and the idea was to send the signaling traffic over IPsec and the media traffic over public internet.
We hit a sag with the call setup after setting up the SIP trunk and when we took a trace, we realized that the INVITE message was being dropped by the firewall:
Model: srx240h2
JUNOS Software Release [12.1X46-D35.1]
Problem:
SIP over IPsec, call setup failure
Some Important Symptoms:
1. On the handset you would get the announcement; "The person you are calling is not answering"
2. Wireshark trace shows the INVITE message leaving the MSS
3. When you bypass the IPsec tunnel, call setup is successful
4. Firewall flow sessions show one way traffic
5. INVITE request is not received at the tunnel end point
6. SIP OPTIONS messages were OK and received well both ways
7. ICMP ping was OK
Today we had a major breakthrough regarding this issue, we were finally able to place a successful call through this SIP trunk.
Problem Cause:
The Packet size for the INVITE message from our MSS was abnormally big and had a DF bit set.
i would want to mention that our setup is kind of special, i will not dive into the details of our core network setup but what i can say is we are majorly a 4G (TDD) network with CSFB voice/sms/2g/3g services to a national roaming partner. so the SIP INVITE message is actually originated by our CSFB partner MSS and not our MSS.
Our MSS only acts as a proxy and relays the INVITE message to wherever it's supposed to go, which in this case was to our international roaming partner through this SIP trunk that we had setup over IPsec.
My reasoning to why the packet size was abnormally big, is that our MSS adds a layer of information onto the original packet making it bigger. for now i will not dive into the detailed analysis but i would be happy to share the knowledge in case you are interested (we can use the comment box below this article to carry on the discussion).
Solution:
Add this line of configuration to your VPN
set security ipsec vpn SIP_VPN df-bit copy
The default behavior of DF-bit, when the traffic goes to the IPSec tunnel, is to not change the DF-bit of the inner IP header and clear the DF-bit flag on the outer IP header. For more details on what this line of configuration does, please follow this link.
Results:
Call setup was successful and we were able to place a call through SIP over IPsec.
