About TonyDeHart

It is still strange tho, so I would guess it may be related to the logging setting - does your rule log at session start, end or both.In combination to how those SSL sessions are ended - are they fully established or closed due to ageout, or not even completed. I would search the traffic logs filtering by rule name and application SSL and look at the log details - how the sesson end, is there traffic in both directions, was the log created at sesson start or end?    This is logged at the end and there are no "packets received" just "packet sent".  It does show reason for ending as "tcp-fin" so it doesn't appear to just be dropping or cutting it off unless I'm misunderstanding...just odd there is not a received.  It all seems to be some anomaly related to GlobalProtect. ... View more

I get the "ANY" service allowing all ports but it would seem that would apply only if SSL was implicitly allowed by one of the other applications which it is not.    Either way, there was a missed clue for me as to something else going on here and I did get an explanation from a Palo engineer with some references to KB and conversations here.   I've included a screenshot of the clue but it has to do with the Palo tracking GlobalProtect clients IP's and us using the same IP for our GP traffic as other traffic inbound. It is recognizing SSL traffic as possible GP traffic until it is thoroughly identified.  The screenshot included shows it NAT'ing traffic to destination port 20077.  I'm told the Palo is intercepting this and forwarding it to the management plane and once it is clear it is destined for GlobalProtect or not it applies the right rule to the traffic.   It still seems odd to me that this is the rule getting applied but it does eventually turn the traffic over to another rule in the logs.   Here some of the related info to this issue:   If a GlobalProtect Portal uses the same IP address as the traffic. The Dataplane knows which host IPs GlobalProtect is enabled on. Whenever the PAN-OS sees traffic on those IPs and the dport= 443 then it would changes the dport to 20077 and sent it over to Management plane. Once the firewall sees enough packets it then knows this isn't GlobalProtect traffic. Also: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClM1CAK https://live.paloaltonetworks.com/t5/general-topics/ports-used-for-paloalto/td-p/522816 https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0   ... View more

That is great news! Thanks.  I doubt highly the source port matters at all but I'll probably take a closer look at the logs and see what shows up soon on the ASA.  I'm still in discovery mode on some of this but this helps.   ... View more

Just as a follow-up to this, I did end up having a brief conversation with an engineer at Palo. While it SHOULD have worked, the suggestion was to add the interface to the NAT destination along with the Zone.  It is possible with only the Zone the firewall is not determining properly what subnet/interface needs the proxy ARP.  When I have time I may setup a set of test rules to experiment with. ... View more

What is interesting is step 2 of that document says:   Create a secondary IP address on the network of this new destination NAT IP or the IP itself. Example: If 70.1.1.1/24 is on Ethernet1/3 (Untrust), and destination NAT needs to be configured for 70.1.2.22, add either the IP address 70.1.2.22/32, or an IP in the network (70.1.2.1/24 for example) as a secondary IP on the Untrust interface. This will tell the firewall that this network exists on this firewall, and it will know how to route traffic properly.   That was what I thought should have worked as we had the subnet's interface configured but nothing alongside it worked in the same subnet without defining the address.  Unfortunately it isn't something easy to test in a live config so I'm sort of stuck with it at this point until I can get another testing window to troubleshoot more fully.  We had a small window for our ASA to PA migration and we were banging our heads against a wall until we added those addresses.   I appreciate the confirmation that at least it wasn't a misunderstanding and simply something that should have worked but wasn't.  I'm on 10.1.9-h1 too and I've not seen anything bug related like this in the release notes.  I've not opened a ticket with palo about it though either. ... View more

Yes, they were.  We had three subnets on our IP networks outside interface that I believe were /28's and even though there were IP's assigned with the /28 subnet designated, I had to individually add every NAT'd address with a /32 to the network interface before NAT would work. ... View more

Thank you! I really appreciate the input on this! ... View more

Thanks. That is essentially what I did after I discovered this but I was more curious what, if anything, is the rational behind a port going doing being informational? Not sure if anyone from Palo Alto chimes in but how is this not a more critical type of alert? ... View more

This is straight out of the system log from a link dropping on us.  Bonus for the HSCI being in there. 🙂   Our alerting was ignoring information as far as getting a text/email so we never knew until other services dropped that the link had failed on the firewall. ... View more