New Member

Question

IPSec VPN accepts any peer certificate when specific certificate given

Forum|Forum|9 years ago
October 31, 2016
1 reply
29306 views

Hi All,

Setting up IPSec VPN (IKEv2) between two 5.4.1 FortiGates. Works fine with PSK (after working around GUI bug that saves wrong IP if you use named addresses for the VPN).

When I changed over to using certificates I found the tunnels went up just fine, but the peer certificate wasn't getting verified as I would have expected. Meaning, I could (and did) list a non-existent peer certificate name of GARBAGE_T with or without cn and subject set, and the tunnel would still go up with no complaints. Not exactly secure.

Both devices have their peer certificates signed by my local CA root vpn ca certificate.

Both devices have imported the root vpn ca cert.

Both devices have the private version of their own cert (signed by the root vpn ca cert).

Both devices have the public version of the other devices cert (signed by the root vpn ca cert).

The phase1 settings on both sides specify that they authenticate with a signature and list their own certificate by name.

The phase1 settings on both sides specify IKEv2 and that they accept only a peer certificate, with the peer certificate name referring (I believe) not to the certificate, but to the name of the peer that refers to the cert (config user peer). As mentioned above, I can change the user peer here to be a dummy peer referring to a non-existent certificate and the tunnel still goes up. Scary.

Any ideas on what's going on here? I'm really hoping this is some simple mistake on my part.

5.4

emnoc

New Member

What's you peer type set as "any" or this peer

show full vpn ipsec phase1-interface | grep peer

You can run the following for better diagnostic and reset the tunnel from the far end

diag debug dis

diag debug reset

diag debug enable

diag debug vpn ike log filter name yourphase1-interface-byname

diag vpn ike gateway flush

oops stick a to turn on ike debug

diagnose debug app ike -1

tanrAuthor

New Member

Hi emnoc,

The show full gives peertype as peer for the phase1-interface, which the online help says means "accepts this peer certificate."

The cleanest version of the logs I was able to generate are below. From my (poor) understanding of the logs, it certainly looks like it is authenticating the (non-existent) GARBAGE_T cert referenced in my test peer. I cut off the logs once it started building phase2.

PROMPT # di de app ike -1

PROMPT # di vpn ike log filter name p1-sp-to-ho

PROMPT # di de enable

PROMPT # di vpn ike gateway flush

ike 0:p1-sp-to-ho: deleting

ike 0:p1-sp-to-ho: flushing

ike 0:p1-sp-to-ho: deleting IPsec SA with SPI eafXX353

ike 0:p1-sp-to-ho:p2-sec-to-ho-cams: deleted IPsec SA with SPI eafXX553, SA count: 0

ike 0:p1-sp-to-ho: sending SNMP tunnel DOWN trap for p2-sec-to-ho-cams

ike 0:p1-sp-to-ho:p2-sec-to-ho-cams: sending SNMP tunnel DOWN trap

ike 0:p1-sp-to-ho: flushed

ike 0:p1-sp-to-ho:285:132: send informational

ike 0:p1-sp-to-ho:285: enc 000XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0107

ike 0:p1-sp-to-ho:285: out 11BBEF79XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho:285: sent IKE msg (INFORMATIONAL): SP.SP.IP.IP:500->HO.HO.IP.IP:500, len=80, id=11bbXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX58:00000002

ike 0:p1-sp-to-ho: deleted

ike 0:p1-sp-to-ho: set oper down

ike 0:p1-sp-to-ho: schedule auto-negotiate

ike 0:p1-sp-to-ho: carrier down

PROMPT # ike 0: comes HO.HO.IP.IP:500->SP.SP.IP.IP:500,ifindex=5....

ike 0: IKEv2 exchange=INFORMATIONAL_RESPONSE id=11bbefbbbbbafb7/5418922bbbbb458:00000002 len=80

ike 0: in 11BBEF79XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho: auto-negotiate connection

ike 0:p1-sp-to-ho: created connection: 0x50877e0 5 SP.SP.IP.IP->HO.HO.IP.IP:500.

