About dshue

dshue · ‎04-11-2014

Yup, same problem. We are running 5.0.11. • 60201—In a HA Active/Active setup, an IPSec key renegotiation timing issue caused the new IPSec session to be set to DISCARD until the next key renegotiation. This caused traffic loss until the next tunnel key renegotiation. I'm waiting for the 5.0.12 release though.

dshue · ‎04-08-2014

Have you had any issues with 6.0.1?

dshue · ‎04-08-2014

Thank you jdelio, I think you nailed it! We are at 5.0.11 and just upgraded to that a week prior to implementing HA. I've had a support case open since starting with Active/Active. They responded today that it is most likely they bug you are talking about but I'm reluctant to upgrade to 6.0.1 however. From the 6.0.1 Release Notes - Resolved Issues • 60201—In a HA Active/Active setup, an IPSec key renegotiation timing issue caused the new IPSec session to be set to DISCARD until the next key renegotiation. This caused traffic loss until the next tunnel key renegotiation.

dshue · ‎04-08-2014

I'm also gonna jump in on this. Been Active/Active for the past 3 - 4 weeks and even leaving Site2Site VPNs alone I'm still fighting with strange issues with tunnels not re-keying properly and dropping for the duration of the key lifetime. To the best of my knowledge, to make tunnels and portals work across both devices you will need to use Floating IPs. This will enable the two devices to sync these tunnels and portals. Although, that still hasn't worked for me with all my devices yet. Another thing to consider is that you have to position the PAs where they can answer a layer 2 arp request as this is how Floating IPs have to work and something that completely floored me. If you are using routing protocols on your PAs to bring traffic in from your ISPs, Floating IPs will not work in this case as traffic destined to a peer device will not be forwarded over HA3. See my post below for more detail. Active/Active Floating IP/Traffic Forwarding Problem In addition to document from Steven, here is another document that helped me. High Availability Synchronization This is about the extent of the documentation provided. There are several articles and discussions out there, but beware that Steven is absolutely correct. You will be fighting this battle much on your own and documentation is scarce. It took talking to three techs to determine my Floating IP problem only to find out it "just wasn't designed to work that way". Here is my latest post... seems to be pretty straight forward but PAN won't really discuss this further until I change my HA config is set to always use Primary as session owner and session setup so I've turned to the community for help troubleshooting. Active/Active & IPSec Trouble I will add that as far as the normal transit traffic goes, it does work and so far works great. I'm using OSPF internally and BGP externally and HA3 takes care of any asymmetric packet flows as promised by PAN. Good luck, and if you can avoid Active/Active... avoid it.

dshue · ‎04-07-2014

