Windows app traffic flow issue

[PeterCheng]

Hello sir,

Recently I found a strange behavior.
I'm using 3CX V18 update 3 with on-premise linux platform and client is Windows app.
Using Internet to connect to our 3CX server is normal, but it's a bit wierd when I connect to our VPN service to access 3CX server.
When I used wireshark to capture my packets, I found normal signaling is walking on the vpn virtual nic and saw port 443 traffic.
destination ip is 3CX server private ip (for historic issue, the ip seems a public ip (202.x.x.x), but actually it's a private network)
But when I made a call, the UDP traffic will go through wifi nic and it seems that it treated RDP as internet traffic.
destination ip is 3CX server public ip.
DNS resolves 3CX as internal network (internal dns and private ip), but different traffic for signaling and rtp?

Can somebody explain why it could happen? why does 3CX clients use different way to communicate with server?
Thanks.
Peter

 

[NickD_3CX]

Hi Peter,

First of all it is the duty of the VPN client to force the traffic via the VPN Tunnel, so I can't talk too much for that.

Some VPN client though don't always "catch" applications that have already established a connection.
Try this, first close the Desktop App completely from the Notification Area, then launch the VPN client and let it make the connection, then re--launch the Desktop App.

 

[PeterCheng]

Hi Peter,

First of all it is the duty of the VPN client to force the traffic via the VPN Tunnel, so I can't talk too much for that.

Some VPN client though don't always "catch" applications that have already established a connection.
Try this, first close the Desktop App completely from the Notification Area, then launch the VPN client and let it make the connection, then re--launch the Desktop App.

@NickD_3CX ,
Thanks for your suggestion.
I followed your instructions to do the test, but unfortunately the result was the same.
I'm wondering which configuration made this happen?
It seems that it won't happen in the past.
Since the signalling goes through VPN tunnel, the audio should not go throuth the Intrenet directly.
The destination IP is the same, and I'm no idea why they go through different ways.
Please help or if possible, you can try to simulate our environment, thanks a lot.

Peter

 

[PeterCheng]

And I found that basically 3CX windows app client will communicate with server with private ip(202.X.X.X) through VPN tunnel.
But when I make a call, from wireshark I found that it will use STUN to talk to 3CX server's public ip (211.X.X.X) from the wifi nic's ip address (public ip).
I'm wondering if 3CX client treat server ip as public ip? But normal keepalive/ signalling as private network?
No idea.

Peter

 

[NickD_3CX]

I'm wondering if 3CX client treat server ip as public ip?

If the Server IP is not in range 10.0.0.0/8 or 192.168.0.0/16 or 172.16.0.0/12, then this is very likely yes.
In this case it is also likely that if the server "sees" the 3CX Client coming from a Public IP range, then it is sending the Public IP in the SDP.


This aside though, when you establish a VPN Tunnel, I think all traffic should be routed through it regardless, unless you have made any exclusions on the Firewall.

 

[PeterCheng]

If the Server IP is not in range 10.0.0.0/8 or 192.168.0.0/16 or 172.16.0.0/12, then this is very likely yes.
In this case it is also likely that if the server "sees" the 3CX Client coming from a Public IP range, then it is sending the Public IP in the SDP.


This aside though, when you establish a VPN Tunnel, I think all traffic should be routed through it regardless, unless you have made any exclusions on the Firewall.

Hello @NickD_3CX ,

I just don't know when connecting in VPN, fqdn resolves is 202.X , but audio will not communicate with 202.X, client uses 211.X instead. Before V18 update 3 , there seems no such issue. It seems that there're 2 teams who wrote the code. Signalling uses fqdn's response to communicate, while audio connection uses external public ip to communicate.
By the way, as I know we don't use on-premise STUN, why do I capture packets and found it's there ?
Thanks.
Peter

 

[NickD_3CX]

It seems that there're 2 teams who wrote the code.

This is absurd, don't assume things.

fqdn resolves is 202.X , but audio will not communicate with 202.X, client uses 211.X instead.

Where the FQDN resolves to has nothing to do with it. SIP doesn't work this way.

By the way, as I know we don't use on-premise STUN, why do I capture packets and found it's there ?

STUN packets are required for many transactions, including WebRTC.


So to summarize, from the sounds of it, the "Local" IP of your 3CX is 202.x.x.x. This is a problem:
https://www.3cx.com/docs/manual/phone-system-installation-windows/#h.54jfq2u6vkwt

If you check the first bullet point in the admin guide, it clearly states that for LAN installs, the Private IP needs to be in the RFC1918 IP range.
I think this is the first thing you need to address, then take a backup, uninstall 3CX, re-install it and restore the backup, then reconfigure all LAN devices to use the new LAN IP.