VPN net-to-net X509 ¿howto?

I configured a 'working' net-to-net x509 (2 peers) last night and here is how I did it. With the following method you will only have 1 'signing' CA (at the 'main' site), 1 verification CA (at the 'branch' site), 2 CERT+KEY's (at the 'main' site), 1 CERT and 1 CERT+KEY (at the 'branch' site).

At the 'main' site:
---Creation of Networks---
Create a network object for the 'branch' ASL public IP
Create a network object for the 'branch' internal network
---Creation of 'signing' CA and CERTS---
Create Signing CA
Create CSR's for both this ASL and the 'branch' ASL using the IPv4 address
Issue CERT's from CSR's for both CSR's you just created
Now on this ASL you have 1 'signing' CA,and 2 CERT+KEY's
---Now to make active your local certificate---
Under "Local Keys" select the CERT+KEY for this ASL and enter the password that you used while creating this CERT+KEY
---Now for Downloading these CERTS---
Download 'signing' CA as PEM (other formats if you like)
Download 'main' CERT+KEY as PEM
Download 'branch' CERT+KEY as PEM
---Finish Configuring---
Setup the Policy if you want to use something other than one of the default policies
setup connection as normal, be sure to choose the remote CERT for the authentication
Create a packet filter rule(s) allowing traffic from this private network access to the 'branch' private network and visa-versa

What we did at this 'main' ASL is first take care of creating the network objects that we need, then create the 'signing' CA that will sign all the CSR's that are created if we need to add other branches or roadwarriors. Then we created a CERT+KEY for this ASL and the 'branch' ASL using the IPv4 address. The CERT+KEY for this ASL was then set as the active "Local Certificate". Then all of these were downloaded for use on the 'branch' ASL as we will see now.

At the 'branch' ASL:
---Creation of Networks---
Create a network object for the 'main' ASL public IP
Create a network object for the 'main' internal network
---Upload the 'Verification CA'---
Choose 'New..' for 'Certificate Authorities' and choose upload and select the PEM file.
Do not select the file for the KEY...All we want over here is the public part of the CERT not the (private) KEY as well. That is the difference between a 'signing' and a 'verification' CA. We just want to verify CERT's over here since there is no need to have have several 'signing' CA's to create a possible administrative headache.
Now you should see under 'Certificate Authorities', a 'Verification CA" that is actually from the 'main' ASL.
---Upload this ASL's CERT+KEY---
Now under "Host CSR's and CERT's" choose "New..." and then upload both the CERT and KEY for this ASL (fill in both "File" AND "Key File (opt)" with the same PEM file
You should now see the CERT+KEY for this branch's ASL
Note:We need the (private) KEY for this one because this will end up being this ASL's local certificate for 'going against' the (public) CERT for decryption from the 'main' site
---Upload the 'main' ASL CERT---
Now under "Host CSR's and CERT's" choose "New..." and then upload the 'main' ASL CERT ONLY. There is no need to bring over the (private) KEY because we are not "going against' that (public) CERT, we are 'going against' the (public) CERT of the 'branch', We need this 'public' CERT over here to 'go against' the (private) 'main' KEY at the other site....starting to make sense now? Hope so.
Now you should see the CERT (NOT CERT+KEY) for the 'main' ASL
---Now to make active your local certificate---
Under "Local Keys" select the CERT+KEY for this ASL and enter the password that you used while creating this CERT+KEY at the 'main' site
---Finish Configuring---
Setup the Policy if you want to use something other than one of the default policies - MUST MATCH 'MAIN' SIDE
setup connection as normal, be sure to choose the remote CERT for the authentication
Create a packet filter rule(s) allowing traffic from this private network access to the 'main'' private network and visa-versa

You should now (hopefully) see an active VPN route.

Hopefully this will help out!

Brent  

I configured a 'working' net-to-net x509 (2 peers) last night and here is how I did it. With the following method you will only have 1 'signing' CA (at the 'main' site), 1 verification CA (at the 'branch' site), 2 CERT+KEY's (at the 'main' site), 1 CERT and 1 CERT+KEY (at the 'branch' site).

At the 'main' site:
---Creation of Networks---
Create a network object for the 'branch' ASL public IP
Create a network object for the 'branch' internal network
---Creation of 'signing' CA and CERTS---
Create Signing CA
Create CSR's for both this ASL and the 'branch' ASL using the IPv4 address
Issue CERT's from CSR's for both CSR's you just created
Now on this ASL you have 1 'signing' CA,and 2 CERT+KEY's
---Now to make active your local certificate---
Under "Local Keys" select the CERT+KEY for this ASL and enter the password that you used while creating this CERT+KEY
---Now for Downloading these CERTS---
Download 'signing' CA as PEM (other formats if you like)
Download 'main' CERT+KEY as PEM
Download 'branch' CERT+KEY as PEM
---Finish Configuring---
Setup the Policy if you want to use something other than one of the default policies
setup connection as normal, be sure to choose the remote CERT for the authentication
Create a packet filter rule(s) allowing traffic from this private network access to the 'branch' private network and visa-versa

What we did at this 'main' ASL is first take care of creating the network objects that we need, then create the 'signing' CA that will sign all the CSR's that are created if we need to add other branches or roadwarriors. Then we created a CERT+KEY for this ASL and the 'branch' ASL using the IPv4 address. The CERT+KEY for this ASL was then set as the active "Local Certificate". Then all of these were downloaded for use on the 'branch' ASL as we will see now.

At the 'branch' ASL:
---Creation of Networks---
Create a network object for the 'main' ASL public IP
Create a network object for the 'main' internal network
---Upload the 'Verification CA'---
Choose 'New..' for 'Certificate Authorities' and choose upload and select the PEM file.
Do not select the file for the KEY...All we want over here is the public part of the CERT not the (private) KEY as well. That is the difference between a 'signing' and a 'verification' CA. We just want to verify CERT's over here since there is no need to have have several 'signing' CA's to create a possible administrative headache.
Now you should see under 'Certificate Authorities', a 'Verification CA" that is actually from the 'main' ASL.
---Upload this ASL's CERT+KEY---
Now under "Host CSR's and CERT's" choose "New..." and then upload both the CERT and KEY for this ASL (fill in both "File" AND "Key File (opt)" with the same PEM file
You should now see the CERT+KEY for this branch's ASL
Note:We need the (private) KEY for this one because this will end up being this ASL's local certificate for 'going against' the (public) CERT for decryption from the 'main' site
---Upload the 'main' ASL CERT---
Now under "Host CSR's and CERT's" choose "New..." and then upload the 'main' ASL CERT ONLY. There is no need to bring over the (private) KEY because we are not "going against' that (public) CERT, we are 'going against' the (public) CERT of the 'branch', We need this 'public' CERT over here to 'go against' the (private) 'main' KEY at the other site....starting to make sense now? Hope so.
Now you should see the CERT (NOT CERT+KEY) for the 'main' ASL
---Now to make active your local certificate---
Under "Local Keys" select the CERT+KEY for this ASL and enter the password that you used while creating this CERT+KEY at the 'main' site
---Finish Configuring---
Setup the Policy if you want to use something other than one of the default policies - MUST MATCH 'MAIN' SIDE
setup connection as normal, be sure to choose the remote CERT for the authentication
Create a packet filter rule(s) allowing traffic from this private network access to the 'main'' private network and visa-versa

You should now (hopefully) see an active VPN route.

Hopefully this will help out!

Brent