We have been working with TAC to find the cause of this issue where FTP client could no longer upload to external companies FTP server over the VPN tunnel. After many days, we started a packet filter on the Public Internet (WAN) interface, which is a different zone from the tunnel interface, and were still seeing drops due to "flow_dos_pf_strictip". We had previously disabled the zone_protection policy that was applied to the tunnel interface zone, and even though we did not see drops, the uploads were failing. When we finally did that packet filter on the WAN interface we saw the drops again due to the same reason "flow_dos_pf_strictip" and decided to remove the zone protection policy from the WAN interface. BOOM! FTP uploads succeed. Combing through the policy I saw the strict ip check option and removed it, then pushed the policy overwriting our revert. Everything still good.
We couldn't find the configuration change that put that feature in place (wish that function worked better in the Palo, or just knew how to use it better!) and reading the KB pages for that feature, I'm not sure why it was causing our traffic to be dropped.
Any help would be very much appreciated!
I would love to help on this but unfortenately I can't reproduce the issue at all. Unfortanetly the only way you can enable Packet Drop Logging is if your device is in Common Criteria (CCEAL4 Mode), which I doubt yours are; that would be something to check out though, because if they are you might get your why answer.
The exact ZP settings that you actually had selected at the time you ran into the issue; along with how you actually have the tunnel configured and the IP ranges being used on both sides. Then it would just be how your VPN was actually setup and configured. If you feel more comfortable sending this directly and not posting it on the forum just let me know and you can just email it over to me.
Hi @ms.jzam @BPry I am experiencing the same issue here. Updated the firewall to PAN OS 9.1.12 and the GP and IPsec VPN broke, disabled strict-IP-check in the outside zone protection policy and the VPN connectivity was restored. Did you ever find a resolution to this issue?
The only thing I noticed was the local VPN IP address is a public IP on a loopback interface in the outside zone. The below KB seems to suggest loopback addresses can cause issue with the strict-IP-check setting in a ZP profile?
Thanks in advance.
That's actually expected behavior if your using a loopback address. In general I don't have this option enabled on untrust/outside interfaces due to the prevalence of people using the interface address for things like IPSec and GlobalProtect.
|Strict IP Address Check||Select the checkbox to discard packets with malformed source or destination IP addresses. For example, discard packets where the source or destination IP address is the same as the network interface address, is a broadcast address, a loopback address, is a link-local address, is an unspecified address, or is reserved for future use.|
I have exactly the same issue, just updated from 9.1.9 to 9.1.13 last night, vpn failed. I removed zone-based protection and the tunnel access came back immediately. I figured out it was (strict ip check), I turned it off tunnel came back immediately. turned it back on and the tunnel failed. Did anyone raise a ticket with Paloalto recently on this ?
I got feedback from TAC, seemingly this obviously caused lots of issues.
PAN-186937 The firewall drops Encapsulating Security Payload (ESP)
IPsec packets that originate from the same firewall. This
behavior occurs when you enable Strict IP Address
Check in the Zone Protection profile (Packet Based
Attack Protection tab, IP Drop section) and the packet’s
source IP address is the same as the egress interface
Workaround: Disable the Strict IP Address Check option
in the Zone Protection profile. Alternatively, downgrade
to 9.1.11 or earlier or upgrade to 10.0.0 or later if you
want to enable the Strict IP Address Check.
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!