Why Did Strict IP Address Check Break this VPN?

[ms.jzam]

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!

[ms.jzam]

Ok that's two confirmations on fixing the issue.  I think this deserves to be bumped until we can sniff out a solid understanding of what's happening here.

BUMP!

[BPry]

@ms.jzam,

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. 

[ms.jzam]

@BPry

Happy to provide more detailed configuration for any attempts at duplicating the issue.  What would be needed?

[BPry]

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. 

[ms.jzam]

@BPry  I tried to find a DM feature, don't think there is one.  Happy to continue over email.

[BPry]

@ms.jzam,

brandon.pry@bpcoding.net

[jdprovine]

@BPry 

Brandon if you read my replies it broke my VPN access as well

[BrianRa]

Has anyone opened a support case on this?  It may be a bug they need to look into.

Could be versions with specific configs that are not working together.  That kind of stuff happens sometimes.

Brian

[ms.jzam]

I had a case open, once the issue was resolved they closed the ticket.

[Ben-Price]

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?

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008U3FCAU&lang=en_US%E2%80%A...

Thanks in advance.

[BPry]

@Ben-Price,

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.

[Ben-Price]

@BPry sorry to clarify, my local VPN IP address is a public IP address (220.x.x.x) assigned to a loopback interface, not a loopback address e.g. 127.0.0.1.

Does strict-IP-address check, still affect a loopback interface in the above scenario? The above scenario was working pre update.

[JohnWiktorski]

HI,

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 ?

[Ben-Price]

@JohnWiktorski No I haven't raised it with TAC. My client was able to disable the strict IP check and complete their upgrade path. I am waiting for them, to test on 10.1.3 and see if the issue remains.

[JohnWiktorski]

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
address.
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.