Rule to block TOR Application blocks all traffic directed to Internet

[Jacopo_Vigano]

Hello Community,

we have an issue when we try to block TOR application. We do a rule like the image reported below and put it on top of the rulebase:

 

But it seems that all Internet traffic is dropped by the rule named "Tor_Blocking".

 We see the Application is "Not-Applicable" on all log files. It seems PaloAlto cannot resolve properly the Applications involved.

At the moment we are not using SSL Decryption and we have PANOS 7.0.6 and Application Version 584-3342 on a cluster of PA-5060 appliances.

Do you have any idea to resolve this issue?

Let me know if you need any other information.

Thanks in advance.

Jacopo

[Transporter]

Hi,

Not-applicable

Not-applicable means that the Palo Alto device has received data that will be discarded because the port or service that the traffic is coming in on is not allowed, or there is no rule or policy allowing that port or service.
For example, if there was only one rule on the Palo Alto device and that rule allowed the application of web-browsing only on port/service 80, and traffic (web-browsing or any other application) is sent to the Palo Alto device on any other port/service besides 80, then the traffic is discarded or dropped and you'll see sessions with "not-applicable" in the application field.

Thnaks

[santonic]

Destination port in this case is 5671. Do you have any rule which would allow this port?

One explanation would be that it doesn't even start recognising app if this port is not allowed by any rule. Still unusual that it drops it with TOR rule, it should be by some default drop rule at the end.

But if this rule blocks http traffic on standard port as well and you have TCP 80 open somewhere (either by service or with web-browsing app) then it's very weird and wrong. 

[Transporter]

Hmm. I didn't read the question properly. I thought it just drops the TOR application. Can you create a rule any any and see if firewall will be able to determine application you are using. generate web or dns request to outside

[Jacopo_Vigano]

Hi All,

if I disable the "Tor_blocking" Rule, the application is identify correctly by other rules specified on the rule base and the traffic is accepted and goes to untrust zone.

Thanks.

Jacopo

[jambulo]

Im not sure why you're seeing this behavior. We have a similar rule and it works fine. Only difference is we have it set to App-Default for Service. Which should be fine because its "Standard Ports" are TCP/dynamic. You should give that a try.

[Jacopo_Vigano]

Hi @jambulo,

I'll ask customer to set application default as "service" and i'll update you.

What version of PANOS are you using?

Thanks.

Jacopo.

[reaper]

I'd also recommend changing the source zone from 'any' to 'trust' and instead of setting the negate for rfc-1918, to simply set the destination netwrok to 'any' (as there should not be any rfc-1918 ip addresses upstream and your ISP should drop these anyway)

[Jacopo_Vigano]

Hi All,

customer will try to change the rule in the next few days. I'll update you as soon as possible.

Thanks,

Jacopo.

[santonic]

Can you confirm that you have for example port 80 open somewhere in policy and that TOR rule blocks traffinc on that port anyway?

Even if it works with service set to application-default (which is all ports anyway in this case) I still think something is broken here and PA should be notified.

[reaper]

the destination port is 5671, the session id is 0 and the associated log is interzone-default (at the bottom of the log screenshot): this session is being dropped because there is no application rule that allows this traffic, but the tcp handshake is being allowed because the service in the TOR policy is set to any instead of application-default, that is also why the log is showing up because that rule has logging enabled

[santonic]

Yes, I know this session was port 5671. But he said all traffic to internet stops. So i was asking about a port 80 which is more likely to be allowed somewhere than port 5671.

TCP handshake didn't go through in this case as only 1 packet was seen, most likely SYN.

Application default port for TOR is TCP/dynamic. So no matter what the service setting is in the rule, PA will have to allow all TCP ports.

Ok, i didn't notice "interzone-default" in related logs so far. But even if this is a connection related to one of the sessions correctly recognised as TOR and dropped, it still doesn't explain why all traffic to internet stops. 

[reaper]

if the session was identified as Tor, the log should also indicate that... a show counter global could be useful to see if there is a system level drop reason, maybe a LAND attack due to some NAT rule we're not aware of... I tried replicating the config in my lab but can't get it to break