Site-to-Site VPN - FTD (6.2) x Azure

[caiobomani]

Has anyone successfully created a VPN with Azure from within FTD devices?

I'm attempting to establish the tunnel (which can only be IKEv2) and the Phase 2 flow is not establishing.

Attaching the debug logs from the connection.

Any suggestions?

Obs.: I've masked my end of the tunnel IP with an *.*.*.*

[Rob Ingram]

Hi, you don't appeared to have uploaded the debug logs.

[caiobomani]

My apologies.

Here you go.

[Rob Ingram]

Hi,

The following errors are repeated a few times:-

IKEv2-PLAT-2: (582): Crypto map CSM_inet_map seq 1 is incomplete
IKEv2-PLAT-2: (582): Crypto map CSM_inet_map seq 2 is incomplete
IKEv2-PLAT-2: (582): Crypto map CSM_inet_map seq 3 is incomplete
IKEv2-PLAT-2: (582): Crypto map CSM_inet_map seq 5 is incomplete
IKEv2-PLAT-2: (582): Crypto Map: No proxy match on map CSM_inet_map seq 6
IKEv2-PROTO-1: (582): Failed to find a matching policy
IKEv2-PROTO-1: (582): Received Policies:
IKEv2-PROTO-1: (582): Failed to find a matching policy
IKEv2-PROTO-1: (582): Expected Policies:
IKEv2-PROTO-5: (582): Failed to verify the proposed policies
IKEv2-PROTO-1: (582): Failed to find a matching policy

---

I'd check your protected networks on both ends and make sure you've defined exactly the same networks/subnet mask etc. Also I'd check the IKEv2 Policy on both ends to ensure the same algorithms are defined.

HTH

[caiobomani]

Indeed with a more detailed capture (attached) it confirmed that Azure side is attempting to send all networks.

Payload IKEV2 TSi PAYLOAD
Next Payload: IKEV2 TSr PAYLOAD
Critical Bit: OFF
Reserved: 00
Payload Length: 24
Num TSs: 1
Reserved: 000000
Protocol ID: 0
Selector Length: 16
Port Range: 0 - 65535
Type: TS_IPV4_ADDR_RANGE
0.0.0.0 -> 255.255.255.255
Payload IKEV2 TSr PAYLOAD
Next Payload: None
Critical Bit: OFF
Reserved: 00
Payload Length: 24
Num TSs: 1
Reserved: 000000
Protocol ID: 0
Selector Length: 16
Port Range: 0 - 65535
Type: TS_IPV4_ADDR_RANGE
0.0.0.0 -> 255.255.255.255

As soon as I get it fixed in the partner side, I'll let you guys know how it goes.

[caiobomani · Accepted solution]

Azure side was indeed not specifying the encryption domain on both ends. That needed to be done via shellscript.

After that got fixed, the tunnel came up and the communication started to flow.

Thanks everyone for the assistance.

[sanmi]

Any chance that you explain here how to specify the encryption domain on the Azure endpoint (shellscript)?

Best,

[caiobomani]

I've requested that script from my partner and he gave me this:

1) Create (via web interface) the ResourceGroup, Virtual Network and VPN Gateway.

2) Script

Login-AzureRmAccount

Select-AzureRmSubscription -SubscriptionID *ID*

$vnet1gw = Get-AzureRmVirtualNetworkGateway -Name *Virtual Network Azure* -ResourceGroupName *Resource Group Name*

$lng6 = Get-AzureRmLocalNetworkGateway -Name *NAME* -ResourceGroupName *Resource Group Name*

$ipsecpolicy6 = New-AzureRmIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA1 -DhGroup DHGroup2 -IpsecEncryption AES256 -IpsecIntegrity SHA1 -PfsGroup None -SALifeTimeSeconds 3600 -SADataSizeKilobytes 102400000

New-AzureRmVirtualNetworkGatewayConnection -Name *NAME* -ResourceGroupName *Resource Group Name* -VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng6 -Location *where the resource will be hosted* -ConnectionType IPsec -UsePolicyBasedTrafficSelectors $True -IpsecPolicies $ipsecpolicy6 -SharedKey ‘*PSK*’

[sanmi]

Hi caiobomani

Please check that what the script is doing is create a policy based traffic Gateway, thus parting ways with route based configuration. This way you won't be able to use the Azure Basic Gateway SKU, instead you will be forced to use a more expensive SKU.

-UsePolicyBasedTrafficSelectors $True 

I just opened a case with Azure support. I will let you know if they can fix the offered acl.

Best,

sanmi