ike 0:p1-sp-to-ho:p2-sec-to-ho-cams: chosen to populate IKE_SA traffic-selectors

ike 0:p1-sp-to-ho: no suitable IKE_SA, queuing CHILD_SA request and initiating IKE_SA negotiation

ike 0:p1-sp-to-ho:286: out F9F295BXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho:286: sent IKE msg (SA_INIT): SP.SP.IP.IP:500->HO.HO.IP.IP:500, len=416, id=f9XXXXXXXXXXX8c/0000000000000000

ike 0: comes HO.HO.IP.IP:500->SP.SP.IP.IP:500,ifindex=5....

ike 0: IKEv2 exchange=SA_INIT_RESPONSE id=f9f295be2d3dd98c/8a0b87d1ab66f5f0 len=441

ike 0: in F9F295BE2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho:286: initiator received SA_INIT response

ike 0:p1-sp-to-ho:286: received notify type NAT_DETECTION_SOURCE_IP

ike 0:p1-sp-to-ho:286: processing NAT-D payload

ike 0:p1-sp-to-ho:286: NAT not detected

ike 0:p1-sp-to-ho:286: process NAT-D

ike 0:p1-sp-to-ho:286: received notify type NAT_DETECTION_DESTINATION_IP

ike 0:p1-sp-to-ho:286: processing NAT-D payload

ike 0:p1-sp-to-ho:286: NAT not detected

ike 0:p1-sp-to-ho:286: process NAT-D

ike 0:p1-sp-to-ho:286: incoming proposal:

ike 0:p1-sp-to-ho:286: proposal id = 1:

ike 0:p1-sp-to-ho:286: protocol = IKEv2:

ike 0:p1-sp-to-ho:286: encapsulation = IKEv2/none

ike 0:p1-sp-to-ho:286: type=ENCR, val=AES_CBC (key_len = 256)

ike 0:p1-sp-to-ho:286: type=INTEGR, val=AUTH_HMAC_SHA2_256_128

ike 0:p1-sp-to-ho:286: type=PRF, val=PRF_HMAC_SHA2_256

ike 0:p1-sp-to-ho:286: type=DH_GROUP, val=MODP2048.

ike 0:p1-sp-to-ho:286: matched proposal id 1

ike 0:p1-sp-to-ho:286: proposal id = 1:

ike 0:p1-sp-to-ho:286: protocol = IKEv2:

ike 0:p1-sp-to-ho:286: encapsulation = IKEv2/none

ike 0:p1-sp-to-ho:286: type=ENCR, val=AES_CBC (key_len = 256)

ike 0:p1-sp-to-ho:286: type=INTEGR, val=AUTH_HMAC_SHA2_256_128

ike 0:p1-sp-to-ho:286: type=PRF, vaVVVVVVl=PRF_HMAC_SHA2_256

ike 0:p1-sp-to-ho:286: type=DH_GROUP, val=MODP2048.

ike 0:p1-sp-to-ho:286: lifetime=86400

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV3dd98c/8a0b87VVVVVVf5f0 SK_ei 32:F58D9VVVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV2d3dd98c/8a0b87d1aVVVVVV SK_er 32:4091VVVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV2d3dd98c/8a0b87d1aVVVVVV SK_ai 32:28725VVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV2d3dd98c/8a0b87d1aVVVVVV SK_ar 32:5CCC2VVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: initiator preparing AUTH msg

ike 0:p1-sp-to-ho:286: local cert, subject='WXXXX_VPN1_SP', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: local CA cert, subject='WXXXX_VPN_RT1', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: sending INITIAL-CONTACT

ike 0:p1-sp-to-ho:286: sending CERTREQ payload

ike 0:p1-sp-to-ho:286: enc 2500008D09000000308182310B30090603550406130255533XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxxx

ike 0:p1-sp-to-ho:286: out F9F295BE2D3DD98C8A0B87D1AB66F5F02E202308000000010XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxx

