I just figured it out!
It was the IKE ID's.
I was getting this error in the
kmd logs:
IPSec negotiation failed with error: Peer's IKE-ID validation failed during negotiation
Because this is an AutoVPN, it needs to use certificates for authentication. I already had them configured, but the ID's were still off.
When authenticating, each side will send their certificate and their local ID.
With PSK authentication, this would probably be an IP address on the SRX.
However, with certificate authentication, it needs to be a field in the certificate.
The spoke side was already configured correctly. It wasn't sending an IP, as the IP was dynamic.
However, I had the hub side sending it's IP address as its IKE ID.
The trick is this:
security {
ike {
gateway IKE-Gateway {
local-identity distinguished-name;
}
}
}
This sends the 'DN' field in the certificate as the IKE ID.
The spoke can authenticate this with this configuration
security {
ike {
gateway IKE-Gateway {
remote-identity distinguished-name wildcard DC=example.com;
}
}
}
I'm still not sure why the hub was UP, but the spoke was DOWN.
But, in any case, that's how it's fixed!
Hope that saves someone some time in future.
Original Message:
Sent: 01-17-2021 16:47
From: Unknown User
Subject: One-sided IKE SA
I have two SRX firewalls. One is a 320, the other is 345.
I am trying to configure AutoVPN between them.
I have found that the IKE SA is up on the hub side.
The hub has a static Public IP, which is applied with NAT by an upstream device.
The hub is always the responder.
On the spoke the SA shows as DOWN. The SA is in this state for a while before clearing itself. It will retry periodically.
The spoke uses 4G for its connection to the internet, and has a dynamic IP.
The spoke is always the initiator.
I've never seen a case where the SA is UP on one side, but DOWN on the other.
Can anyone offer any suggestions on what might cause this, or how to troubleshoot it?