After implementing HA Active/Active, we left S2S VPN tunnels alone. Ultimately no changes to IKE Gateways. The S2S terminate to a /30 address that is statically routed from the ISP to ethernet1/12 on the active-primary. Tunnel interfaces and their routes are identical on both primary and secondary, IKE Gateways are NOT synced as this is just an IP assigned to the 1/12 interface on the primary side. OSPF on the internal LAN side, HOWEVER, supplied static routes for the remote sites to only route to primary device. Secondary should never be session owner. Session Owner = First Packet Session Setup = ip-modulo Phase 1 and Phase 2 seem to come up fine. Communication is established and devices can talk fine. However, the key lifetime is set for 2 hours. Throughout the day, the remote side will stop responding at key expiration. It appears that a new negotiation is started and completed, however for the two hour key time the VPN tunnels will not pass traffic. This doesn't happen every time it negotiates, and I can seem to locate a pattern. The best lead that I have right now is that the return traffic from the remote side is being discarded due to the flow being in a discard state. I can also see where the 'decap packets' in the vpn flow will not increment. I've looked through the ike debug log and don't really see anything going on there during this state of limbo. Phase 1 appears to be up, phase 2 SAs seem to be up, but for some reason the firewall is rejecting these return packets and I cannot determine why. If can clear phase 1, and the flows and it will pick right back up. Other option is to just wait for Phase 1 to timeout and re-key. These devices were working fine prior to HA to the best of my knowledge. Any help would be greatly appreciated! == Apr 07 09:33:26 == Packet received at ha_ingress stage Packet info: len 1532 port 49 interface 49 vsys 1 wqe index 228383 packet 0x0x8000000416f718e0 Packet decoded dump: L2: 00:1b:17:3c:21:31->00:1b:17:c8:6f:31, type 0x7261 L3 binary dump: 40 bytes 00000000: 80 02 00 1b 00 1b 17 3c 21 1b 00 16 4d 6e a6 8c .......< !...Mn.. 00000010: 08 00 45 00 05 dc c8 d9 40 00 36 06 ff 43 c7 1b ..E..... @.6..C.. 00000020: 4e b8 41 29 20 02 00 50 N.A) ..P ...skipping... IP: 166.xxx.xxx.xxx->71.xxx.xxx.xxx, protocol 50 version 4, ihl 5, tos 0x00, len 120, id 663, frag_off 0x0000, ttl 49, checksum 57440 L4 binary dump: 16 bytes 00000000: f3 46 fb c0 00 00 01 3c 19 ac 55 94 f5 04 3f a5 .F.....< ..U...?. Flow lookup, key word0 0xf346fbc000023200 word1 0 Flow 211818 found, state 3 Packet dropped, flow in discard state Session 105909 c2s flow: source: 166.xxx.xxx.xxx [untrust] dst: 71.2.234.230 proto: 50 sport: 62278 dport: 64448 state: DISCARD type: FLOW src user: unknown dst user: unknown s2c flow: source: 71.xxx.xxx.xxx [untrust] dst: 166.142.205.229 proto: 50 sport: 64448 dport: 62278 state: DISCARD type: FLOW src user: unknown dst user: unknown start time : Mon Apr 7 09:28:39 2014 timeout : 60 sec time to live : 58 sec total byte count(c2s) : 103868 total byte count(s2c) : 0 layer7 packet count(c2s) : 722 layer7 packet count(s2c) : 0 vsys : vsys1 application : ipsec-esp rule : ALLOW_IN_VPN session to be logged at end : True session in session ager : True session synced from HA peer : False session owned by local HA A/A : True layer7 processing : completed URL filtering enabled : True URL category : any session via syn-cookies : False session terminated on host : True session traverses tunnel : False captive portal session : False ingress interface : ethernet1/12 egress interface : ethernet1/12 session QoS rule : N/A (class 4) session tracker stage deny : host service session tracker stage l7proc : ctd app has no decoder

dshue · ‎04-07-2014

Gonna answer this one myself. After talking with PA support, traffic destined to a Floating IP through it's peer was never designed to go through HA3 packet forwarding. It is assumed that the owner of the Floating IP would always get the traffic first via ARP and the virtual mac. In my situation, I have two /29 that communicate with the upstream ISP routers and I was attempting to use one of my /24 (BGP routed) IPs as a floater. I was wanting to use the Floating IP as a signal point of entry for S2S VPNs. Because of asymmetric routing and BGP, there was no way to guarantee that the Floating IP owner would 100% always receive the packet. I'm working around this issue for now and just using a /30 that is ALWAYS statically routed to one device. But I'm still having IPSec VPN problems, but that's another post. Hope this helps someone.

dshue · ‎03-26-2014

Hello All, I have a support case open with PAN but I thought I would query others smarter than I. 2 x PAN-2020 Recently enabled HA Active/Active BGP on External/Currently ONLY Static Inside to Active-Primary device (0.0.0.0/0 -> Active Primary) Session Owner = First Packet (only going to be Active-Primary right now do you static route) Session Setup = IP-modulo Floating IP - x.x.x.128 -> active-secondary preferred Floating IP - x.x.x.129 -> active-primary preferred 2 x GlobalProtect Portals - each using respective Floating IPs I first noticed an issue when configuring an SSL-portal using a Floating IP. It seems as though only the session owner can communicate with it's preferred floating IP. Example 1: Client A -> 0.0.0.0/0 -> active-primary -> https://x.x.x.129 = WORKS! Client A -> 0.0.0.0/0 -> active-primary -> https://x.x.x.128 = FAIL Example 2: Client A -> 0.0.0.0/0 -> active-secondary -> https://x.x.x.129 = FAIL Client A -> 0.0.0.0/0 -> active-secondary -> https://x.x.x.128 = WORKS! From these examples, only the session owner can communicate with its respective floating IP. I have also seen where IPSec tunnels that terminated to ONLY the Active-Primary are having intermittent issues with communicating with internal hosts. All outbound and inbound NAT'd traffic seems to be doing wonderfully, just sessions that terminate to the firewalls themselves seem to be having issues. I have a drawing that I can share if anyone shows interest in helping me troubleshoot. I'm at a loss and been at if for 4 days. TIA!

