Strict IP Address Check after 9.1.12

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

Strict IP Address Check after 9.1.12

L3 Networker

Customer upgraded to 9.1.12 and after that it was noticed that for some of the zones, traffic was dropped. During debug,it was concluded that reason is Strict IP Address Check in the Zone Protection Profile:

"flow_dos_pf_strictip 1 0 drop flow dos Packets dropped: Zone protection option 'strict-ip-check'"

In the 9.1.12 release notes it is noted:

Fixed an issue where packed-based zone protection settings (such as Strict IP Address Check) were not applied to return traffic.

So one may think it is a bug that was fixed and customer has his routing table messed up, but after checking - routing seems to be fine. Traffic was dropped even from outside interface (with default route) to GlobalProtect interface which is loopback on the device. Same for Outside <-> DMZ traffic, which is directly connected interface, so essentially no dynamic/static routing is done there.

Behavior can be confirmed and reproduced by turning on and off strict IP check in the zone protection profile.


Can anyone confirm this? Checking before opening TAC case.


Edit a bit later: PBR is not configured.


L4 Transporter

Hi @nikoo


I have just run into the same issue when going along the upgrade path to 10.1.3, when we hit 9.1.12, GP VPN and IPsec VPN both broke. Turned off 'strict-IP-check' on the internet zone protection profile and both VPNs are working again. Haven't re-tested on 10.1.3 as yet.

Only thing I noticed was our local VPN IP address is on a loopback address in the internet zone, the below KB article seems to suggest that 'strict-IP-check' can cause an issue with loopback addresses, in saying that not sure why it only just became a problem with 9.1.12.


Did you end up raising this with PA support? or find a solution here?



Hi @Ben-Price,


I noted that article as well, but my understanding loopback address was mean to be given the context along with broadcast, network, etc. addresses. Not sure if my guess was correct, though.


Currently I have not opened a case, would still like to check the effect on traffic passing via the firewall - as that was seen in the customer case as well, so it did not seem to be related to Palo Alto assigned IPs only. Was hoping that someone from PA may confirm this behavior as that would mean less guessing and poking around.

As for now left the workaround - strict IP check disabled.


L4 Transporter

@nikoo OK thanks for the feedback, I think you might be right regarding the meaning of loopback address outlined.


@BPry Are you able to comment here on the above issue me and @nikoo have experienced?

L0 Member

Experiencing similar behavior. Suddenly traffic across a WPN was being dropped and did not even have a ZPP on it. Running 9.1.12.


Followed this KB to find it which was helpful. Unchecked strict IP check and returned to normal.


L4 Transporter

@nikoo @JesseCurtis2020 My client has updated there firewall to PAN OS 10.1.3. I have asked them to re-enabled the strict IP check and see if the issue remains on that version.

L3 Networker

@JesseCurtis2020, ZPP most likely was assigned to public interface, as I had similar behavior with VPN traffic being dropped and sounds like the same issue, yeah.

@Ben-Price, that can be good to know for future reference. In my case though customer is running PA-3xxx series, so no possibility to go above 9.1.

L0 Member

>ZPP most likely was assigned to public interface,


Yes, this was the case and what I figured as well. 

L4 Transporter

@nikoo @JesseCurtis2020 This has been identified as a bug and PA have now updated the PAN OS 9.1.12 known issues documentation outlining the bug (PAN-186937).



  • 8 replies
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!