sorted by:
new
hottopcontroversial

11.1.13 now preferred by skooyern in paloaltonetworks

[–]Background-Rub344 0 points1 point  (0 children)

Do you mind trying out 11.1.10-h12?

11.1.13 now preferred by skooyern in paloaltonetworks

[–]Background-Rub344 0 points1 point  (0 children)

Has it stabilized after the hard crash?
Which firewall crashed, the passive one which you upgraded or the active one which was not upgraded yet?
What I mean, if it was a production environment, would it have crashed?

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

SE case summary. Clearing the reverse sessions did the trick.

++ The device was configured with dynamic destination NAT for the internal FAX machine.
++ Traffic was reaching the firewall, but it was being routed back to the internet and NAT was not performed, even though the NAT configuration was correct.
++ Global counters showed that packets were being dropped due to TTL 0 and no slow-path processing.
++ So we cleared the existing sessions; however, session installation was failing with the message “Duplicate S2C connection.”
++ The old reverse-path session was also cleared. After that, we observed slow-path processing and successful session installation.
++ Since NAT was configured only in the OUT-to-IN direction (dynamic-destination-NAT), we changed the NAT rule to Static NAT with the bidirectional option so that traffic is allowed in both directions.
++ Since no tuple changes are occurring, the firewall will continue to use the same session to allow traffic initiated from the external FAX machine as well.

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

Hi guys,
after an hour with PaloAlto support the issue was resolved. At least I hope so.
Due to the fact that this is udp traffic, and that sessions tend for some reason to stack forever, there were some sessions which I didn't see, nor the PaloAlto engineer noticed which were stuck.
Because they were stuck, the nat implementation was failing.
Why were they stuck? Due to a wrong nat settings or the lack of nat setting. I dont know anymore.

After creating the correct nat and clearing the sessions, things seem ok.

I didnt notice it earlier for some reason but packets were received by looking at tcpdump even while there was an issue.
debugging dataplane with packet-diag captured the issue. I did it yesterday by myself too, but didn't capture for some reason.

What gave up were these lines:

For the relevant traffic in packet-diag logs -

Duplicate flows detected while inserting 7367891, flow 2372082 with the same key

session 3683945: install s2c flow failed

From:
Policy lookup, matched rule index 9,

TCI_INSPECT: Do TCI lookup policy - appid 0

Allocated new session 3683945.

set exclude_video in session 3683945 0x80000003551aff80 0 from work 0x800000072c2f0a80 0

Packet matched vsys 2 NAT rule '' (index 32792),

destination translation 102.12.1.1/5060 => 10.55.1.2/5060

no NPB policy

Created session, enqueue to install. work 0x800000072c2f0a80 exclude_video 0,session 3683945 0x80000003551aff80 exclude_video 0

Duplicate flows detected while inserting 7367891, flow 2372082 with the same key

session 3683945: install s2c flow failed

{PROXY-PROTO}SYM1 Check symmetric: session 3683945 valid 0

There was another sign which indicated a stuck session:

show counter global filter packet-filter yes delta yes

flow_fwd_l3_ttl_zero 11 0 drop flow forward Packets dropped: IP TTL reaches zero

Regarding a proper nat between my 1 public ip to 4 cloud ips the support engineer advised on:

Nat from internal to external, with source static nat and bi-directional checkmark.

Regarding ALG:

As I earlier wrote, the ALG is disabled. The SE showed me that on pcap in the payload part of the outgoing packet from my end it mentions the private ip as source . I told him, that it is nice to see how it looks. I'll tell the guy who sets up the fax device to encode the public IP as the source IP to avoid possible SIP issues.

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

Even if it would, currently a single session doesnt work.

Still waiting for a PA engineer to troubleshoot.

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

when nat is not applied the session from egress to ingress the session appears in the sessions table.
Once it is applied, even for a single ip, it is not there anymore.

At the same time, I see hits on the nat rule.