ike 0:p1-sp-to-ho:286: sent IKE msg (AUTH): SP.SP.IP.IP:500->HO.HO.IP.IP:500, len=2992, id=f9f295bbbbbbd98c/8a0b87d1bbbbbbf0:00000001

ike 0: comes HO.HO.IP.IP:500->SP.SP.IP.IP:500,ifindex=5....

ike 0: IKEv2 exchange=AUTH_RESPONSE id=f9f295be2d3dd98c/8a0b87d1ab66f5f0:00000001 len=2960

ike 0: in F9F295BE2D3DD98C8A0B87D1AB66F5F02E2023200000000100000B9024000B7488XXXXXXXXXXXXXXXXXXXxxxxx

ike 0:p1-sp-to-ho:286: dec F9F295BE2D3DD98C8A0B87D1AB66F5F02E20232000000001EXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxx

ike 0:p1-sp-to-ho:286: initiator received AUTH msg

ike 0:p1-sp-to-ho:286: received peer identifier DER_ASN1_DN 'C = US, ST = State, L = City, O = Company, CN = WXXXX_VPN2_HO, emailAddress = xXxXx@xXxXx.com'

ike 0:p1-sp-to-ho:286: Validating X.509 certificate

ike 0:p1-sp-to-ho:286: peer cert, subject='WXXXX_VPN2_HO', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: peer CA cert, subject='WXXXX_VPN_RT1', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: peer ID verified

ike 0:p1-sp-to-ho:286: building fnbam peer candidate list

ike 0:p1-sp-to-ho:286: FNBAM_GROUP_NAME candidate 'GARBAGE_T'

ike 0:p1-sp-to-ho:286: certificate validation pending

ike 0:p1-sp-to-ho:286: certificate validation complete

ike 0:p1-sp-to-ho:286: certificate validation succeeded

ike 0:p1-sp-to-ho:286: signature verification succeeded

ike 0:p1-sp-to-ho:286: auth verify done

ike 0:p1-sp-to-ho:286: initiator AUTH continuation

ike 0:p1-sp-to-ho:286: authentication succeeded

ike 0:p1-sp-to-ho:286: received notify type MESSAGE_ID_SYNC_SUPPORTED

ike 0:p1-sp-to-ho:286: processing child notify type MESSAGE_ID_SYNC_SUPPORTED

ike 0:p1-sp-to-ho:286: established IKE SA f9f29bbbbbb98c/8a0bbbbbbbf0

ike 0:p1-sp-to-ho: set oper up

ike 0:p1-sp-to-ho: schedule auto-negotiate

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: incoming child SA proposal:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: proposal id = 1:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: protocol = ESP:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: encapsulation = TUNNEL

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: type=ENCR, val=AES_CBC (key_len = 128)

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: type=INTEGR, val=SHA256

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: type=ESN, val=NO

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: PFS is disabled

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: matched proposal id 1

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: proposal id = 1:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: protocol = ESP:

...

Any thoughts on what is going on?

tanrAuthor

New Member

Did some more testing of this, and what I found was disturbing.

Specifying a PKI peer, to authenticate only a specific certificate, appears to be badly broken in 5.4.1 IPSec VPN, at least if you specify a ca certificate in the peer.

If I specify a ca cert in the peer, the IPSec phase1 will accept ANYTHING signed by that ca cert. It doesn't check the peer's cn, it doesn't check the subject, it doesn't even check the cn-type. I hope it won't accept a signed but revoked cert, but who knows.

I read that this used to be an issue with FortiOS 4.x SSL VPN, but the forum comments implied that IPSec VPN verified the subject/cn correctly. No longer, I guess.

Anybody aware of this, or have a workaround? Has it already been reported as a bug to Fortinet?

Right now, the only workaround I see is to generate a unique CA cert for each site, have that CA sign a dummy cert for the site which the site will authenticate with, and give the other sites the public ca cert to verify against the dummy cert. Hopefully that will work with intermediate CA certs. Yuck.

Sign up

Login with SSO

Login to the community

Login with SSO