Skip to main content

TCP/IP port tests or scans produce inaccurate results

Aaron
  • Updated
In this article:
    Applicable to:
    • Twingate Component: Client, Connector
    • Third Party: Any network port testing or scanning tools such as Nmap, telnet, or netcat.

    Overview

    Running port connectivity tests against Twingate Resources from the Twingate Client doesn't provide real-life results. This article will help to provide understanding as to how port tests or scans, such as Nmap or telnet, operate with Twingate.

    Analysis

    Twingate restricted port

    One can review how the Twingate Client handles traffic by the below. 

    1. In the below example we have the Twingate Resource of stor​ with port restrictions to allow only TCP/UDP 8001​ and ICMP traffic.
    2. Enable debug level logs for the Twingate Client (if not already).
    3. Run an Nmap scan to the Twingate Resource.
    4. The scan will return several ports that are open, when in fact they are not.
    5. Review the logs and see that the traffic flows are not allowed, and therefore, not forwarded. This can be further confirmed by a packet capture if necessary.
    2022-01-17 10:33:59.5408 [DEBUG] <no type>.log [SDWAN] Core::authorize_hydra_viper_flow: route_id=192 conntrack_proto=TCP fqdn=stor tuple=100.127.255.172:33020->100.96.47.92:7 
    2022-01-17 10:33:59.5408 [DEBUG] <no type>.log [SDWAN] match: no matching rule 
    2022-01-17 10:33:59.5408 [DEBUG] <no type>.log [SDWAN] Node[AN 6925]::authorize_hydra_viper_flow: new flow route_id=192 conntrack_proto=TCP fqdn=stor tuple=100.127.255.172:33020->100.96.47.92:7 does not match any policy, use bypass 
    2022-01-17 10:33:59.5408 [DEBUG] <no type>.log [SDWAN] operator (): rule stor:TCP[[8001]]:UDP[[8001]]:ICMP 
    2022-01-17 10:33:59.5408 [DEBUG] <no type>.log [SDWAN] is_protocol_port_allowed: protocol TCP, port 7 is not allowed

    Twingate unrestricted port

    One can review how the Twingate Client to the Twingate Connector handles traffic by the below.

    1. In the below example we have the Twingate Resource of 10.168.0.6 with no Twingate port restrictions applied.
    2. The Resource of 10.168.0.6 has a firewall rule that blocks port 5656. 
    3. From the Twingate Client test TCP port connectivity via curl -v telnet://10.168.0.6:5656 .
    4. A false positive will be returned: Connected to 10.168.0.6 (10.168.0.6) port 56556.
    5. Powering down the Resource 10.168.0.6 will still result in Connected to 10.168.0.6...
    6. If there is a single Connector deployed for this Resource, powering it down will finally result in the connection to return failed.

    Summary

    When Twingate restricts ports for a resource, traffic matching the user's available Resources will be intercepted by the Twingate Client. The Twingate Client will then determine which traffic to forward based on the defined Resources and the underlying ruleset. As a result of this interception of traffic, Nmap scanning from the Twingate Client will result in seeing ports that are unexpectedly open, when in fact they are not.

     

    When Twignate doesn't restrict ports, the Twingate Client will leverage the Twingate Connector to proxy the connection. The initial TCP/IP connection will take place against the Connector, as such, a false positive is returned.

     

    Testing connectivity to Twingate Resources from the Twingate Client should not be dependent on TCP/IP port tests/scans. Tests should be performed against the applicable application session, such as interactive SSH or RDP client connections being established, or HTTPS connections returning a 200 response.

     

    Related articles