AWS Compatibility with Forcepoint Firewall

To reiterate, no one should be using IKEv1 in 2025, not with AWS and not with any other platform. Only ever enable IKEv2 and never IKEv1.

To help troubleshoot your AWS-Forcepoint VPN tunnel issue, you need to clarify a few things first:

1. What AWS VPN service are you using?

• AWS VPN Gateway (attached to VPC) or
• AWS Transit Gateway with VPN attachment

2. What exact error are you getting? Please update with log details of errors

3. Common IPSec tunnel connectivity issues are because of config mismatch on both sides of the tunnel. Check:

*** Phase 1 (IKE) Mismatches:**

    1. Encryption algorithm (AES-128, AES-256)
    2. Authentication method (PSK vs certificates)
    3. DH Group (2, 14, 15, 16, 17, 18, 19, 20, 21)
    4. Lifetime settings

*** Phase 2 (IPSec) Mismatches:**

    1. PFS (Perfect Forward Secrecy) settings
    2. Encryption/authentication algorithms
    3. Lifetime values

4. Troubleshooting Steps:

    a. Check AWS VPN Connection Status:
            AWS Console → VPC → VPN Connections → [Your Connection] → Tunnel Details

    b. Review CloudWatch Logs:
            * VPN connection state changes
            * Tunnel state metrics

5. Common Fixes:

    * Ensure both tunnels are configured (AWS provides 2 for redundancy)
    * Verify NAT-T is enabled if behind NAT
    * Check firewall rules allowing UDP 500/4500
    * Confirm pre-shared keys match exactly

The Forcepoint Secure SD-WAN firewall works perfectly well with the AWS site-to-site VPN.

I suggest you start by creating an SD-WAN Profile in SMC with settings recommended for tunnels with AWS:

• IKE SA settings (phase 1)

- versions: IKEv2 only (uncheck IKEv1)
- cipher algorithms: AES-256
- message digest algorithms: SHA-2, 256-bit
- Diffie-Hellman group: 20 (uncheck all the other groups)

• IPsec SA (phase 2)

- IPsec type: ESP
- cipher algorithms: AES-GCM-256 (unselect all the others)
- message digest algorithm: SHA-2, 256-bit (only used as a pseudo-random function, PRF, for AES-GCM)
- compression algorithm: none
- use PFS with Diffie-Hellman Group: 20
- do not select any of the settings named "disable ..."

Configure equivalent settings on the AWS side. Specifically, don't leave all the supported options enabled but only the ones intended to be used.

AWS site-to-site VPNs are route-based VPNs, not policy-based ones, so in your site configuration ("encryption domain") on the Forcepoint firewall's side, you should have 0.0.0.0/0 and no other networks on the Forcepoint side of the tunnel. Even when the AWS side has specific routes pointing to the tunnel, the traffic selector it will expect or offer for the other side of the IPsec SAs is going to be for 0.0.0.0/0. Also, AWS supports only one SA at a time per direction, so if you configure multiple CIDRs on the Forcepoint side, the IPsec SA established for one CIDR is going to be torn down by AWS whenever a new SA is being requested for any of the other CIDRs.

You can control which networks are actually allowed through the tunnel on the Forcepoint side by using the firewall's access policies to send to and accept from the appropriate policy-based VPN only the expected IP ranges.

If the logs on the Forcepoint firewall still show failures, please capture the "Information message" field value of the log entries from the IPsec facility that you mentioned. They should show what settings are being offered or received and often show the reason offered settings are being rejected.

Based on your error logs (IKE-Timeout, IKE-SA-Initiator failed, IKE-SA deleted), this is a classic Phase 1 IKE negotiation failure. Here's what to check:

1. NAT-T Configuration: AWS automatically enables NAT-T - no manual configuration needed. Since you have Load Balancer → WAN Router → AWS, NAT-T is definitely required. Verify Forcepoint is configured for NAT Traversal mode

2. Critical Issue - Multiple NAT Devices: Your path: Forcepoint → Load Balancer → WAN Router → AWS. This creates a double-NAT scenario which often breaks VPN tunnels.

Immediate fixes to try:

A) Configure Static NAT on Load Balancer: Create 1:1 NAT mapping for Forcepoint's private IP. Ensure UDP 500/4500 are forwarded without modification

B) Bypass Load Balancer (Recommended): Route VPN traffic directly: Forcepoint → WAN Router → AWS. Use policy-based routing to exclude VPN traffic from load balancing

3. Forcepoint-Specific Settings: On ForcePoint, Verify these generic settings:

IKE Version: IKEv1 (AWS default) DPD: Enable with 10-second intervals Aggressive Mode: Disabled (use Main Mode) NAT Keepalive: 20 seconds

4. Debugging Steps: Enable detailed logging on Forcepoint: IKE negotiation logs IPSec tunnel logs NAT-T specific logs

Check AWS VPN Connection:

AWS Console → VPC → VPN Connections → [Connection] → Tunnel Details Look for: "Last Status Change Reason"

5. Quick Test: Try configuring only one tunnel initially (disable the second AWS tunnel endpoint) to eliminate any confusion during negotiation.

6. Network Path Verification: Run traceroute from Forcepoint to AWS VPN endpoint to confirm the exact path and identify where packets might be getting modified.