Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Softphone via ZTNA
- Thread starter trilogy8
- Start date
- Thread starter
- #3
ZTNA is a Zscaler vpn type client. Our teams are looking to replace our current VPN client which is F5. There's functionality differences it seems with this new one where this ZTNA client works one way. Our network team is saying if the client is the destination of the traffic it won't be able to accept it since the ZTNA clients work one way. In our case, the company laptop connects and builds the tunnel and then the Avaya softphone client then registers to CM. I interpret from them is if the softphone client calls another it won't work and they are looking for workarounds.
- Thread starter
- #4
hopefully a more articulated explanation is:
ZTNA "VPN" client connects to the ZTNA cloud which has a connection to our data centers using Zscaler App Connector.
These ZTNA clients do not register their name/IP with our internal DNS which means that they cannot be reached by other sources such as users' machines or servers. With this limitation, is there any way softphones could make phone calls to other clients if the receiving end machine cannot be resolved via name.
Also, they get an IP address assigned by Zscaler that does not fall within our RFC1918.
ZTNA "VPN" client connects to the ZTNA cloud which has a connection to our data centers using Zscaler App Connector.
These ZTNA clients do not register their name/IP with our internal DNS which means that they cannot be reached by other sources such as users' machines or servers. With this limitation, is there any way softphones could make phone calls to other clients if the receiving end machine cannot be resolved via name.
Also, they get an IP address assigned by Zscaler that does not fall within our RFC1918.
My google found Zero Trust Network Access 
Yeah, that doesn't sound nice. The phone side has an IP that CM or SM send packets to. That's how they get told they're being called.
Don't think that'll work. If you go SIP Remote Worker/SBC, then the SIP traffic would go through the SBC and not the ZScaler gateway.
But even their own documentation says they don't support voip protocols:
Protocols that are not supported (like SIP, H.323, H.248, VOIP, and TFTP) should be bypassed from Zscaler by changing the configuration on the firewall or router when configuring your GRE or IPSec tunnel.
Yeah, that doesn't sound nice. The phone side has an IP that CM or SM send packets to. That's how they get told they're being called.
Don't think that'll work. If you go SIP Remote Worker/SBC, then the SIP traffic would go through the SBC and not the ZScaler gateway.
But even their own documentation says they don't support voip protocols:
Protocols that are not supported (like SIP, H.323, H.248, VOIP, and TFTP) should be bypassed from Zscaler by changing the configuration on the firewall or router when configuring your GRE or IPSec tunnel.
- Status
Similar threads
