Weird network issue

Question

We are facing a technical issue with networking, which I'm not able to comprehend.

We are using Linphone Client to connect to x.x.x.125(Freeswitch box) via x.x.x.101 i.e .101 being a SIP proxy Flexisip.

The SIP flow look as below.

   [ Linphone box ]  <-> [ `.101` box ]  <-> [ `.125` box ]

Now when we register i.e SIP REGISTER request (without VPN connected) to .125 via .101 it works i.e Registration is a success, saying this because I was sniffing around the traffic with TCP dump on both .101 and Linphone Client box (both had 200 OK Response for Register request).

Now here is the deal, when we make a call i.e send SIP INVITE request without VPN connected. We see no traffic on .101 box but same can be found on Linphone box hinting that request is directed to .101.(but at the same time I can constantly see OPTIONS request appearing from .101 to Linphone Machine and also a 200K response getting sent from Linphone machine for OPTIONS request.)

Now, The sooner we connect to VPN, we see the request appearing on the .101 box from Linphone box

Now, had this behaviour would have stayed constant, I would have suspected the Firewall rule but the it would work during SIP REGISTER and not using Regular INVITE invite is something I'm able to understand here.

And when we are connected to VPN it work.

NOTE: If I assume this is a packet loss as a part of UDP even the retransmission too does not go through and this happen in multiple run..

It's only the INVITE packet would not be sent always does not happen with REGISTER request.

Here how the sip flow looks like

Answer 1

Given the REGISTER requests are getting through that rules out an IP routing and firewall issue (assuming it's not doing deep inspection on SIP packets).

That leaves the two most likely culprits as the client software (in this case Linphone) using the wrong network interface,

Try running a test with a tool like sipp where you can explicitly set the local address to use and the type of SIP request to send.

# To test the user agent client scenario (which sends INVITE requests) use:
sipp -bind_local 10.1.10.1 -sn uac -m 1 x.x.x.125

Update:

Some observations from inspecting the packet captures:

In the no VPN case:

• there is a NAPT between the softphone and the Proxy translating 10.1.10.1 to 49.36.13.47, e.g. 10.1.10.1:39248 mapped to 49.36.13.47:44150.
• REGISTER responses do appear to be coming from the FreeSWITCH server at 63.211.239.125 according to the User Agent string of Flexisip... on the response.
• in agreement with the original post there are no responses at all to INVITE requests in the capture.
• there are no fragmented UDP packets captured.

In the VPN case:

• there is no NAPT between the softphone and the Proxy. The softphone traffic is originating from 172.17.8.37.
• the softphone is using an IP address of 192.168.29.134 in it's SDP offer which means the device likely has multiple network interfaces.
• there is a fragmented UDP packet recorded when the softphone sends an INVITE request to the Proxy but it doesn't seem to be an issue as the Proxy happily forwards the request to the FreeSWITCH server.

Missing Data:

The no VPN capture does not contain the traffic between the Proxy and the FreeSWITCH server. This is the most crucial leg for the analysis since it could show whether the Proxy is forwarding the INVITE request or not.

Running tcpdump directly on the Proxy would be able to provide this missing information.

Updated Guess:

Based on the still incomplete information my best guess would now be that that Proxy has misconfigured (or perhaps deliberate) SIP settings and is silently dropping INVITE requests received on public interfaces.

When the softphone connects on the VPN the INVITE requests are forwarded because they are considered to originate from an internal network.

For REGISTER requests the Proxy could have a rule that says always forward them no matter which interface the Proxy receives them on since they are not as risky as INVITES.