I am unable to register a soft client over a VPN.
The soft client registers successfully when connected to the same network but Asterisk does not seem to respond to the registration request when connected remotely via a VPN.
I would expect Asterisk to reply with a 401 unauthorized upon receiving the register, triggering the soft phone to re-register with credentials. The server seems to acknowledge (ACK) the request but Asterisk doesn’t respond. The SIP headers look the same and the SIP debug does not display any transactions as though the request has not made it to the Asterisk SIP stack.
I have attached screenshots of the working vs non working registrations and also the Wireshark trace.
Any help would be much appreciated
Does the SIP traffic appear in “pjsip set logger on”?
Hi Jcolp, I am running chan_sip, the log level is enabled for DEBUG. The same behavior is observed on both Asterisk 11 & 20.
Test-PBX*CLI> logger show channels
Channel Type Status Configuration
/var/log/asterisk/full File Enabled - DEBUG NOTICE WARNING ERROR VERBOSE
Console Enabled - DEBUG NOTICE WARNING ERROR VERBOSE
Ah, I’ll bow out then.
VPN’s can really mess with VoIP. For example I have a LAN2LAN OpenVPN and I have no problems registering a Polycom phone over it and sending calls back and forth while a Cisco phone will register but not complete calls. wireshark trace indicates the rtp data is being translated - even though the vpn has the -notranslate option set. Why this does not bother the Polycom phone is unknown.
Anyway, I would guess you are doing UDP registrations and if you were to switch to TCP registration it would work but then calls would not complete. Your VPN is obviously the culprit and it’s messing something up in the SIP traffic. This is more of a networking question - even if you had current Asterisk and pjsip running all that would happen is they would have you make a bunch of traces and then it would show your VPN is messing with the call which you already know.
What is your VPN created with?
Hi TedM, thank you for your response. The Phones are using TCP SIP on port 5060. I have tried various VPN options including native windows PPTP and Shrewsoft IPSEC. Asterisk does not respond on either solution.
I agree that something strange is going on when a VPN is introduced as this is functioning perfectly when connected on the LAN. I have provided the working SIP trace (LAN) vs the non-working (VPN) trace in the comparison spreadsheet. I am unable to identify any significant differences, the SIP headers look identical and I was hoping that someone could help identify the issue with the network headers or point me in the correct direction in troubleshooting, it seems that although the port is open on the Debian Server, Asterisk does not respond to the Register and I am unable to see anything in the asterisk console or full log.
root@Test-PBX:~# netstat -punta | grep 10.5.5.228
tcp 0 0 10.5.5.3:5060 10.5.5.228:50318 ESTABLISHED 2989/asterisk
tcp 0 96 10.5.5.3:22 10.5.5.228:50164 ESTABLISHED 9943/0
Any help would be appreciated.
Please post information on the VPN itself. You said you tried multiple VPNs - so are we talking a windows system that is a remote VPN client? What version of Windows? Is this a softphone program that’s running on the windows system? What is your VPN server? Is it another PC or a hardware device?
Hi TedM, I have tried the native Windows VPN with PPTP and also Shrewsoft IPSEC IKE PSK on both Windows 10 & 11 Pro. The VPN concentrator is a Cisco 997VA ISR. I am using Cisco IP Communicator as the Soft Phone.
The SIP headers (see attached) for the non working and working registrations look identical to me. Perhaps there is a difference in the network headers, they do look very similar but I have limited knowledge is this area. The server seems to acknowledge (ACK) the request but Asterisk doesn’t respond.
Any help would be much appreciated
I was wondering about that.
You can start here:
IP Communicator requires a modified TFTP server to serve out it’s SEPMAC configuration file so somewhere in this mix you either have a patched TFTP server or you are using a Cisco UCM’s TFTP server.
I have only managed to get IP Communicator to work with Asterisk when I was either on the same subnet as the PBX, or my network connection to the subnet the PBX was on was through a real, honest-to-God router, router. (in my case a FreeBSD system with 2 network cards) It is very sensitive to NATs and does not tolerate them well at all. Like you, I have not gotten IP Communicator to work from a Windows host running any kind of VPN client software. But I have problems with it even when the VPN isn’t even terminated on the Windows box but instead is terminated on a separate hardware box.
I think you have 2 problems. First is the IP Communicator softphone’s inability to negotiate any NAT modifications to the packet flow for both registrations and calls. This is also a problem shared by the firmware in the regular Cisco desk phones.
Second is that IP Communicator ties into the Windows network stack at a much lower level than the windsock API. It’s probably tying into the NDIS layer. As a result, IP Communicator is trying to send traffic out the same publicly numbered interface that the PPTP and IPSEC clients are using to connect to the VPN server.
My suggestion is unless this is something that you are hell-bent on getting working, that you try the Linphone softphone application. IP Communicator is pretty cool - when it’s working - and it works with the USECALLMANAGER patch to support BLF keys - but it’s really archaically written software and it’s a quick hack by Cisco dating from the model 7960 days.
One last note on this - I HAVE been told that IP Communicator DOES work if you use Cisco Secure Client AKA Cisco AnyConnect software with a Cisco ASA as a VPN head-end.
I have NOT checked this out myself. I think I will, however, since I have the testing networks setup.
Thank you TedM for your input, it is much appreciated. I will try it with Cisco AnyConnect.
As mentioned above, the phone works perfectly when on the same LAN as the PBX. There is no NAT configured on either the phone or PBX in both scenarios and the ethereal trace of the SIP headers taken from the PBX look identical. Interestingly port 5060 also opens on the Debian Server so it seems that the server acknowledges the packet but it doesn’t seem to reach Asterisk.
I know you probably don’t have a NAT configured in your Shrewsoft VPN but that code may be secretly running the packets through translation behind your back anyway.
The OTHER possible issue is MTU. Those VPN solutions may be improperly handling overhead and Cisco Communicator may be as well.
Consider that most channels on “the internet” have a max MTU of 1500 bytes. So a PPTP vpn or most other VPNs have to use some of that for the encryption. If Cisco Communicator sends a registration packet of exactly 1500 bytes in size through an ethernet network - then no problem. If it sends it through a VPN, then the VPN software must fragment the packet then the PBX reassembles the frags. If the VPN software fails to frag it properly, then the reassembled packet will be trashed.