SRX

 View Only
last person joined: 23 hours ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  One-sided IKE SA

    Posted 01-17-2021 16:48
    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?


  • 2.  RE: One-sided IKE SA

    Posted 01-17-2021 18:25
    Do you have nat traversal on in the configuration?
    This is required when the gateway interface address is behind a nat.

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 3.  RE: One-sided IKE SA

    Posted 01-17-2021 18:33
    Thanks for the suggestion.
    NAT-T is on by default, and I haven't disabled it


  • 4.  RE: One-sided IKE SA
    Best Answer

    Posted 01-17-2021 18:42
    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.