Symptoms
When a security policy is defined to deny traffic to a particular destination, you would see that the Palo Alto Networks firewall would still permit the 3-way handshake to go through.
Example:
user@host> show running security-policy
PANOBLOCK {
from any;
source any;
source-region none;
to any;
destination 104.244.14.253; <<< Specific Destination
destination-region none;
user any;
category any;
application/service any/any/any/any;
action deny; <<< Simple Destination IP based deny
icmp-unreachable: no
terminal no;
}
user@host> show session id 10622
Session 10622
c2s flow:
source: 192.168.15.41 [L3-Trust]
dst: 104.244.14.253
proto: 6
sport: 49460 dport: 80
state: ACTIVE type: FLOW
src user: unknown
dst user: unknown
s2c flow:
source: 104.244.14.253 [L3-Untrust]
dst: 10.129.72.15
proto: 6
sport: 80 dport: 17747
state: ACTIVE type: FLOW
src user: unknown
dst user: unknown
start time : Thu Oct 27 19:52:53 2016
timeout : 90 sec
time to live : 76 sec
total byte count(c2s) : 672
total byte count(s2c) : 62
layer7 packet count(c2s) : 5 <<< Packets Permitted
layer7 packet count(s2c) : 1 <<< Packets Permitted
vsys : vsys1
application : web-browsing
rule : PANOBLOCK
session to be logged at end : False
session in session ager : True
session updated by HA peer : False
address/port translation : source
nat-rule : NAT_OUT(vsys1)
layer7 processing : enabled
URL filtering enabled : True
URL category : not-resolved
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : ethernet1/4
egress interface : ethernet1/3
session QoS rule : N/A (class 4)
end-reason : policy-deny <<<< Policy Action Deny
You can see that though the traffic that it is matching the Deny Policy Packets and are being sent.
Packet Captures would also reveal that the packets are being actually sent.
Diagnosis
This occurs if the traffic matches a configured Captive Portal Policy.
Example:
user@host> show running captive-portal-policy
TEST {
from L3-Trust;
source any;
to L3-Untrust;
destination any;
category any;
service [ tcp/any/80 tcp/any/8080 ];
action web-form;
terminal yes;
}
When you run packet-diag with flow basic set, you would be able to note that the traffic matches the Captive portal policy:
Example:
== 2016-10-27 19:52:53.510 -0700 ==
Packet received at slowpath stage
Packet info: len 62 port 19 interface 19 vsys 1
wqe index 229362 packet 0x0x8000000037b900e6
Packet decoded dump:
L2: 00:50:56:93:51:10->58:49:3b:9d:a6:13, type 0x0800
IP: 192.168.15.41->104.244.14.253, protocol 6
version 4, ihl 5, tos 0x00, len 48,
id 991, frag_off 0x4000, ttl 128, checksum 44838
TCP: sport 49460, dport 80, seq 1732543400, ack 0,
reserved 0, offset 7, window 8192, checksum 28395,
flags 0x0002 ( SYN), urgent data 0
TCP option:
00000000: 02 04 05 b4 01 01 04 02 ........
Session setup: vsys 1
PBF lookup (vsys 1) with application web-browsing
Session setup: ingress interface ethernet1/4 egress interface ethernet1/3 (zone 8)
NAT policy lookup, matched rule index 0
2016-10-27 19:52:53.510 -0700 debug: __pan_cfg_cp_policy_lookup(pan_cfg_cp_policy.c:154): Returned rule index is 0Pa
cket matched captive portal rule, action 1 <<<< Matching Captive Portal Rule
Then we see that the traffic is permitted through an internal security policy for Captive Portal session traffic:
Policy lookup, matched rule index 0, is special <<< Hitting a Special Rule 0
Allocated new session 10622.
When any traffic to port 80 or 8080 (443 if decryption is enabled), matches the Captive Portal policy it bypasses configured security policy lookup and permits the 3-way handshake.
This behaviour is due to the fact that, in case of captive portal, the Palo Alto Networks firewall would present a "Redirect" or a "web-form", by hijacking the ongoing "http" session. The 3 way handshake would be permitted, and the Palo Alto Networks firewall would intercept the "http-get" request and send the redirection.