IP SoftPhone via IPSec VPN

[sirlawnmower]

Hello,
I am the networks administrator in a medium-sized company in Chile. We have a core of Cisco switches, a wired network and a wireless network, in addition to two Fortinet FortiGate 100E firewalls and two dedicated Internet links.
We have an Alcatel-Lucent OmniPCX PBX, with software version 3EH30556DFAA ONECL030/058.001
Until a few months ago we had four Call Center operators working within the LAN, using the IPSoftPhone v12.1.1.0 software configured in HTTPS+TFTP mode for connection to the PBX.
Now, the company has decided that those four Call Center operators work remotely from their homes. For that, connectivity via VPN was defined in an IPSec tunnel through the FortiGate firewalls. With this, the remote users can connect to the LAN via VPN, but the IPSoftPhone is not able to complete the registration in the PBX. When running the application, it tries several times to register but finally aborts due to timeout.
I made a capture of the traffic with Wireshark and verified that there are repeated attempts by the PBX to send three files via TFTP, but they fail to reach their destination.
Any help or advice you can give me to get to the solution of this problem will be welcome.

Hector

[Konstantinos.E]

ports used

client side

tftp 0-65535/udp windows,ios,android 1024-65535 macOS
rtp 32000-32512/udp
signaling 7775/ udp

server side

tftp 69/udp 10000-10499/udp
rtp 32000-32512/udp
signaling 5000-5099 /udp

Manage your firewall and should be ok.

[sirlawnmower]

Thank you for your answer.
But the policies I applied to that VPN have no restrictions at all.
All tcp and udp ports are permitted.
So, this is not the problem.
Let me explain the scenario: when I am a remote user and connect to the VPN via FortiClient, when I reach the firewall, a virtual IP address is assigned to my remote user. That address is taken from a pool defined in the creation of the tunnel. But that ip address is NATted to the LAN with the inside address of the firewall, because the virtual IP address exists only inside the firewall.
So, for example: the public IP address of the outside interface of the firewall is 190.151.47.10, and the inside address is 10.10.10.1. The pool of virtual addresses is 10.0.111.10 to 10.0.111.20. When I issue a remote connection via FortiClient, my connection gets the 10.0.111.10 address.
I have defined the ingress and egress policies for the VPN connection with no restrictions on any ports, and I have tried enabling NAT and disabling NAT in those policies (when I disable NAT I have to provide some static routes in the L3 distribution switch, of course).
And I cannot reach the OXE via de IP Softphone.

[Konstantinos.E]

i suppose your oxe has 10.10.10.1 gateway under netadmin.
Also do you have enabled trusted ip addresses on your ip domain?
Check also softphone in the network settings if network adapter in your vpn client interface.

This config is common and it should work . maybe your nat config is missing some parameters .
use tools as arp-proxy or a nat helper maybe will help

[sirlawnmower]

Hello.
This LAN is logically segmented in many VLANs and their corresponding subnets. The core/distribution Layer3 switch is the router between subnets.
The IP Telephony subnet is 10.0.101.0/24 the OXE is 10.0.101.2 and vlan interface in the switch is 10.0.101.1
Every ip softphone installed locally is in users subnet 10.1.20.0/23 and all of them are working perfectly.
Remote users connect via VPN using Fortinet FortiClient in an IPSec implementation. When the remote user connects the firewall assign them an IP address taken from an address pool between 10.0.111.10 and 10.0.111.20.-
The firewall policies applied to this IPSec tunnel are completely open and no NATted.

[alexeik]

can you ping the pbx from a remote workers PC and the other way round? what does a traceroute say from both sides?

[sirlawnmower]

Yes, I can. It's not a routing problem...

[vad]

I made a capture of the traffic with Wireshark and verified that there are repeated attempts by the PBX to send three files via TFTP, but they fail to reach their destination.

Make trace from both side. If PBX send but nothing received - check firewall rules. Some protocols (f/e/ TFTP)) - forbiden.

[sirlawnmower]

As I said previously, the firewall policies applied to this VPN are completely open, i.e., all traffic is allowed.
I did the following test: I started a TFTP server on a PC on the local network, connected to the same VLAN as the telephony subnet. Later, I connected remotely over the VPN from a PC, and ran a GET from a TFTP client, bringing back a 10 MB file stored on the TFTP server, and it worked fine.

[alexeik]

i would make a wireshark trace with working client and with a vpn client and then do a compare