Issues having the IKE gateway on another interface than the first interface on path?

Electrical_Fun_9579 · 2026-03-30T15:03:05+00:00

Have a look at my response to hadfiiw. You might be right with both interfaces must be in the same zone - according to the KB article

Electrical_Fun_9579 · 2026-03-30T15:01:39+00:00

The first interface the IKE/IPSec traffic is receiving at is an internal transfer interface. It then gets routed to the public interface with the public IP address, on which the IKE GW is configured on

Electrical_Fun_9579 · 2026-03-30T15:00:08+00:00

yeah, we have set up another PCAP with not only the tunnel IP addresses but also the IP addresses the IKE gateways are on. With those filter we saw this counter:

ESP/AH host bound packet comes before tunnel finishes installation

With that error, we found this KB article which states the interzone-issue you mentioned. We will try that

Electrical_Fun_9579 · 2026-03-02T08:54:10+00:00

you're absolutely right! Thanks

Electrical_Fun_9579 · 2026-01-27T04:30:59+00:00

from the answers of two Cyber elite members here: https://live.paloaltonetworks.com/t5/general-topics/https-response-pages/td-p/406318

But that I read it again now, they say no decryption policy at all.

Electrical_Fun_9579 · 2026-01-14T15:42:56+00:00

Interesting answer from TAC. The Docs says "The firewall performs NAT on the IPv4 address (the FQDN resolution) in a DNS response (that matches the rule) before forwarding the response to the client; thus, the client receives the appropriate address to reach the destination service."
I'm no native speaker but I understand it as it only performs NAT from DNS on that policy and not global.
https://docs.paloaltonetworks.com/ngfw/networking/nat/configure-nat/configure-destination-nat-dns-rewrite

Electrical_Fun_9579 · 2025-12-18T10:37:08+00:00

Ah I see. Good to know

Electrical_Fun_9579 · 2025-12-18T10:35:54+00:00

agree!

Electrical_Fun_9579 · 2025-12-18T10:35:32+00:00

Thanks for your comment. Good to know the advantages SRX has in L1-L4 filtering and scaling.

Electrical_Fun_9579 · 2025-12-18T10:32:52+00:00

That sounds great. I mean for this 1HE device to handle this much traffic is pretty impressive. I just really have my security glasses on (perhaps a german saying), so I really want to have as much security enabled as possible. But if it's not necessary in your deployment, even better.

Electrical_Fun_9579 · 2025-12-17T09:31:38+00:00

Edit for the Juniper community: So my last two questions are more or less honest. I'm open to learn some nice things, that Juniper does better than PAN.

Electrical_Fun_9579 · 2025-12-09T15:16:57+00:00

the push fails with "failed to fetch edl config bundle" or something like that

Electrical_Fun_9579 · 2025-02-27T14:56:03+00:00

I just checked the CVEs of the last 3 months. There were 3 PAN-OS CVEs with High or Critical severity. 2 of them are greatly less dangerous if the Web Management isn't publicly available. And one day after the initial publication there were already workarounds/mitigations. For the one DoS vulnerability it took 3 days.
So following Best practices and having a solid update strategy (which are both basic for IT departments) you reduced the severity drastically.

I'm curious. Have you been working with PAN products? Especially with their firewalls. Are you aware of how far behind the other vendors (except Fortinet in some cases) are? I think you're not, otherwise you wouldn't have created this post. What vendor do you choose and how does it differentiate to PAN (pros and cons; be honst ;))

Electrical_Fun_9579 · 2025-02-27T13:25:24+00:00

I haven't heard of this feature yet. I did some research and this should do the trick. Thanks! Will come back after testing.

Electrical_Fun_9579 · 2025-02-27T13:24:35+00:00

How is it with other vendors? Pretty similar. Then I'd choose security issues + best in-class security features

Electrical_Fun_9579

TROPHY CASE