IPSec-ESP trough PA-7k only unidirectional best practice? Work around bug (ID:80950)

[Unibw]

Hi,

due to a bug (ID:80950), that PANW is not able to fix, it is necessary to create seperate IPSec-ESP policies for both directions trough the PA-7050.

IPSec-ESP that comes in response to a opened session is being dropped if there is no separate policy for incomming ESP traffic.

Example:

-Client are allowed to open IPSec-Connections from "trust" to "untrust".

-You have to allow ESP also from "untrust" to "trust" for any adress a IPSec client might use

To avoid flooding, etc. from outside I am searching for solutions to avoid this.

Has any PA-7k admin found a valid approach?

Regards

Winfried

[glastra1]

Are you using hide-NAT to provide internet access?

Maybe using a Hide-NATfor the internal users you're allowing traffic to the untrust could workaround the issue, using NAT-transversal should encapsulate the traffic in UDP instead of ESP and almost every vendor support it.

You can find the NAT-transversal negotiation in the RFC

https://tools.ietf.org/html/rfc3947#page-3

so if you simply hide NAT the outgoing traffic from trust to untrust going to UDP port 500 should do the trick.

If you can control the client configuration use IKEv2 when possible, it's more resilent to DOS attacks. 

Be careful because allowing outgoing ESP traffic gives the end user tha ability to bypass your company policy rules. 

Regards,

Gerardo.

[Unibw]

Hi Gerardo, thanks for your answer. Usual we do no NAT at all in the concerning environment. The IKE-part is not the problem. The PA-7k does IKE stateful but is not able to handle the ESP stateful. Most solutions I am aware of need either change the client to avoid using ESP and packing ESP in TCP or UDP. Allowing each ESP packet from outside is not a good option. Using a second Firewall like Juniper Netscreen or Juniper SRX to fix the PA-7k firewall is also a possible solution, but who can afford a second firewall to fix a PANW bug? Regards Winfried