IKEv2 fragments

IKEv2 messages can become extremely large due to  various conditions ( certificate and exchange messages ). So since these messages are UDP  based,  and have no  transport layer mechanism to  determine MTU ( aka MSS  Maximum Segment Size ) the IKEv2 process need to  control fragments at the application layer of the Internet Key Exchange.

So after the IKEv2  IKE_SA_INIT  we need to  set and control the fragments size for future and pending ExChange messages



You can review the  total fragments with in a packet decoder such as wireshark

e.g

NOTE: take note of the SPI for INITIATOR AND RESPONDER 

So we know that  3ea  individual message makes up this IKE_AUTH  message. So during IKEv2 trouble shooting make sure you  are aware of the  total number of fragments and any missed fragments if your experiencing IKEv2 issues.


This is easily accomplish by  both ends packet captures. If a message is  split into  three packets and one is missed, it would be the equal of  "   trying to  read a book with every other word missing"

Now if  IKE messages are missing along the way you can try the following;

1: lower the over all interface MTU but this will affect ALL other traffic types

2:  if the device support IKEv2 fragment mtu-adjust-sive  ( Juniper & Cisco has support for this in various systems  btw )

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o

        /  \

FortiOS and EAP identity vpn.

In this last final IKEv2 series of vpn, I will demo  a EAP Identity based ipsec-vpn solution  with the FortiGate firewall and a StrongSwan vpn client.

The setup is similar to my earlier IKEv2 blogs,  but we will use a use group and authenticate the  user from the local FortiOS database.


I'm using the macosx and android  strongswan clients in this blog.











You can monitor the  client logs for statistics and for any errors. The logs are very detail and will show the device challenge and assignments.





On the fortigate a  IPSEC-SA will be presented upon a successful establishments.

Once the client has connect in the  WebGUI ipsec monitor you will not find any end-user details which is horrible. Also notice each vpn-tunnel session is prepended with the <vpntunnel_name>_<+Number>. You will need to use the diag vpn ike gateway command to id the actual user.

Here's the  fortigate configurations

 in the android client do NOT select  send  request to CA, this will generate a lot of wasted IKEv2 messages

The vpn client only needs  the server name and identity, here's a a typical Android setup.

Do you not leave the "CA certificate Select Automatically " enable. Uncheck and  defined the root CA-cert that signed the server certificate.

If all goes well you should have a connected vpn status, if not download the loads and start reviewing

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o

        /  \

Strongswan DYNAMIC vpnclient fortiOS IKEv2

https://www.strongswan.org/

To use IKEv2 and the strongswan vpnclient  deployment,  you need to be  made aware of the following. The client will validate the SubjectAlternativeName  section of the  certificate. This has cause numerous issues for users deploying the   strongswan client and the dread  not able to find a trusted RSA public key.

"no trusted RSA public key found for "


Do not build a  x509 certificate with just a CN and Subject Alternative Name  & if you want it to work across multiple client-types.


https://wiki.strongswan.org/issues/1540
http://tiebing.blogspot.com/2016/03/no-trusted-rsa-public-key-found.html

reference the above fellow blogger  article & about how strongswan checks the certs. 



The  CN  field  is not as important, but the SubjectAlternativeName  section is  very important and you might need to ensure the IKEv2 certificate display has a IP value that matches the vpnclient server configuration

Here's the wikipedia  definition of SAN and possible values

!!!!!!!!   In my example ,   I ONLY NEED A IP ENTRY,   BUT I CRAFT A CERTIFICATE WITH ALL TYPES  just   for demostration purpose    !!!!!!!!!

When crafting the certificate for the FortiOS, we need to apply the "IP" name in the SubjectAlternativeName value. I have never figured out why  the  clients  checks the "IP" field and not the "DNS" field in the  certificate.

  !!!! Do NOT use the fortiOS to generate a CSR, but build a CSR with openssl and send it for signing !!!!

openssl req -new -nodes -sha256 -config ./myaltnamesupplement.cnf -out  mycsr.csr -keyout mycsrkey.key



Here's a few example for extension-file  value that I will pass to my CA & my CSR for signing and the final certificate  output (  trunacated ). I also  add a few other not so common values that the SubjectAlternativeName can support  such as  URI and emailaddress.

Now the client  is simple to configure, you need to install a user  certificate and upload the  root_SignerCA   certificate into the client. The rest should be straight forward

   1:  define a profile name
   2:  define the server address/hostname that we will attempt connection to
   3:  select the user certficare the vpn-gateway is expecting
   4:  set the rootCA certificate

When you have all set, you should be able to connect in a similar fashion;

 Here's an established session  take note of the peerid details in the two sessions and the src_ports. This was me logging in from the same network from 2 android devices

!!!!!!  Note,  if strongswan  complains of no trusted RSA public key and provides and a ipv4address in the log message, that ensure you have a IP value in the Alternative Name field  that is correct  .  !!!!!!!!

 

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o

        /  \

 

NCP vpnclient Ikev2 with fortiOS v6.0

In this blog I will demo the NCP entry vpnclient and a typical IKEv2  connection using  "SIGNATURE RSA" aka certificates. This  design was done under fortiOS v6.0


The NCP client provides numerous log details on vpnclient  errors codes,  and have host of configuration items for  IKE/IPSEC settings. It  a great client and I've been  studying and  demo'ing it for  a little over a year now. It a client that cane be a great  replacement for the MACOSX native client if you do NOT meed LT2P-ipsec.

In this example, the MacOS vpnclient has a imported pfx/pkcs12 formatted cert. It crucial to add the  user_cert and rootCA certificates into the certfile-bundle when building the pfx that you will load and later call up.

e.g ( how to build a cert-bundle  from  unix shell )

    cat user.crt > myvpncert.pem
    cat rootCA.crt >> myvpncert.pem

The certificates that signs the user_vpn_certificate needs to be present or you will get errors and fail auth and validations.

I have a few open  dialogs with the support team on NCPclient and they claims it supports all known ipsec IKEv2 RFCs,  but I have not been successful in getting the client to  CFREQUEST ipv6


Moving on, here's a FortiOS  configuration set for  a peer and with no EAP ( no user Auth, no username/password )

 

In this case we are using peergroup and anybody  issues a certificate from socpuppetCA would be authenticated and  if they have a subject field that has ken.felix

On the NCP client we have a few items to configure

FortiOS  policy to allow vpn client turn around NAT to get back out. I'm allowing  services defined below. In a real deploy you  might use  TLS inspection with URL/AV inspections.

Now we launch the client and  wait for a  Success  Connection

The 1st time you  use the certificate you will be prompt for the cert PIN. The pin is the  pfx passphrase. Why they call it a PIN ?...............I have no clue.


FortiOS diagnostic cmds for tunnel validations.

The ipv6 mode-config was sent to the client , but the client ( macosx ) does not seem to honor it. I'm awaiting for  NCP support to get back with me.

I hope this helps for those wanting to use basic IKEv2 without EAP authentication. Next up will be the IKEv2 cert a StrongSwan client  on Android

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o

        /  \