Telnet is getting connected in all ports if using Zscaler

Hi Team,
we are having all clouds : AWS, GCP and Azure and a lot of subnets due to which a lot of AppSeg and policies configured but one issue

for any cloud we use to check the connectivity for any custom port using telnet from forticlient but from Zscaler its getting connected to all the ports.

please help with a solution.

I want telnet to show connected to only ports which I have allowed from AppSeg

For example
above telnet I did when Zscaler was connected and below when not connected, also this port is not allowed for this IP. Checking it from my personal laptop at home.

 08/03/2022   17:37.02   /home/mobaxterm  telnet 172.20.2.83 9999
Trying 172.20.2.83…
Connected to 172.20.2.83.
Escape character is ‘^]’.
Connection closed by foreign host.

 08/03/2022   17:44.15   /home/mobaxterm  telnet 172.20.2.83 9999
Trying 172.20.2.83…

 08/03/2022   17:47.28   /home/mobaxterm 

Hi Vishal,
This might be because of your application segments configuration.
Review the ZPA logs and see , which application segments and policies are triggered when you access those destination.

Regards
Ramesh M

Hi Ramesh,
Thanks for your reply. but I checked and tested it with a lot of IPs and tested it for a day.

My finding is:
Telnet will say connected for all private communication allowed in all ports(Ports allowed or not does’nt matter).

Also If Port is allowed then logs gets generated but if port is not allowed then it says connected but logs are not getting generated for that.

ZPA Client Connector will intercept and terminate all TCP ports locally. This is necessary for the Client Connector to understand if there is a corresponding policy and matching application segment port.
If the app segment port does not exist then the connection would be dropped. If the app segment port exists, then the policy would be evaluated - if permitted, then the connection would be established to the server (through the app connector) otherwise the connection is dropped.

e.g. App Segment = server.company.com:80

telnet server.company.com:22
server.company.com resolves to 100.64.1.1 locally
Connection would be “established” to 100.64.1.1:22
Locally client would “see” port 22 as the application port.
Since 22 is not defined the connection is dropped.

telnet server.company.com:80
server.company.com resolves to 100.64.1.1 locally
Connection would be “established” to 100.64.1.1:80
Locally client would “see” port 80 as the application port.
Policy is evaluated in cloud.
Policy says “deny”.
Since policy is “deny” the connection is dropped.

telnet server.company.com:80
server.company.com resolves to 100.64.1.1 locally
Connection would be “established” to 100.64.1.1:80
Locally client would “see” port 80 as the application port.
Policy is evaluated in cloud.
Policy says “allow”.
Since policy is “allow”, path through app connector is decided
App Connectors check health of server.company.com:80 - shortest/most appropriate path is decided
mTunnels established from Client Connector to App Connector
TCP Connection from client to application established to port 80

It’s also worth noting - in the first example the connection to port 22 is blocked at the client. Logs for “drop” are stored locally in ZCC logs.
In the 2nd and 3rd example, the allow/deny is logged both at the client and in the cloud (since the connection/policy is applied in the cloud)

2 Likes

Absolutely, I totally agree with this point.
if connection is not allowed on certain port then the connection is getting blocked or terminated.

but as a end user I am seeing telnet connected in my system.

now as admin I will be able to confirm form logs whether comunication happened or not
but if any engineer tests it then it will always show connected to him because he cant access Zscler dashboard…

so my prime motive here is if a port in not allowed then while doing telnet it should fail instead of giving false message as connected.

Consider Zscaler at this point is behaving similar to an NGFW with delayed binding. The connection is accepted, and we need to see payload to make a decision, in some respects. Therefore all ports will get accepted, but unopen ports subsequently get dropped.

What is the usecase for a user making a telnet? For example - a user is unable to get to a webserver through ZPA - should they be telnetting to it to test for the connection? A better way would be to perform a CURL/WGET, which not only opens the connection, but makes a request and expects a response.
Similarly - if the user does telnet to port 80 on the webserver, ZPA would intercept. it the user issues a “GET / HTTP/1.1” then the server should send some response. If the user opens a telnet to port 81, ZPA would intercept - if the user then issues a “GET / HTTP.1.1” the connection would get dropped (in fact it would likely drop the moment the users sends any content".
The TCP connection would be accepted, once some payload is sent, the connection should get dropped.

we have our infra spread across all clouds
as for security reasons we are managing access from Firewall policies of clouds, NSGs, On-Prem-FW

plus a lot of applications running on multiple ports
due to security we are allowing on required ports from source to destination not all the ports.

so If any requirement is coming to us for allowing any communication then we will allow certain port from source to destination coud be via IP or Subnet or Tag or Service Account anything

in order for engineer to test the connection is success from our side or sometimes engineer also do telnet buy loggin in to source VM and telnet
to see if comunication is happening now or not

if it will always say connected then we would need to find other way to test it

The current implementation will always accept the connection, and will eventually timeout the connection when it’s invalid.
We would need to implement an enhancement request to send a RST packet in the event of an invalid connection, which would give you what you need.
Would you be able to open a support ticket, and request an Enhancement Request for this? The support ticket is necessary to capture account details, and specifics about the requirement to tie to your account.

In the meantime, sending some data in a payload after the connection is established, would result in the connection being dropped. It’s not matching what you’re doing today, but it is how the product is currently designed to work.

Noted, Thanks
will check with Support team for this