TCP 3 way handshake success (telnet) but data doesnt flow through

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

TCP 3 way handshake success (telnet) but data doesnt flow through

L1 Bithead

Information
Source : 10.1.1.1
Destination (example) 202.181.200.188
Destination Port : 8443

Client is running on port based firewall

 

Issue (Technical not an issue just the firewall behavior) :

3 way hand shake success which mean telnet port 8443 is success but the actual data doesnt go through and with deny log record at traffic log. Client is questioning why TCP hand shake is success.


Rules 1 : Permit 10.1.1.1 destination any application ICMP, PING and traceroute
Rules 2 : Deny IP ANY ANY

Based on debug flow the traffic hit the Rules 1 due to PING application as it doesnt have any standard port configure. 3 way hand shake is success but with the debug ( CP-DENY TCP non data packet getting through)


Question 1 :  why the telnet is successful ?

Question 2 : where is the 2nd time policy rerun again to recheck the destination port?
Question 3: where to check policy id based on the debug log (example : first packet policy id 3)
Question 4 : how to interpret following app id 

(2022-05-09 16:37:18.531 +0800 debug: pan_appsig_process_result(pan_app_sigs.c:669): Process app signature [oridus-nettouch] rule [nettouch-1], dir [cts]
2022-05-09 16:37:18.531 +0800 debug: pan_appsig_process_result(pan_app_sigs.c:695): slot is 0
2022-05-09 16:37:18.531 +0800 debug: pan_appid_check_header_match(pan_app_sigs.c:299): Header match: app rule [nettouch-1] matches
2022-05-09 16:37:18.531 +0800 debug: pan_appid_check_string_match(pan_app_sigs.c:528): MATCH_IN_ORDER: app rule [nettouch-1] match
2022-05-09 16:37:18.531 +0800 debug: pan_appid_process_pkt_done(pan_appid_proc.c:1897): Packets seen by appid: 1
2022-05-09 16:37:18.531 +0800 debug: pan_appid_process_pkt_done(pan_appid_proc.c:1903): Bytes [cts] seen by appid: 1)

4 REPLIES 4

L2 Linker

Hi VLim,

 

Keep in mind you'll need to add the "telnet" application that security policy also for telnet traffic to match it.

 

Separately, that "CP-DENY TCP non data packet" may imply the next packet after handshake is being blocked as part of Zone Protection or global firewall TCP Settings.

Kiki

hi Kiera,

 

Actually I wanna block the port 8443 but the telnet is successful.

 

Cyber Elite
Cyber Elite

Hi @VLim ,

 

What is the service set to in rule 1?

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

Cyber Elite
Cyber Elite

Hi @VLim ,

It sounds the answer is right there in your question - "traffic hit the Rules 1 due to PING application as it doesnt have any standard port configure"

- Even that Palo Alto firewall is pretty smart, it doesn't re-invet how networks work .So even if you still allow applications not ports don't forget that how networks works

- TCP 3-way-hand shake doesn' provide any information about the about the application used or any of the above layers. So how do you expect for the firewall to identify that you want to use facebook on the first TCP SYN -it cannot.

- Using app-id firewall will need to allow some traffic to pass in order to identify the actuall application. For example web browsing - firewall will allow the TCP hanshake to complete and wait for the firsts packets that transfer actuall data and will see that it countains HTTP GET

- If you have noticed when creating firewall rule for service (basically ports) you can specify: application-default, any or something specific. Application-default is related to the application signatures that FW is using to identify applications. If you go to Objects -> Applications and open details for any app, you will notice that each app definition contain standard ports. This is what FW expect to be used for such application.

- So when you allow web browsing app with application-default service, firewall will again need to allow the TCP handshake to establish in order to get the HTTP traffic and identify it as web browsing, but it will allow only TCP traffic over ports 80 and 8080, because those are the only ports that FW is expecting to be used for web traffic.

- If you use "any' for service, firewall will allow any session - no matter which port is used, because you simply tell it that you expect given application on any port.

 

Not sure what debug have you run for the above output, but if you are insterested to go deeper I would suggest you to check this traning on how to run Debug level packet tracing - https://beacon.paloaltonetworks.com/student/path/1028945?sid=4a4b7cef-fe1b-4109-a308-5f8e3e317138&si...

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!