dshue · ‎12-12-2012

Has anyone come up with a good solution for this? The work around would work, just wondering if anyone else came up with something.

dshue · ‎12-30-2011

A few of my rules allow for certain individuals (by way of User-ID) access to download EXE and access most any application. This of course works fine for PCs that are joined to the domain which makes up 99% of our PCs. However, for that 1% that are not on the domain, what's the best way for an individual to optionally supply the proper AD credentials to allow them these elevated privellages if they so choose to need them?

dshue · ‎10-10-2011

I'm working on developing my rule base prepping for implementation. I'm noticing that alot of my inbound rules, ie: Where the destination in an address object with my internal IP. Now of course I have NAT rules to statically NAT the traffic inbound and outbound. Outbound (handled by another rule), the log shows the internal IP address as the source IP. However, for inbound traffic the log shows the destination IP as the NAT address and does not catch on the rule above. Looking at the details of the log it shows that it is being NAT'd correctly and what not. Is this normal behavior? Do I need two objects (even though I know I don't need an object) for each IP, an external object and an internal object? Should the rule above contain the destination object of the external IP? Just FYI, this behavior didn't always seem to be the case. As I went back through my logs I saw where it look as though this rule was catching as it should have been. Recently I went from one VR to three VRs to handle redundant ISPs. Could this be the reason we see it logged this way? TIA, Daniel

dshue · ‎09-27-2011

YES, you read it right! DIAL-UP speeds! Unfortunantly we have some users that have old 1x and iDEN air cards that are probably slower than some Dial-Up speeds. It is what it is I suppose. Our old IPSEC vpn (Check Point) client really didn't complain about it much, it was slow but still connected. We are moving our users over to the Palo Alto SSL VPN, and we're not having alot of luck with these slow devices. Broadband users, no problem! With these iDEN devices, I have the client installed (manually from the MSI), I can login, get the spalsh screen, get the client status window... 'Connecting......' , 'connecting.......', 'Disconnected'. It says it can't contact the server. I know it's related to the slow connection, but is there anything I can do to prevent a timeout or whatever else might be happening here? Is there an alternative to the Palo Alto client that I can use and go back to an IPsec tunnel? TIA

dshue · ‎09-26-2011

The post is a little old, but for future folks... Add a PBF rule, preferably at the top, to do a 'no-pbf' on your Peer networks as the destination. PBF takes presedence over routes. Destination - 'remote network' = 'no-pbf'

Member Since	‎05-25-2011 12:17 PM
Date Last Visited	‎04-23-2018 03:40 PM
Posts	14
Total Likes Received	1

Online Status	Offline
Date Last Visited	‎04-23-2018 03:40 PM

About dshue

Re: VPN & SSL VPN questions - A/A cluster

Re: Active/Active & IPSec Trouble

Re: Active/Active & IPSec Trouble

Re: VPN & SSL VPN questions - A/A cluster

Active/Active & IPSec Trouble

Re: ISP redundancy issues

Re: Tips to improve mgnt tasks in a PA-2020

Re: Tips to improve mgnt tasks in a PA-2020

Re: Pa-2020 and number of rules

Re: PANOS 6

Re: VPN & SSL VPN questions - A/A cluster

Re: Active/Active & IPSec Trouble

Re: Active/Active & IPSec Trouble

Re: VPN & SSL VPN questions - A/A cluster

Active/Active & IPSec Trouble

Re: Active/Active Floating IP/Traffic Forwarding Problem

Active/Active Floating IP/Traffic Forwarding Problem

Re: Possible to both block and upload files to WF in same file blocking profile ?

Captive Portal as an option

Question about Security Policies and NAT

SSL VPN over Dial-Up Speeds

Re: ISP redundancy issues

Network Security

Cloud Security

Security Operations

About dshue