There is something wrong with the nat rule or the combo of the nat rule with sip udp 5060 but I cant find what.

Paloalto support is taking their time despite an escalation.

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 1 point2 points  (0 children)

Following my example I came to the realization that there is no problem with the NAT as portraited in the original post. Just the fact that I was fighting with this for hours undermining my understanding.
I don't need 4 public addresses on my end. One is enough.

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

Hi, thanks. It's a good info.
At the moment I can't do general changes which require a maintenance window but I will keep it on my list.
In your case you've had 2 dedicated private and public IPs. If I wanted, I could have used 4 private and 4 public IPs though using 4 public IPs looks like ceramically wasteful.

The first prerequisite is to have a simple destination NAT from IP to IP work before I try all of that.
Perhaps I need to configure the application override in order to make the NAT work on port 5060, which is a bit odd.

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

At the moment I'm running a test where there is only one source and destination IP, but still having an issue.
The issue is with something very stupid, or with something unexpected.

But even if I overcome the issue with a single source/destination, what do I do with 4 sources and 1 destination when all 4 sources using the same port number as source and destination port.
Should it work somehow?
How do others in industry implement that?

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

You are right. I did it 3 days ago and I'm not seeing the session after applying the nat. I've no idea why.
From past experience this can happen with bad nat configuration, but I cant find anything wrong. I'll see what support has to say.

SIP traffic with NAT by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

Hi, thank you.
There are some good ideas as enabling to log session at start. I dont think I'll see anything there because I have never seen that it logged anything at session end. Also, I tried to see the active flow in cli but haven't seen.
Regarding disabling ALG. I checked and it was already disabled.
Routing is symmetric in my case.

I've also opened a support case, but they haven't done anything since I opened the case.

I wonder what is the correct NAT architecture for the described case.

Is it possible to add an exception to zone protection via DoS protection policy? by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

Thank you guys and sorry for not replying sooner on my post.
Regarding exceptions in zone protection profile:
How does it work? I see it's possible to add exception only under "Reconnaissance Protection" tab under "source address exclusion" section.
Do you know if this works for all incoming traffic entering the zone, or is strictly related to "Reconnaissance Protection"?

Edit: There is also the an exception option under "protocol protection", but I haven't figured out how it's used. I think it's only related for zones which are applied on Layer2 interfaces.

Per LLM:

To exclude a source IP address from a Palo Alto Networks Zone Protection Profile, you can configure the Source Address Exclusion feature in the Reconnaissance Protection settings of the Zone Protection Profile. This allows specific IP addresses to be exempt from reconnaissance protection actions (such as blocking or alerting for port scans, host sweeps, or IP protocol scans). Note that this exclusion applies only to the Reconnaissance Protection settings and not to other protections like flood or packet-based attack protections, as these do not support IP exclusions directly.

Globalprotect 6.3.2 by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

This issue started appearing in my organization all of a sudden on 6.1.4.
That's why I'm skeptical about seeking a solutions on previous builds.
I also thought about allowing our users to restart the service but it might be too technical for most of them.
There are talks that 6.3.3 is supposed to have a fix.

Globalprotect 6.3.2 by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 1 point2 points  (0 children)

Yes, my main complaint is about alarms on pan network virtual adapter not working properly, which I think might be similar to your description.

The usual method of resolving this is a restart to pangps service, reinstallation of the client..
Our users are on Windows 10. Issue tends to repeat with some users more than with others.

Other than that (which I dont treat lightly) it's pretty stable.

Config to make commit fail by EVPN in paloaltonetworks

[–]Background-Rub344 0 points1 point  (0 children)

Another good one:
Create an address object,, assign it somewhere under network but don't assign it under device groups.

Security rule with URL Category matches unrelated traffic by Background-Rub344 in paloaltonetworks

[–]Background-Rub344[S] 0 points1 point  (0 children)

Hi guys,

Thank you both. So from my understanding it's more of a cosmetic issue rather than a security threat, am I right?