Tag Archives: VPN

FortiClient Azure Authentication

Posted on by
11

FortiClient Azure KB ID 0001797

Problem

More and more people are using Azure as their primary identity provider, thanks in no small part to the massive success of Office/Windows 365. So if you want to provide a FortiGate/FortiClient SSL remote access VPN solution then securing it via Azure makes a lot of sense.

Multi Factor Authentication: If you have MFA on your Azure accounts then that’s a big box ticked for your accreditations and digital liability insurance also. This article does not cover enabling MFA in Azure, we are assuming you already have that enabled. I’ve covered that in other articles anyway, (use the search box above!)

Essentially your firewall will redirect authentication (via SAML) to Azure when you attempt to connect either via the web or tunnelled with the FortiClient.

Note: You can of course Use Azure MFA With Microsoft NPS (RADIUS) Server but this would require an additional server.

FortiClient Azure Authentication

FortiClient Azure Prerequisites

You will need an Azure subscription (a trial one is fine), obviously a FortiGate firewall, and a publicly signed certificate for the firewall (see below).

Note: Stop asking if you can use self signed certs – this one cost me six dollars! It needs to be publicly signed so Azure trusts it!

Add and Configure the FortiGate SSL VPN Application

From within your Azure tenancy, locate Enterprise applications and choose to add a new one.

Do a search for Forti and you should see the FortiGate SSL VPN application, select it.

In the setup single sign on  section, click ‘Get Started’.

Select SAML.

The ‘Vast Majority’ of the work that needs to be done will be done in here. In Section 1 (Basic SAML Configuration)  you will enter FOUR URLs (these URLs will reside on your FortiGate). 

Change the values in red to match your own publicly resolvable FQDN, (which will match the CN on your certificate).

Identifier (Entity-ID)

[box]

https://vpn.petenetlive.com/remote/saml/metadata

[/box]

Reply URL (Assertion Consumer Service URL)

[box]

https://vpn.petenetlive.com/remote/saml/login

[/box]

Sign on URL (Yes it’s the same as the one above!)

[box]

https://vpn.petenetlive.com/remote/saml/login

[/box]

Then scroll down.

Log out URL 

[box]

https://vpn.petenetlive.com/remote/saml/logout

[/box]

Then SAVE.

Section 2: Attributes and Claims, click edit.

Add a new claim.

Name = username, Source attribute = user.userprinciplename > Save.

Select the existing user.groups value > Change it to ‘All Groups’ > Tick ‘Customise the same of the group claim’ > Set the name to group > Save.

Note: It can take little while for the main page to refresh .

Section 3: SAML Signing Certificate. Download the Base64 version of the certificate.

Back on your FortiGate > System > Certificates > Import > Remote Certificate.

If you can’t see certificates click here.

Browse to and upload the certificate you just dowloaded.

Make a note of the certificate name, in this case it’s REMOTE_Cert_2 (You will need this later).

