topic Re: TCP 3 way handshake success (telnet) but data doesnt flow through in General Topics

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

VLim — Mon, 09 May 2022 09:29:05 GMT

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)

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

KieraMitchell — Mon, 09 May 2022 09:58:21 GMT

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.

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

VLim — Mon, 09 May 2022 10:27:18 GMT

hi Kiera,

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

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

TomYoung — Mon, 09 May 2022 17:37:30 GMT

Hi @VLim ,

What is the service set to in rule 1?

Thanks,

Tom

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

A_Astardzhiev — Mon, 09 May 2022 21:33:37 GMT

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&sid_i=0