Why Did Strict IP Address Check Break this VPN?

Reply
Highlighted
L2 Linker

Why Did Strict IP Address Check Break this VPN?

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!

L7 Applicator

Re: Why Did Strict IP Address Check Break this VPN?

@ms.jzam,

What IP address were you sending to from within that tunnel? If I had to harbor a guess, the IP in question is technically not valid if you follow RFC 1918. 

L2 Linker

Re: Why Did Strict IP Address Check Break this VPN?

@BPry

 

IKE Gateway Local IP Address 216.1.x.x Peer IPA 199.79.x.x

 

IPSec Tunnel used Proxy ID which was Local 172.16.2x.x (Internal Server IP of 10.x.x.x was NATd) Remote 128.1.2xx.x

 

L2 Linker

Re: Why Did Strict IP Address Check Break this VPN?

BUMP

L4 Transporter

Re: Why Did Strict IP Address Check Break this VPN?

@ms.jzam

 

Same here I had to take zone protection off of my untrust zone cause it was breaking my VPN. I will have to try deselecting strict IP check and see if it fixes my issue

L2 Linker

Re: Why Did Strict IP Address Check Break this VPN?

@jdprovine  Let us know what you find!  If it does fix the issue, that's a much better place to be than disabling the whole ZP policy.

 

Hopefully we can get some progress on understanding the root cause behind the issue.

L4 Transporter

Re: Why Did Strict IP Address Check Break this VPN?

@ms.jzam

 

I have a ticket in with TAC about it and so far they told me that it wasn't likely the cause of my VPN breaking though yesterday I was able to repeat the issue by merely enabling Zone protection. I would be very interested to see why the strict IP address cause the issue. TAC also advised me to turn on spoofing IP address, which did not work.

L2 Linker

Re: Why Did Strict IP Address Check Break this VPN?

@jdprovine

 

I would reccommend taking the same steps that I did in order to get a clue as to the cause.  Include your VPN tunnel network/interface in a packet capture filter, and also your WAN interface where the VPN traffic is coming into.  

 

clear logs and packet filter

debug dataplane packet-diag clear all

debug dataplane packet-diag clear log log

 

enable debug

debug dataplane packet-diag set log feature flow basic

debug dataplane packet-diag set log on

debug dataplane packet-diag set log off

debug dataplane packet-diag aggregate-logs

 

review logs

less dp-log pan_packet_diag.log

 

clear your vpn tunnels and see if interesting traffic reestablishes them

clear vpn ike-sa 

clear vpn ipsec-sa

 

check and configure your packet filter

debug dataplane packet-diag show setting 

*was easier for me to configure the packet filter in the WEB-UI

 

check for vpn sesssions

show session all filter source X destination X

show vpn flow

*pay attention for encap and decap byte increase

 

check the details of the specific traffic session

show session id X

 

show results of the packet filter

show counter global filter packet-filter yes delta yes

 

 

There is probably a better order to running these commands, but this is everything I used to try and get to a resolution.

L3 Networker

Re: Why Did Strict IP Address Check Break this VPN?

There may be something in your Zone Protection Profiles that is configured other than what you are intending.  For example out of order packets or asymetric routing (just examples).

From the CLI you can type out these commands and it will give you a good config dump of what your profiles look like.  It may help to sanitize them and paste them for people to take a look at.

pa-firewall> set cli config-output-format set   (this sets the way the output will be displayed and only lasts the current session)

pa-firewall> configure

pa-firewall# show network profiles zone-protection-profile  (this will display the profiles in line format, not xml)

 

I try to use this to make sure what is being put in is actually doing what I want (if anyone remembers back in the cisco "gui" days *cough*pix*cough*).

L2 Linker

Re: Why Did Strict IP Address Check Break this VPN?

@BrianRa

 

ran the commands as you indicate but received no output:

 

(active)> 
(active)> set cli config-output-format set
(active)> configure
Entering configuration mode
[edit]                                                                                                                                            
(active)# show network profiles zone-protection-profile 
  <name>   <name>
  |        Pipe through a command
  <Enter>  Finish input

(active)# show network profiles zone-protection-profile 
set network profiles zone-protection-profile 
[edit]                                                                                                                                            
(active)# show network profiles zone-protection-profile ZP_DEFAULT_OUT
[edit]                                                                                                                                            
(active)#



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 Live Community as a whole!

The Live Community thanks you for your participation!