Section 4: Setup FortiGate SSL VPN. In this section there are three URLs that you need to take a copy of (they are used in the code block you will post into the FortiGate.

You now have all the elements you need to paste the following code block into your FortiGate, the following elements IN RED should be changed to match yours.

set-cert is the NAME that the FortiGate has given to its public cert, (mine’s the same as its common name, yours may be something else!)

entity-id, single-sign-on-url, and single-log-out-url are the URLs you pasted into section 1 (above).

idp-entity-id, idp-single-sign-on-url, and idp-single-log-out-url are the URLs you copied out of section 4 (above).

idp-cert is the NAME that the FortiGate has given to the cert you dowloaded from section 3 (above)

user-name and group-name are the attributes and claims you setup in section 2 (above).

[box]

config user saml
edit SSL-Azure-SAML
set cert vpn.petenetlive.com
set entity-id https://vpn.petenetlive.com/remote/saml/metadata
set single-sign-on-url https://vpn.petenetlive.com/remote/saml/login
set single-logout-url https://vpn.petenetlive.com/remote/saml/logout
set idp-entity-id https://sts.windows.net/de742342-edf0-49e7-8ca3-1402fddc17bc/
set idp-single-sign-on-url https://login.microsoftonline.com/de742342-edf0-49e7-8ca3-1402fddc17bc/saml2
set idp-single-logout-url https://login.microsoftonline.com/de742342-edf0-49e7-8ca3-1402fddc17bc/saml2
set idp-cert REMOTE_Cert_2
set user-name username
set group-name group
next
end

[/box]

Azure Groups

You will need a group in Azure created with the users that you wish to be able to authenicate into to the remote VPN. Take a copy of its Object ID (you will need that shortly).

With that object ID you can create a ‘Group’ on the FortiGate with the following code block

[box]

config user group
edit AAD-Remote-VPN
set member SSL-Azure-SAML
config match
edit 1
set server-name SSL-Azure-SAML
set group-name 02f047b1-8db2-4474-84df-21af6a16204c
next
end
next
end

[/box]

You will also need to add this group (In Azure) into the FortiGate SSL VPN application > users and groups > add user/group.

Click ‘None Selected” > Select your user group > Select.

Heed the warning! No nested groups, which is a little annoying, but you can’t say they didn’t warn you > Accept.

FortiGate SSL VPN

I’m going to use the basic settings to get this up and running, VPN > SSL VPN Settings > Listen on Interfaces (set to the outside facing interface (that the certificate name points to!) Server Certificate set to your publicly signed certificate > Scroll down.

Note: If you see a warning about not having configured SSL policy, dont worry we will fix that in a moment.

Create New.

Select the AAD user group (we created with the second code block) and set the Portal, (here I’m using full access so the remote client can use the web, or full tunnel options) > OK.

Policy & Objects > Firewall Policy > Create New.

Give the policy a sensible name > Incoming Interface will be SSL-VPN (Not outside!) > Outgoing interface is usually the inside (unless you have DMZs etc) > Source, add in All and your AAD-Group you created with the second code block above >  DISABLE NAT > Scroll down.

Change Logging to ‘All sessions’ (Note: once fully deployed, you can change this to security events) > OK.

Note: It may error at this point if the portal you have chosen, (in this case full-access) has split tunnelling enabled, you can either disable split tunnelling on the portal, or change All in the destination section to a particular subnet on the the LAN).

Testing Forti Web SSL With Azure

From an external client connect the web address of your FortiGate, all being well it should redirect you to Azure, (or your ADFS portal if you use ADFS).

Provision authentication is successful, you should see something like this.

Testing FortiClient Azure SSL VPN With Azure

Install the FortiClient, (here I’m using the VPN only version). Give the connect a sensible name > Set the gateway to your public FQDN, and tick ‘Enable Single Sign On (SSO) for VPN Tunnel > Save.

SAML Login

After your Microsoft authentication prompt appears, the client should connect successfully.

Related Articles, References, Credits, or External Links

Microsoft: Azure AD SSO with FortiGate

Fortinet: Configuring SAML SSO login for SSL VPN

Use Azure MFA With Microsoft NPS (RADIUS) Server

Posted on by
12

 

KB ID 0001759

Problem

I was in a forum last week and someone asked, “Can I enable Azure MFA, on my RADIUS server, to secure access to my switches and routers etc”. It turns out if you want to enable Azure MFA with Microsoft NPS it’s actually quite  simple.

So, I’m using RADIUS auth (above) on my NPS server, and it’s simply checking the authenticating user is a member of a domain security group. Once it has satisfied that requirement, it will authenticate against my Azure AD, which will trigger an MFA event, (in my case send a request to the Microsoft Authenticator Application on my Android Phone).

Azure MFA With Microsoft NPS Pre-Requisites

The remote user needs EITHER an Azure P1 License, or a Microsoft 365 license. 

“But I can use the Authenticator App with my Office 365 subscription?”

Well yes you can, but we are not authenticating to office 365 are we?

Below you can prove the licence is allocated in Office 365

And the same in Azure AD.

Now your user needs to have MFA enabled, (this should be pretty obvious), to use the Microsoft authenticator application the USER chooses that method of authentication, when you enable MFA for them (the first time they login). You can re-force that, from the following screen if you wish.

Azure MFA With Microsoft NPS: Deploying NPS

So I’ve pretty much covered this half a dozen times before, but for completeness I’ll quickly run though setting up NPS / NPAS. The quickest simplest method is to use PowerShell.

[box]

Install-WindowsFeature NPAS -IncludeManagmentTools

[/box]

From administrative tools open > Network Policy Server >Right click (Top Level) > Register Server in Active Directory  > OK > OK

Execute the following PowerShell command to create a registry key

[box]

New-Item 'HKLM:\SOFTWARE\Microsoft\AzureMfa' -Force | New-ItemProperty -Name REQUIRE_USER_MATCH -Value TRUE -Force | Out-Null

[/box]

Enable NPS RADIUS on Windows Firewall

Now for some reason installing NPS does not open the correct ports on the Windows Firewall? So issue the following command;

[box]

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

[/box]

Azure MFA With Microsoft NPS: Domain (on Premises and Azure AD)

You will need to know what your Azure Tenant ID is, keep a copy of this handy either in notepad or on the clipboard because you will need it in a minute.

Below you can see I’ve got my domain user, their remote access (Dial In Tab) is set to control access though policy, and I’ve placed them in a security group called SG-Azure-MFA.

Configure NPS for RADIUS Access

Note: You may already have this configured, if so please skip to the next section.

The first task is to define the RADIUS CLIENT, in my case it will be a Cisco firewall, yours could be any device that requires RADIUS authentication. Locate REDIUS Clients  > New > Provide a ‘Friendly Name’ (REMEMBER WHAT IT IS) > Enter its IP address > Then provide and confirm a shared secret (think of it like a password, you will need to add this to the radius clients config) > OK

Policies > Network Policies > New > Give it a sensible name > Next.

Add in a ‘Condition‘ for User Group, then add in the user group you created/used above.

Add in another ‘Condition‘ > Set the friendly name to the one you used when you created your RADIUS client.

Accepts all the defaults until you get to Configure Authentication Methods > Tick ‘Unencrypted Authentication (PAP, SPAP)’> Click yes if you want to read the warning > Next > Accept all the defaults from this point forward.

Enable Azure MFA With Microsoft NPS

Download the ‘NPS Extension For Azure MFA‘ software form Microsoft, and install it on your NPS server.

To actually enable it against your Azure AD, Execute the following PowerShell commands;

[box]

cd "c:\Program Files\Microsoft\AzureMfa\Config"
.\AzureMfaNpsExtnConfigSetup.ps1

[/box]

Eventually you will be asked to authenticate to Azure, do so with an administrative account.

You will be asked to provide your Azure Tennant ID.

When complete REBOOT THE NPS SERVER!

Testing Azure MFA With NPS

Again for Cisco ASA I’ve already blogged about this, but for completeness here’s me making sure it works;

Remember to RAISE the RADIUS timeout, by default its 10 seconds, I raised it to 30 seconds.

And on my phone I get prompted to allow

 

Authentication successful!

Troubleshooting (NPS Azure MFA Not Working)

Event ID 6274: The Request Was Discarded by a third-party extension DLL file. 

This happens when the user you are authenticating does not have the correct license in Azure (or you have just allocated the license and have not waited for a while).

Full Error

[box]

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          15/07/2021 16:42:58
Event ID:      6274
Task Category: Network Policy Server
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      PKI-02.pnl.com
Description:
Network Policy Server discarded the request for a user.

Contact the Network Policy Server administrator for more information.

User:
	Security ID:			PNL\tanya.long
	Account Name:			tanya.long
	Account Domain:			PNL
	Fully Qualified Account Name:	pnl.com/PNL/Users/Tanya Long

Client Machine:
	Security ID:			NULL SID
	Account Name:			-
	Fully Qualified Account Name:	-
	Called Station Identifier:		-
	Calling Station Identifier:		-

NAS:
	NAS IPv4 Address:		192.168.254.254
	NAS IPv6 Address:		-
	NAS Identifier:			-
	NAS Port-Type:			Virtual
	NAS Port:			6

RADIUS Client:
	Client Friendly Name:		Firewall
	Client IP Address:			192.168.254.254

Authentication Details:
	Connection Request Policy Name:	Use Windows authentication for all users
	Network Policy Name:		NP-Azure-MFA
	Authentication Provider:		Windows
	Authentication Server:		PKI-02.pnl.com
	Authentication Type:		PAP
	EAP Type:			-
	Account Session Identifier:		-
	Reason Code:			9
	Reason:				The request was discarded by a third-party extension DLL file.

[/box]

Event ID 6273: An NPS extension dynamic link library (DLL) that is installed on the NPS server rejected the connection

In my case I had re-install the NPS Azure extension.

Full Error

[box]

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          15/07/2021 17:24:39
Event ID:      6273
Task Category: Network Policy Server
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      PKI-02.pnl.com
Description:
Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
	Security ID:			NULL SID
	Account Name:			tanya.long
	Account Domain:			PNL
	Fully Qualified Account Name:	PNL\tanya.long

Client Machine:
	Security ID:			NULL SID
	Account Name:			-
	Fully Qualified Account Name:	-
	Called Station Identifier:		-
	Calling Station Identifier:		-

NAS:
	NAS IPv4 Address:		192.168.254.254
	NAS IPv6 Address:		-
	NAS Identifier:			-
	NAS Port-Type:			Virtual
	NAS Port:			10

RADIUS Client:
	Client Friendly Name:		Firewall
	Client IP Address:			192.168.254.254

Authentication Details:
	Connection Request Policy Name:	Use Windows authentication for all users
	Network Policy Name:		-
	Authentication Provider:		Windows
	Authentication Server:		PKI-02.pnl.com
	Authentication Type:		Extension
	EAP Type:			-
	Account Session Identifier:		-
	Logging Results:			Accounting information was written to the local log file.
	Reason Code:			21
	Reason:				An NPS extension dynamic link library (DLL) that is installed on the NPS server rejected the connection request.

[/box]

 

Related Articles, References, Credits, or External Links

NA

AnyConnect 4 – Plus and Apex Licensing Explained

Posted on by

KB ID 0001013 

Problem

(Updated 11/05/21)

Before version 4 we simply had AnyConnect Essentials and Premium licensing, now we have Plus and Apex licensing.

AnyConnect Plus and Apex

There are in fact three licensing options;

  • Cisco AnyConnect Plus Subscription Licenses
  • Cisco AnyConnect Plus Perpetual Licenses
  • Cisco AnyConnect Apex Subscription Licenses
  • NEW VPN Only perpetual Licences

Plus and Apex Contain;

AnyConnect PLUS (Cisco pitch “Equivalent to the old Essentials License”).

  • VPN functionality for PC and mobile platforms, including per-app VPN on mobile platforms.
  • Basic endpoint context collection (Note: NOT full ISE context support).
  • IEEE 802.1X Windows supplicant.
  • Cisco Cloud Web Security agent for Windows & Mac OS X platforms.
  • Cisco Web Security Appliance support.
  • FIPS compliance.

AnyConnect APEX (Cisco pitch “Equivalent to the old Premium License”).

  • Everything that’s included in AnyConnect Plus.
  • Clientless (browser-based) VPN termination on the Cisco ASA.
  • VPN Compliance/Posture agent in conjunction with the Cisco ASA.
  • Unified Compliance/Posture agent in conjunction with the Cisco ISE 1.3 or later.
  • Next Generation Encryption/Suite B.

Both licenses are available as 1, 2 and 5 (not 3 as listed on the Cisco website) year subscription, or you can buy Plus licenses with a perpetual license option.

Note: For PLUS Licences looks at SKUs starting  L-AC-PLS, for APEX Licences look SKUs starting at L-AC-APX

(Note: if you have a Plus Perpetual license you still need to purchase a software applications support plus upgrades (SASU) contract.

Regardless of which you buy, the SASU for AnyConnect is NOT included in the support contract for the parent device e.g. the SmartNet on your Cisco ASA Firewall.

To purchase support you order the parent license (SKU: L-AC-PLS-P-G) which has no cost, then you add in the relevant license for the amount of clients you have e.g. AC-PLS-P-500-S for 500 users, AC-PLS-P-2000-S for 2000 users etc.

BE AWARE: AnyConnect 4 Licenses will display as AnyConnect Premium licenses when you issue a ‘show version’ command. When adding an AnyConnect 4 License (regardless of the quantity of licenses added), will license to the maximum permitted AnyConnect Premium license count for the ASA hardware platform, those being;

New AnyConnect VPN Only Licences (Perpetual)

You can now purchase VPN Only perpetual licences, they are sold by ‘Concurrent VPN Connection‘. You order them like so;

L-AC-VPNO-25 (for 25 concurrent VPN connections) you can also buy in 50, 100, 250, 500, 1K, 2500, 5K ,and 10K versions. Depending on what you device will physically support (see below)

Cisco ASA Maximum VPN Peers / Sessions

Cisco Firepower Firewalls

FPR-1010 = 75
FPR-1120 = 150
FPR-1130 = 400
FPR-1140 = 800
FPR-2110 = 1500
FPR-2120 = 3500
FPR-2130 = 7500
FPR-2140 = 10,000
FPR-4110 = 10,000
FPR-4112 = 10,000
FPR-4115 = 15,000
FPR-4120 = 20,000
FPR-4125 = 20,000
FPR-4140 = 20,000
FPR-4145 = 20,000
FPR-4150 = 20,000
FPR-9300-SM24 = 20,000 
FPR-9300-SM36 = 20,000
FPR-9300-SM40 = 20,000
FPR-9300-SM44 = 20,000
FPR-9300-3xSM44 = 60,000
FPR-9300-SM48 = 20,000
FPR-9300-SM56 = 20,000
FPR-9300-SM3x56 = 60,000

Cisco ASA 5500-X Firewalls
5506-X = 50
5508-X = 100
5512-X = 250
5515-X = 250
5516-X = 300
5525-X = 750
5545-X = 2500
5555-X = 5000
5585-X = 10,000
Cisco ASA 5500 Firewalls

5505 = 25 
5510 = 250 
5520 = 750 
5540 = 5,000 
5550 = 5,000 
5580 = 10,000

Cisco ASAv Firewalls

ASAv5  = 50
ASAv10 = 100
ASAv30 = 750
ASAv50 = 10,000
 

Related Articles, References, Credits, or External Links

Cisco AnyConnect – Essentials / Premium Licenses Explained

Cisco ASA 5500 – Adding Licenses

Cisco AnyConnect Ordering Guide

Cisco ASA to Fortigate VPN (Properly!)

Posted on by
2

KB ID 0001721

Problem

A while ago I did a run through on site to site VPNs from Cisco ASA to Fortigate firewalls. Back then I said that the default settings were a bit ‘shoddy‘ and that I’d revisit it once I had more time.

What do you mean shoddy? Well, Cisco and Fortinet are both guilty of enabling ‘Everything’ to make the tunnel come up, so people can just use a wizard and not put to much thought into the process, for most people thats absolutely fine. However I’ve found ‘Many Times‘ I’ve been trying to put a VPN into third party and it’s like a game of ‘Encryption Bingo‘ e.g. ‘Can you change it from AES128 to AES256 and change the hash to SHA512‘, or ‘Do you not support elliptical curve’. Who are these people? Do they expect Tom Cruise  to come rappelling out of a skylight to steal the details of their 2016 Christmas golf event!

I digress, so here’s how to set up a site to site VPN using IKEv2 with some weapons grade encryption. Here’s a pretty picture of what it will look like;

And here’s what my test bench topology looks like in EVE-NG.

Configuring the Fortigate for Site to Site VPN

After saying don’t use the wizard, I’m going to use the wizard to do the Fortigate end, then I’ll edit the tunnel it creates and make it a bit more ‘fit for purpose’.

From the web management portal > VPN > IPSec Wizard  > Give the tunnel a name > Change the remote device type to Cisco > Next.

Give it the ‘public’ IP of the Cisco ASA > Set the port to the ‘outside’ port on the Fortigate > Enter a pre-shared key, (text string, you will need to enter this on the Cisco ASA as well, so paste it into Notepad or something for later) > Next.

Local interface will be in the ‘inside’ interface on the Fortigate > Enter the local subnet(s) > Enter the remote (behind the ASA) subnet(s) > Next.

Review the settings > Create.

Select IPSec Tunnels > Select the new tunnel  > Edit.

In the Authentication Section > Edit > Change the IKE Version to 2 > Edit the Phase 1 Proposal.

Note: If you can’t see this option, change the tunnel type to custom.

Delete all the factory ones and add one for;

Then under Phase 2 Selectors click the pencil icon to edit.

Advanced.

Remove any existing Phase 2 proposals, add a new one

Encryption: AES256GCM 

Click OK to close.

Manually Configuring the Cisco ASA For Site to Site VPN

Manual VPN via CLI

We all know real men work at command line, paste this in, boom done!

WARNING: If your ASA already has a crypto map then use the name of that map rather than CRYPTO-MAP (as below) or all your existing VPNs will break!

[box]

!
crypto ikev2 policy 5
 encryption aes-gcm-256
 integrity null
 group 21
 prf sha512
 lifetime seconds 86400
crypto ikev2 enable outside
!
object network OBJ-SITE-B
subnet 172.16.1.0 255.255.255.0
object network OBJ-SITE-A
subnet 192.168.1.0 255.255.255.0
!
access-list VPN-INTERESTING-TRAFFIC extended permit ip object OBJ-SITE-B object OBJ-SITE-A
!
nat (inside,outside) source static OBJ-SITE-B OBJ-SITE-B destination static OBJ-SITE-A OBJ-SITE-A no-proxy-arp route-lookup
!
tunnel-group 192.168.100.100 type ipsec-l2l
tunnel-group 192.168.100.100 ipsec-attributes
ikev2 remote-authentication pre-shared-key 123456
ikev2 local-authentication pre-shared-key 123456
isakmp keepalive threshold 10 retry 2
!
crypto ipsec ikev2 ipsec-proposal VPN-FORTIGATE
 protocol esp encryption aes-gcm-256
 protocol esp integrity null
!
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC
crypto map CRYPTO-MAP 1 set peer 192.168.100.100
crypto map CRYPTO-MAP 1 set ikev2 ipsec-proposal VPN-FORTIGATE
crypto map CRYPTO-MAP interface outside
!

[/box]

Manual VPN via ASDM

You can do the first couple of steps together, but I like to do the Phase1 and Phase 2 proposals first, then tie it all up at the end. Configuration > Site to Site VPN > Advanced > IKE Policies > IKEv2 Policies > Add.

  • Priority: 5
  • D-H Group: 21
  • Encryption: AES-GCM-256 
  • Integrity Hash: null (GCM protocols don’t need an integrity hash)
  • Pseudo Random Function (PRF) Hash: sha512

OK > Apply

Now for Phase 2 (On a Cisco ASA that’s defined with a ‘transform  set’). IPsec  Proposals (Transform Sets)  > IKEv2 > Add.

OK > Apply

Connection Profiles > Tick IKEv2 on the OUTSIDE interface to enable it.

Connection Profile > Add

  • Peer IP: (Public address of the Fortigate)
  • Local Network: Add in the network behind the ASA.
  • Remote Network: You may need to add an object-group for the remote network (behind the Fortigate).
  • Group Policy Name: FORTIGATE_VPN
  • Local Passphrase: An alphanumeric string of characters (it’s a pre-shared key it must match the one you set on the Fortigate).
  • Remote Passphrase: Set the same at the local passphrase.

Scroll down.

Make sure your IKE  Phase 1 policy is in the list, (you may have many) > IPSec proposal > Select > locate yours and add it in > OK > OK > Apply.

The last thing to do is make sure that the traffic travelling over the VPN DOES NOT get NAT translated > Firewall > NAT Rules > Select the top one > Add  >Add Nat Rule Before.

  • Source Interface: inside
  • Destination Interface: outside
  • Source Address: any
  • Destination Address: {The group you created above for the network address behind the Fortinet}
  • Source NAT Type: Static
  • Disable Proxy ARP :  Tick
  • Lookup Route Table: Tick

OK > Apply

Don’t forget to save the changes > File > Save Running configuration to flash

Finally send some interesting traffic across the VPN to bring up the tunnel.

Related Articles, References, Credits, or External Links

NA

Fortigate to Cisco ASA Site to Site VPN

Posted on by
2

KB ID 0001717

Problem

Continuing with my ‘Learn some Fortigate‘ theme’. One of the basic requirements of any edge firewall is site to site VPN. As the bulk of my knowledge is Cisco ASA it seems sensible for me to work out how to VPN both those firewalls together, like so;

Well that’s the pretty picture, I’m building this EVE-NG so here’s what my workbench topology looks like;

Disclaimer (Read First! Especially before posting any comments!)

Fortinet prides itself on you not needing to use the CLI, (until you actually need to use the CLI of course!) But both ends are configured using the GUI and ASDM. This is designed for the ‘Let’s just make it work, who cares what’s going on under the hood‘ generation. Which means it enables IKEv1 NOT IKEv2 on the Fortigate, and BOTH IKEv1 and IKEv2 gets enabled on the Cisco ASA. Couple that with all the weak Crypto sets that get enabled, because someone might have a hardware firewall from 1981 or something! So in production I’d consider doing things a little more manually. I will post another article on the same subject, but then I’ll make the tunnel as secure as I can, (watch this space). This is an exercise in getting the tunnel up and making it work.

Tech Note: If you just use both wizards it wont work, thankfully I could debug the tunnel on the Cisco ASA to work out why. Fortinet sets all the DH groups to 5, and Cisco sets them all to 2. And Fortinet enables PFS and Cisco don’t. (They do on older versions of the OS, but not on the newer ones).

Create IKE/IPSec VPN Tunnel On Fortigate

From the web management portal > VPN > IPSec Wizard  > Give the tunnel a name > Change the remote device type to Cisco > Next.

Give it the ‘public’ IP of the Cisco ASA > Set the port to the ‘outside’ port on the Fortigate > Enter a pre-shared key, (text string, you will need to enter this on the Cisco ASA as well, so paste it into Notepad or something for later) > Next.

Local interface will be in the ‘inside’ interface on the Fortigate > Enter the local subnet(s) > Enter the remote (behind the ASA) subnet(s) > Next.

Review the settings > Create.

Select IPSec Tunnels > Select the new tunnel  > Edit.

Convert to Custom Tunnel.

Phase 1 Proposal > Edit.

Add in Diffie Hellman Group 2

Phase 2 Selectors > Edit > Advanced > Untick Enable Perfect Forward Secrecy > OK.

Create IKE/IPSec VPN Tunnel On Cisco ASA (ASDM)

Connect to the ASDM > Wizards  > VPN Wizards > Site-to-Site VPN Wizard > Next.

You should already have an object for your Local Network add that in > Then add in a new Network Object for the remote (behind the Fortigate) subnet. MAKE SURE that the new object is selected as the Remote Network > Next.

Enter the Pre-Shared key you used (above)  > Next > Tick to DISABLE NAT > Next > Finish.

Tech Note: Look at all those Ciphers/Hashing/Additional Protocols that are about to be turned on! 🙁 That’s why I work at command line.

Finally you will need to send some traffic over the tunnel to ‘bring it up’.

If you have a problem, see the debugging/troubleshooting links below.

Related Articles, References, Credits, or External Links

Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels

Troubleshooting Phase 2 Cisco Site to Site (L2L) VPN Tunnels

AnyConnect: ‘Quick and Dirty’ Duo 2FA

Posted on by
4

KB ID 0001701

Problem

Normally if I were deploying Duo 2FA with AnyConnect I’d deploy a Cisco RADIUS VPN on my LAN, (usually on my Duo Authentication Proxy). See the following article;

AnyConnect: Enable Duo 2Factor Authentication

However, last time I set this up, a colleague said ‘Oh by the way, you don’t need to do that, you can just point the firewall directly at Duo‘. I was initially skeptical but I tried it, and it worked. I thought no more about it until this week when another colleague asked me to help him setup Duo for AnyConnect.

As you can see the firewall queries Duo using LDAPS, but the Duo product I’m using is called ‘Cisco RADIUS VPN’. This makes my networking OCD itch tremendously! (RADIUS and LDAPS are completely different protocols!) But it works, so here we go.

Solution

Note: For this solution you don’t even need to sync your users to Duo, (but it’s OK if you do)! As long as the users exist there.

With Duo, you need to select ‘protect an application‘ and select ‘Cisco RADIUS VPN‘. If you are unfamiliar with Duo you need to take a copy of the Integration Key, the Secret Key and the API Hostname. (Note: Don’t try using these ones, they have been changed!)

On the Firewall > Configuration > Device Management > Users/AAA > AAA Server Groups > AAA Server Groups > Add > Call it ‘DUO-EXTERNAL’ > Select LDAPS > OK.

With your DUO-EXTERNAL group selected > In the bottom window > Add.

  • Interface Name: {Your outside interface name}
  • Servername: {Your Duo API Hostname}
  • Timeout: 60 
  • Enable LDAP over SSL: Enabled
  • BaseDN: dc={Your Integration Key},dc=duosecurity,dc=com
  • Naming Attribute: cn
  • Login DN: dc={Your Integration Key},dc=duosecurity,dc=com
  • Login Password: {Your Secret Key}

OK > Apply.

TO TEST: Press Test > Select Authentication > Use the username displayed in Duo > Type push into the password box, and your phone should then prompt for 2fa authentication. (If it fails: Make sure the time is correct on the ASA, and at least do some debugging before posting below!)

Now either create a new AnyConnect profile, and use this new AAA method, or simply change the AAA method for an existing AnyConnect profile, (like below).

A word of warning, when I did this, (both in production and on my test ASA,) I got a strange error, I’ve documented that and the fix, below.

AnyConnect: Unauthorized Connection Mechanism

Related Articles, References, Credits, or External Links

NA

Cisco ASA VPN Static to Dynamic IP (DHCP)

Posted on by
5

KB ID 0001683

Problem

I had a call with a client last week, they are in one of my employer’s DCs, and their servers are behind a vASA. They had purchased some Meraki MX devices for their IT team who were working remotely (during the Covid-19 lockdown), and were struggling. Normally we would just suggest AnyConnect, but these guys were building new machines for  their clients, and needed access directly to the domain from their home networks to facilitate this. So a Site-to-Site VPN was the ‘best fit’ for them.

But being home internet connections they were on DHCP for their public IP addresses. If we were all Meraki, then Meraki Auto VPN would have them up and running in no time. Conversely if they were all ‘proper’ Cisco we would be OK. In fact if they had static IP’s at home we would be OK.

So how to setup a site-to-site VPN ‘into’ a Cisco ASA with a static IP,  from another firewall with a dynamically assigned (DHCP) public IP?

I tested this firstly using a Cisco ASA at the ‘remote/dynamic’ end, then tested with a Meraki MX Device. But the methodology can be applied to any ISAKMP/IPSEC capable firewall with a dynamically assigned public IP that you want to establish a VPN into an ASA with a static IP address.

Solution

Step 1: Investigate Your Remote Device

Do your homework on the remote device, find out what it supports for VPN connectivity, you will need to answer the following questions;

  • IKE Version: Does it use/support IKEv1 or IKEv2 (or both) Set the ASA config accordingly
  • Phase 1 Encryption: What does it support? DES <- Don’t Use this if you can avoid it! 3DES, AES, AES-128, AES-192, AES-256 etc.
  • Phase 1 Hashing: What does it support? MD5, SHA/SHA1, SHA256 etc.
  • Phase 1 Diffie Hellman Group (for IKEv1): Group 1,2,5,14 etc.
  • Lifetime: {in seconds}
  • Pseudorandom function (for IKEv2): MD5, SHA1 or SHA256
  • Phase 2 (IPSEC) Encryption: 3DES, AES, AES-128, AES-192, AES-256 etc.
  • Phase 2 (IPSEC) Hashing: MD5, SHA1 or SHA254
  • Phase 2 PFS: Off or DH1, DH2, DH5, or DH14 etc.
  • Subnet on the remote site: Make sure it does not overlap with your central site, (or anyone else who will also be ‘dynamically’ connecting*).
  • Pre-Shared-Key: MAKE SURE this is long/complicated and hard to guess. 

*Note This may mean your remote sites may need to change their subnets so they don’t overlap!

Step 1 Configure the ‘Central’ ASA

I’ve covered IKEv1 VPNs and IKEv2 VPNs elsewhere on the site, feel free to go and see what what the following configuration is doing. For my Meraki Tunnel I’m going to use IKEv1, Phase 1 (3DES, SHA, Diffie Hellman Group 2, and a Lifetime of 86400 Seconds,) and Phase 2 (3DES, SHA and no PFS). Note: Some would consider this weak, but it’s the default setting on the remote device so lets keep it simple. In production you can slowly make phase1/2 more secure to your liking once you know it’s working.

Change the values in Red;

WARNING: If you already have a crypto map in use then change the keyword CRYPTO-MAP (below) to match yours. (Or all your VPNs will suddenly stop working!) Issue the command show run crypto map, if you’re unsure.

[box]

!
object network OBJ-MainSite
subnet 192.168.100.0 255.255.255.0
object network OBJ-RemoteSite-01
subnet 192.168.1.0 255.255.255.0
!
nat (inside,outside) source static OBJ-MainSite OBJ-MainSite destination static OBJ-RemoteSite-01 OBJ-RemoteSite-01 no-proxy-arp route-lookup
!
crypto ikev1 policy 65535
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
crypto ikev1 enable outside
!
crypto ipsec ikev1 transform-set TS-IPSEC-VPN esp-3des esp-sha-hmac
!
crypto dynamic-map DYNAMIC-CRYPTO-MAP 65535 set ikev1 transform-set TS-IPSEC-VPN
crypto dynamic-map DYNAMIC-CRYPTO-MAP 65535 set reverse-route
crypto map CRYPTO-MAP 65535 ipsec-isakmp dynamic DYNAMIC-CRYPTO-MAP
crypto map CRYPTO-MAP interface outside
!
tunnel-group DefaultL2LGroup ipsec-attributes
 ikev1 pre-shared-key V3ryL0ng&H@rd2Gue55
!

[/box]

Step 3: Configure the Remote (DHCP) Firewall

If the remote end was going to be another Cisco ASA, here’s the config;

[box]

object network OBJ-MainSite
 subnet 192.168.1.0 255.255.255.0 
object network OBJ-RemoteSite
 subnet 192.168.100.0 255.255.255.0 
! 
access-list VPN-INTERESTING-TRAFFIC extended permit ip object OBJ-RemoteSite object OBJ-MainSite 
nat (inside,outside) source static OBJ-RemoteSite OBJ-RemoteSite destination static OBJ-MainSite OBJ-MainSite no-proxy-arp route-lookup 
!
crypto ikev1 policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
crypto ikev1 enable outside
!
crypto ipsec ikev1 transform-set VPN-TRANSFORM esp-3des esp-sha-hmac
!
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC 
crypto map CRYPTO-MAP 1 set peer 203.0.113.1 
crypto map CRYPTO-MAP 1 set ikev1 transform-set VPN-TRANSFORM 
crypto map CRYPTO-MAP interface outside
!
tunnel-group 203.0.113.1 type ipsec-l2l
tunnel-group 203.0.113.1 ipsec-attributes
pre-shared-key V3ryL0ng&H@rd2Gue55
isakmp keepalive threshold 10 retry 2

[/box]

Note For IKEv2 sample ASA Configs, Click Here

However if the remote end was going to be a Meraki Device.

Log into the Meraki Portal, and select your ‘customer’ (if you have more than one) > Security & SD WAN > Site-to-Site VPN.

Type: Hub > Scroll down.

Non-Meraki VPN Peers > Add a peer.

  • Name: Give it a sensible name.
  • IKE Version: IKEv1 (Note some versions don’t support IKEv2).
  • Public IP :Of the ASA.
  • Private Subnets: The subnet(s) behind the ASA.
  • Availability: ‘All Networks’ Unless you want to filter it.
  • Save.

Note: Should you wish to change any phase1/phase2 settings, click the link that says ‘Default‘ under IPSec policies.

 

Related Articles, References, Credits, or External Links

Special thanks to Paul White for putting me on the right road, and to Andrew Dorrian for taking the time to test the Meraki VPN config for me.

Cisco Firepower 1010 Configuration

Posted on by
3

KB ID 0001673

Background

This page will be used as a central repository and ‘index’ for configuration on the Cisco Firepower 1010 series firewall. I intend to add to it as I test the capabilities and work out any problems whilst trialing/deploying and operating this platform.

Config Documents

VPN Firepower 1000 series running ASA Code.

General

Cisco Firepower 1010 Licensing

Reimage Cisco 1010 ASA to FTD

VPN

EZVPN

Is not supported on this platform, it cannot be configured as an EZVPN client.

Site to Site VPN (as per older 5500-x and 5500 series)

Cisco ASA Site To Site VPN IKEv2 “Using CLI”

Cisco ASA Site To Site VPN IKEv1 “Using CLI” (Only normally required, if the other end does not support IKEv2)

Cisco ASA Site to Site VPN ‘Using ASDM’

Remote Access VPN

Cisco ASA AnyConnect VPN ‘Using CLI’

Cisco ASA AnyConnect VPN ‘Using ASDM’

Cisco ASA – L2TP over IPSEC VPN ‘Using CLI or ASDM’ (Using Windows 10 Built in VPN client)

Port Forwarding and NAT

Cisco ASA Port Forwarding ‘Using CLI or ASDM’

Cisco ASA Port Forwarding To A Different Port

Cisco ASA Port Forwarding a ‘Range of Ports’

Cisco ASA Static (One to One) NAT Translation

 

VPN Firepower 1000 series running FTD Code.

General

Cisco Firepower 1010 (FTD) Initial Setup

Cisco FTD: AMP/URL Filtering/Threat Detection and AVC

VPN

Site to Site VPN 

Cisco FTD Site to Site VPN

Remote Access VPN 

Cisco FTD Remote Access VPN (AnyConnect)

Cisco FTD (and ASA) Creating AnyConnect Profiles

 

 

I will continue to add to this page but please be patient. (I’m juggling two jobs, and have a personal life!)

Related Articles, References, Credits, or External Links

NA

VMware Edge Gateway VPN to Cisco ASA

Posted on by
Reply

KB ID 0001658

Problem

I was asked to setup a VPN to help out a colleague this week. When I had a look, one end turned out to be an Edge Gateway, I wasn’t that concerned, I’d done similar things in my prior role, I just didn’t have access to the vCloud or VMware at this datacenter.

Depite my best efforts on the ASA, the tunnel refused to come up, it took a little looking ‘under the covers’ to accurately diagnose the problem. But to save you my pain, I’ll post the setup of both ends so yours will be a little less stressful.

VMware Edge Gateway VPN Setup

Locate the Edge Gateway in vCloud Director > VPN > Create new VPN > Tick ‘Enable This VPN‘ configuration > Set the local and remote networks > Local ID is the local public IP of the Edge Gateway > Remote ID is the pubic IP of the Cisco ASA > Set the encryption protocol as AES256 > Copy the pre-shared-key (Warning: some browsers wont select all of the key, and you will end up characters short, make sure you have it all!) > OK.

On the ‘Firewall’ Tab allow all traffic TO and FROM the remote subnet, (behind the Cisco ASA).

Note: There no need to make a NAT Exemption.

Cisco ASA VPN Setup (For Edge Gateway)

Note: The version of Edge Gateway I was using, was using (once AES256 is selected) 

  • IKE Version: 1
  • Encryption:AES-256
  • Hashing: SHA
  • Diffie Hellman: Group 2
  • Perfect Forward Secrecy: Enabled (group 2)

I’m aware that newer Edge Gateways support IKEv2 but debugging the incoming requests told me mine was using IKEv1.

[box]

crypto ikev1 enable outside
!
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
!
object network OBJ-vCloud-SN
subnet 172.16.10.0 255.255.255.0
object network OBJ-Site-SN
subnet 172.22.10.0 255.255.255.0
!
access-list VPN-INTERESTING-TRAFFIC extended permit ip object OBJ-vCloud-SN object OBJ-Site-SN
nat (inside,outside) source static OBJ-vCloud-SN OBJ-vCloud-SN destination static OBJ-Site-SN OBJ-Site-SN no-proxy-arp route-lookup
!
tunnel-group 123.123.123.123 type ipsec-l2l
tunnel-group 123.123.123.123 ipsec-attributes
pre-shared-key gT65C9Muwjx4q73tXaxu9gge6psqyr83qcu93xL8xkdk594yzNgf4jeoj7ax85Nc
isakmp keepalive threshold 10 retry 2
!
crypto ipsec ikev1 transform-set VPN-TRANSFORM esp-aes-256 esp-sha-hmac
!
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC
crypto map CRYPTO-MAP 1 set pfs group2
crypto map CRYPTO-MAP 1 set peer 123.123.123.123
crypto map CRYPTO-MAP 1 set ikev1 transform-set VPN-TRANSFORM
!
crypto map CRYPTO-MAP interface outside
!

[/box]

WARNING

Above assumes;

  1. Your interfaces are called inside, and outside.
  2. You DO NOT have any existing VPNs configured, (if you do, change the name of the CRYPTO-MAP (above) to match the name of your cryptomap and use a higher number, e.g. ‘outside_map 2‘).

Troubleshooting Edge Gateway End of the VPN

You need access to the underlying VMware infrastructure > Select Networking and Security > Locate the NSX Edge > VPN > IPsec VPN > Show IPsec Statistics > Here you can see some meaningful error massages if theres a problem.

Troubleshooting Cisco ASA End of the VPN

I’ve covered this to death in the past, so rather than reinvent the wheel;

Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels

Troubleshooting Phase 2 Cisco Site to Site (L2L) VPN Tunnels

Related Articles, References, Credits, or External Links

NA

Cisco ASA Site To Site VPN IKEv2 “Using CLI”

Posted on by
42

KB ID 0001429

Problem

Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.

You want a secure IPSEC VPN between two sites using IKEv2.

Note: If the device you are connecting to does not support IKEv2 (i.e. it’s not a Cisco ASA, or it’s running code older than 8.4) then you need to go to the older version of this article;

Cisco ASA 5500 Site to Site VPN IKEv1 (From CLI)

Solution

Before you start – you need to ask yourself “Do I already have any IPSEC VPN’s configured on this firewall?” Because if it’s not already been done, you need to enable ISAKMP IKEv2 on the outside interface. To ascertain whether yours is on or off, issue a “show run crypto ” command and check the results, if you do NOT see  “crypto ikev2 enable outside” then you need to issue that command.

[box]

PetesASA# show run crypto
crypto ikev2 enable outside << Mines already enabled and its IKE version 2
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 19
 prf sha256
 lifetime seconds 86400
crypto ikev2 enable outside

[/box]

1. I’m going to create access control lists next, one to tell the ASA what is “Interesting traffic”, that’s traffic that it needs to encrypt.

So below I’m saying “Don’t NAT Traffic from the network behind the ASA (10.254.254.0) that’s going to network behind the VPN device at the other end of the tunnel (172.16.254.0).

[box]

PetesASA(config)#object network Site-A-SN
PetesASA(config-network-object)#subnet 10.254.254.0 255.255.255.0
PetesASA(config)#object network Site-B-SN
PetesASA(config-network-object)#subnet 172.16.254.0 255.255.255.0
PetesASA(config)#access-list VPN-INTERESTING-TRAFFIC line 1 extended permit 
ip object Site-A-SN object Site-B-SN
PetesASA(config)#nat (inside,outside) source static Site-A-SN Site-A-SN 
destination static Site-B-SN Site-B-SN no-proxy-arp route-lookup

[/box]

2. Now I’m going to create a “Tunnel Group” to tell the firewall it’s a site to site VPN tunnel “l2l”, and create a shared secret that will need to be entered at the OTHER end of the site to site VPN Tunnel. I also set a keep alive value.

Note: Ensure the Tunnel Group Name is the IP address of the firewall/device that the other end of the VPN Tunnel is terminating on.

[box]

PetesASA(config)# tunnel-group 123.123.123.123 type ipsec-l2l
PetesASA(config)# tunnel-group 123.123.123.123 ipsec-attributes
PetesASA(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key 1234567890
PetesASA(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key 1234567890
PetesASA(config-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2
PetesASA(config-tunnel-ipsec)# exit

[/box]

3. Now we need to create a policy that will setup how “Phase 1” of the VPN tunnel will be established. It sets the encryption type (AES-256), the hashing/integrity algorithm (SHA-256), The Diffie Hellman group exchange version, and the Level of PRF (Pseudo Random Function). Finally it sets the timeout before phase 1 needs to be re-established. It sets the timeout value to 86400 seconds (That’s 1440 Minutes – or 24 hours if your still confused 🙂 ).

[box]

PetesASA(config)# crypto ikev2 policy 10
PetesASA(config-ikev1-policy)# encryption aes-256
PetesASA(config-ikev1-policy)# integrity sha256
PetesASA(config-ikev1-policy)# group 19
PetesASA(config-ikev1-policy)# prf sha256
PetesASA(config-ikev1-policy)# lifetime 86400

[/box]

4. We stated above that we are going to use AES-256 and SHA-256, for Phase 1, so let’s use the same for the IPSEC proposal (Phase 2), ‘Transform Set’.

[box]

PetesASA(config)# crypto ipsec ikev2 ipsec-proposal VPN-TRANSFORM
PetesASA(config-ipsec-proposal)# protocol esp encryption aes-256
PetesASA(config-ipsec-proposal)# protocol esp integrity sha-1

[/box]

5. Finally we need to create a “Cryptomap”, this is the ‘thing’ that fires up the tunnel, when the ACL INTERESTING TRAFFIC is used, it also defines the transform set for “Phase 2” of the VPN Tunnel, that will also use 3DES and SHA and PFS. And last of all we apply that Cryptomap to the outside interface.

[box]

PetesASA(config)# crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC 
PetesASA(config)# crypto map CRYPTO-MAP 1 set peer 123.123.123.123
PetesASA(config)# crypto map CRYPTO-MAP 1 set ikev2 ipsec-proposal VPN-TRANSFORM
PetesASA(config)# crypto map CRYPTO-MAP interface outside
 

[/box]

5. Don’t forget to save your hard work with a “write mem” command.

[box]

PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 5c8dfc45 ee6496db 8731d2d5 fa945425

8695 bytes copied in 3.670 secs (2898 bytes/sec)
[OK]
PetesASA(config)#

[/box]

6. Simply configure the other end as a “Mirror Image” of this one.

ASA 5500 Site to Site IKEv2 VPN Copy and Paste Config

Note: This uses AES-256 and SHA-256. It also assumes your outside interface is called ‘outside’. Check! I’ve seen them called Outside (capital O), wan, and WAN.

[box]

!
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 19
 prf sha256
 lifetime seconds 86400
crypto ikev2 enable outside
!
object network OBJ-SITE-A
subnet 10.0.0.0 255.255.255.0
object network OBJ-SITE-B
subnet 10.0.3.0 255.255.255.0
!

access-list VPN-INTERESTING-TRAFFIC extended permit ip object OBJ-SITE-A object OBJ-SITE-B
nat (inside,outside) source static OBJ-SITE-A OBJ-SITE-A destination static OBJ-SITE-B OBJ-SITE-B no-proxy-arp route-lookup
!
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev2 remote-authentication pre-shared-key 1234567
ikev2 local-authentication pre-shared-key 1234567
isakmp keepalive threshold 10 retry 2
!
crypto ipsec ikev2 ipsec-proposal VPN-TRANSFORM
 protocol esp encryption aes-256
 protocol esp integrity sha-1
!
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC
crypto map CRYPTO-MAP 1 set peer 2.2.2.2
crypto map CRYPTO-MAP 1 set ikev2 ipsec-proposal VPN-TRANSFORM
crypto map CRYPTO-MAP interface outside
!
 
[/box]

Simply change the values in red where;

  • 10.0.0.0 255.255.255.0 is the network behind the ASA you are working on.
  • 10.0.3.0 255.255.255.0 is the destination network behind the device you are connecting to.
  • 2.2.2.2 is the peer IP address of the device you are attempting to connect to.
  • 1234567 Is the shared secret you will use at both ends.

Related Articles, References, Credits, or External Links

NA