This article explains why an Internet Key Exchange (IKE) security association is observed for a peer that is not configured.

(IKE is a method for exchanging keys for encryption and authentication over an unsecured medium, such as the Internet.)

An IKE security association is observed for a peer that is not configured.

The scenario below explains the peculiarity.

IKE configuration on device

root@100-4# show security ike

policy ikep {
    mode main;
    proposal-set standard;
    pre-shared-key ascii-text "$9$xhQ-bYJGifT3goT369OBxNdbgoZUjqP5"; ## SECRET-DATA
}
gateway ikeg {
    ike-policy ikep;
    address 172.27.201.11;
    external-interface fe-0/0/5.0;
}

IKE security association observed for an unknown, unconfigured gateway

root@100-4# run show security ike security-associations

Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
<....Output Snipped....> 
4785539 DOWN   8208b158d8525dc2  82c41f4e64e59af3  Any            172.27.201.8  <-----

Conclusion

IKE packets are being received from IP address 172.27.201.8.


Verify Conclusion

tcpdump

root@100-4# run monitor traffic interface fe-0/0/5.0 layer2-headers no-resolve size 1500 matching "host 172.27.201.8"
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on fe-0/0/5.0, capture size 1500 bytes

01:46:22.684226  In PFE proto 2 (ipv4): 172.27.201.8.500 > 172.27.201.6.500: isakmp: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1 spi=0adca1d351506c5b
            (t: #0 id=ike (type=enc value=3des)(type=group desc value=modp1024)(type=hash value=sha1)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)(type=auth value=preshared)))
        (p: #2 protoid=isakmp transform=1 spi=0adca1d351506c5b
            (t: #0 id=ike (type=enc value=0007)(type=keylen value=0080)(type=group desc value=modp1024)(type=hash value=sha1)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)(type=auth value=preshared))))
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=28)
01:46:22.687669 Out b0:c6:9a:30:47:45 > 28:c0:da:e1:50:85, ethertype IPv4 (0x0800), length 144: 172.27.201.6.500 > 172.27.201.8.500: isakmp: phase 2/others R inf:
    (n: doi=ipsec proto=isakmp type=NO-PROPOSAL-CHOSEN spi=0adca1d351506c5ba8808f65fc6082f8 orig=(
        (sa: doi=393250 situation=1131378028) [|#128]))

The solution is to configure the firewall filter on loopback so that it rejects packets from untrusted IKE peers. For more information, see Guidelines for Configuring Firewall Filters .

Note: Another way to resolve the issue is to completely remove IKE configuration if it is not in use.

• Configuring Security Associations