RTP Ports closed over Site-to-Site VPN to Google Cloud

[pshaikh]

Hello,

I have deployed 3CX from Google Cloud Marketplace, it included a default set of firewall rules, please see screenshot:



Furthermore I added two more custom rules:
- for icmp from everywhere
- for every protokoll from subnets of on prem VPN-Sites

As mentioned our on prem network is connected via Site-to-Site VPN to Google Cloud VPC.
Furthermore I am trying to provision against the internal ip adress in order to be able to hot desk.

The issues I'm having with this are:
- calls from internal to internal do not work (ip phone is ringing but when i accept, caller still gets dial tone and receivers mobile phone continues ringing)
- calls from internal to external do not work at all (no dial tone at caller, no call at receivers end)
- calls from external to internal work fine

However when I provision the ip phone against the external ip everything works fine.

So it seems to be an issue with the RTP ports 9000-10999 not beeing routed through the Site-to-Site-VPN.
I thought why not run a portscanner

against external ip:


and against internal ip:


Please notice here that port 22 is open when scanning the internal adress due to the firewall rule

custom-tcx-phone-system-tcp-allow-all-internal

and the fact that I'm currently in the network of our on prem Site.

My question is why am I not able to use the ip phone when provisioning against the internal IP even when the firewall rule

tcx-phone-system-udp-9000

exists.

 

[JohnS_3CX]

Hi,

1. We automatically include only the public ports in the firewall config, this is a cloud install after all
2. Nmap will not see anything, the ports are not active when there is no active running calls on them
3. LAN-based phones will use the internal range 7000-8499, this is not publicised since you don't need to forward it ever.
4. Calls can be established, and the audio will simply not work (if only RTP was the issue). But in your case, SIP is also affected (based on the 3 issues you outlined above).

The reason why you can't use the phones is because the VPN is not set up properly to allow traffic in both directions, in transparent manner.

I think you will need to look further into how VPN works with Google Cloud before you can get ahead with this problem. This document can help you understand what types of network configs 3CX Supports, and then you also need to read up on GCP to see what type of VPN you can set up to bridge with your premises.
https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/

 

[pshaikh]

Hello and thank you for the quick reply

1. That makes sense, but not in a context of a Virtual Private Cloud.
2. I see
3. Is this documented anywhere? Since this is a Site-to-Site VPN I actually do need to forward these ports.
4. This doesn't make any sense to me, as mentioned in my first post the ip phones are working properly when they are beeing provisioned from the external IP, but the packets are still going through the same router but to different targets.

"The reason why you can't use the phones is because the VPN is not set up properly to allow traffic in both directions, in transparent manner."

Can you ellaborate please? I can reach the hosts in the VPC-subnet and vice-versa.

 

[JohnS_3CX]

Technically we do not support a VPN deployment. But generally speaking, a transparent VPN is one where the endpoints at the two sides are not aware that they are over a VPN. It is entirely transparent to them. To them it appears as if they are on the same local network and subnet and they can send all kinds of traffic back and forth to each other (no NAT or visible "proxy" in between). 3CX Thinks that this is a LAN installation which is supported - if you can achieve the above.

Unfortunately I cannot help you to set this up in Google (it's not my specialty) but I can tell you that when it is set up correctly, the devices would be able to access the PBX freely without any external port forwards. We do not document the internal ports (question 3) because this is not necessary on a LAN (or a transparent VPN), since any and all traffic is assumed that it would be able to pass through unimpeded. We want a LAN scenario here and this is up to you to simulate.



When you provision them based on the external IP, you will either run in STUN or SBC mode, both of which will pass through the firewall and out via the internet (not via the VPN). This is the intended way of using a cloud PBX, hence it works fine. The targets matter because we use the SIP protocol. In SIP you define which contact IPs the endpoints should use, and if those contact IPs are not reachable, you will not get an incoming call, or you will not have audio.

Suggestion: I would recommend to either get help from someone that has experience in setting up VPNs or you could make things way simpler by installing an SBC at your premises, and leaving your PBX in the cloud. This would be the best solution and is fully supported. If you still think a VPN is needed, I would highly recommend contacting a 3CX Partner which will have experience in setting up 3CX in such environments

 

[pshaikh]

Thank you for this very detailed explanation.