Azure to FortiGate VPN Phase 2 Traffic Selector Mismatch Problem

Question

Azure to FortiGate VPN Phase 2 Traffic Selector Mismatch Problem

Ty 25

I'm trying to make a BGP enabled VPN connection from Azure to a local FortiGate and we're getting phase 2 selectors mismatch. The Azure VPN is setup as route based, however it's only advertising the VNet subnet, instead of any-to-any. We originally had the Fortigate setup with 0.0.0.0/0 traffic selectors, but when Azure wasn't matching we tried to match Azure. Here's the log from the FortiGate:

ike 6:Azure_VPN:12436319:25869722: peer proposal is: peer:0:10.10.0.0-10.10.255.255:0, me:0:169.254.21.2-169.254.21.2:0
ike 6:Azure_VPN:12436319:Azure_VPN:25869722: trying
ike 6:Azure_VPN:12436319:25869722: specified selectors mismatch
ike 6:Azure_VPN:12436319:25869722: peer: type=7/7, local=0:169.254.21.2-169.254.21.2:0, remote=0:10.10.0.0-10.10.255.255:0
ike 6:Azure_VPN:12436319:25869722: mine: type=7/7, local=0:10.1.0.0-10.1.255.255:0, remote=0:10.10.0.0-10.10.255.255:0
ike 6:Azure_VPN:12436319:Azure_VPN_2:25869722: trying
ike 6:Azure_VPN:12436319:25869722: specified selectors mismatch
ike 6:Azure_VPN:12436319:25869722: peer: type=7/7, local=0:169.254.21.2-169.254.21.2:0, remote=0:10.10.0.0-10.10.255.255:0
ike 6:Azure_VPN:12436319:25869722: mine: type=7/7, local=0:10.1.0.0-10.1.255.255:0, remote=0:172.17.32.0-172.17.39.255:0
ike 6:Azure_VPN:12436319:25869722: no matching phase2 found
ike 6:Azure_VPN:12436319:25869722: failed to get responder proposal

Any thoughts on how to get this connection made?

Boris Von Dahle 3,221 Reputation points

2023-05-22T20:35:22.9433333+00:00
Hello,

The error message shows that Azure is using 10.10.0.0/16 as the local network and 169.254.21.2 as the remote network, but FortiGate is expecting 10.1.0.0/16 as the local network.

Azure should have the FortiGate local network in its Local Network Gateway, and FortiGate should have the Azure subnet range in its configuration.

There is a few steps to further investigate :

Make sure the FortiGate is also configured to use a route-based VPN.

The traffic selectors should include all the IP addresses that could traverse the VPN from both sides.

Make sure that the BGP community values are set correctly and that you're advertising the correct routes to Azure

Ensure that the IP address spaces for the Azure VNet and your on-premises network do not overlap

If you found this answer helpful, please mark it as accepted so others can find this topic.
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-23T04:21:27.5233333+00:00
@Ty

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you would like to setup Any-to-Any traffic selectors in your Azure S2S VPN Connection.

Please note that community members in Microsoft Q&A Community have expertise over Azure products and may not be well-versed with logs from 3rd party sites.

I would strongly recommend you to check Gateway using diagnostic logs

Especially,

TunnelDiagnosticLog

IKEDiagnosticLog

And share them for troubleshooting.

To enable Diagnostic logs

In your Azure portal, search for Monitor.

Go to Diagnostics settings blade within Monitor and search for your VPN gateway in which you would like to enable diagnostics.

To turn on diagnostics, double-click the gateway and then select Turn on diagnostics.

Fill in the details, and ensure that Send to Log Analytics and TunnelDiagnosticLog are selected.

Choose the Log Analytics Workspace where you want to send the logs to. It may take a few hours for the data to show up initially.

With that said,

Looking at your logs, it looks like a TrafficSelectorMismatch issue.

Now, your OnPrem address range advertised according to your logs is alternating between "172.17.32.0-172.17.39.255", "169.254.21.2-169.254.21.2" (if I am reading the logs correctly)

What is the address range in Azure?

What is the address range(s) in Local?

Are you using BGP? If so, please leave the address range in LNG empty

If not, make sure the address space in the LNG is properly configured to reflect local address space.

Are you using any custom configuration in Azure or just default?

https://learn.microsoft.com/en-us/azure/vpn-gateway/ipsec-ike-policy-howto#step-3---configure-a-custom-ipsecike-policy-on-the-s2s-vpn-connection

Additionally, you can also set the VPN Connection to "Responder-Only" mode.

If the above doesn't help, please enable Gateway using diagnostic logs and check the logs from Azure end

Cheers,

Kapil
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-24T05:27:35.2366667+00:00

@Ty

May I know if you got a chance to review my previous comment?

Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them.

Thanks,

Kapil
Ty 25 Reputation points

2023-05-24T16:31:23.3266667+00:00

Edit: Looks like I accidentally double posted. See below.
Ty 25 Reputation points

2023-05-24T16:52:29.85+00:00
@KapilAnanth-MSFT and @Boris Von Dahle

Thank you so much for the responses! I'm sorry that I missed them until this morning. I have enabled logging as you suggested, thank you. My logs are indicating that Azure is offering the same traffic selectors as what the FortiGate log is seeing. Here's a line from the Azure IKE Diagnostic log:

As for configuration, here's what I've got on my side:

Virtual Network Gateway:

Generation 2

SKU: VpnGw2AZ

Active-Active: Disabled

Gateway Private IPs: Disabled

Configure BGP: yes

ASN: 64545

BGP peer IP Address: 10.10.2.254

Custom Azure APIPA BGP IP address: 169.254.21.3

Route-Based

VNet: 10.10.0.0/24

Local Network Gateway:

Address Space: blank because of BGP

Configure BGP settings: Yes

ASN: xxxxxx

BGP peer IP address: 169.254.21.2

Connection:

Use Azure Private IP Address: Disabled

BGP: Enabled

Enable Custom BGP Address: Enabled

Primary Custom BGP Address: 169.254.21.3

IPSec/IKE Policy: Custom

Phase 1: AES256, SHA256, DH2

Phase 2: AES256, SHA256, PFS None

IPSec SA lifetime: 102400000 KB

IPSec SA lifetime: 3600 sec

Use policy based traffic selector: Disable

DPD Timeout: 45 sec

Connection Mode: Default

Use custom traffic selectors:

local: 0.0.0.0/1 remote:0.0.0.0/1; local: 128.0.0.0/1 remote:128.0.0.0/1

IKE Protocol: IKEv2

After my first post we set the traffic selectors on the FortiGate and Azure to those listed above to attempt any-to-any, however Azure still seems to be only proposing it's local VNet 10.10.0.0/16, and remote ip of the BGP peer 169.254.21.2. Here's an entry from the IKE Diagnostic log from the Azure side:

[SEND] Proposed (Data Triggered) Traffic Selector payload will be- Number of TSIs 1: StartAddress 10.10.0.0 EndAddress 10.10.255.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 169.254.21.2 EndAddress 169.254.21.2 PortStart 0 PortEnd 65535 Protocol 0","instance":"GatewayTenantWorker_IN_1"}

This probably goes without mentioning, but the IPSec tunnel seems to be coming up fine and the connection shows as made. It's only when I look at BGP Peers in the portal that I perpetually see "Connecting".

If anyone has thoughts on why Azure is not offering the specified selectors, I'm all ears.
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-24T17:22:06.0233333+00:00
@Ty

Please disable Use custom traffic selectors and let the BGP update the routes

I would say Azure will accept the TrafficSelectors from OnPrem VPN Device

I don't think so Azure will go ahead and specify the traffic selector as 0.0.0.0/0.

It will simply accept this traffic selector if proposed.

So, what is the response from your VPN device when Azure Proposes the Traffic Selector?

Also, you can let the OnPrem device dictate your TrafficSelectors by setting the VPN Connection to "Responder-Only" mode

Cheers,

Kapil
Ty 25 Reputation points

2023-05-24T20:43:07.17+00:00

@KapilAnanth-MSFT I have done as you requested and made our side Responder-Only with disabled traffi selectors. Here's an excerpt from the IKE Diagnostic Log:

1- Process Payload Notify - NotifyType = 16393","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

2- [Received] [CHILD_SA QM_REKEY] Ipsec rekey request with iCookie 0x2F68449C28660B60 and rCookie 0xFB25C3C86399DF9B For Old IPSECSA spi 0xDF33E667","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

3- Received Traffic Selector payload request- [Tsid 0x71c1 ]Number of TSIs 1: StartAddress 10.1.0.0 EndAddress 10.1.255.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 10.10.0.0 EndAddress 10.10.255.255 PortStart 0 PortEnd 65535 Protocol 0","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

4- [SEND] Proposed Traffic Selector payload will be (Final Negotiated) - [Tsid 0x71c1 ]Number of TSIs 1: StartAddress 10.1.0.0 EndAddress 10.1.255.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 10.10.0.0 EndAddress 10.10.255.255 PortStart 0 PortEnd 65535 Protocol 0","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

5- [RECEIVED]Received IPSec payload: Policy1:Cipher=AES-CBC-256 Integrity=SHA256 PfsGroup=PfsNone ","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

6- [SEND][CHILD_QM_SA] Sending CREATE_CHILD QM_SA response message for tunnelId 0x36 and tsId 0x71C1","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

7- [SEND]Sending IPSec policy Payload for tunnel Id 0x36, tsId 0x71C1: Policy1:Integrity=SHA256 Cipher=AES-CBC-256 ","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

8- [SEND][CHILD_QM_SA] Sending CREATE_CHILD QM_SA request message for tunnelId 0x36 and tsId 0x71C2","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

9- [SEND]Sending IPSec policy Payload for tunnel Id 0x36, tsId 0x71C2: Policy1:Integrity=SHA256 Cipher=AES-CBC-256 ","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

10- [SEND] Proposed (Data Triggered) Traffic Selector payload will be- Number of TSIs 1: StartAddress 10.10.0.0 EndAddress 10.10.255.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 169.254.21.2 EndAddress 169.254.21.2 PortStart 0 PortEnd 65535 Protocol 0","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

11- Process Payload Notify - NotifyType = 38","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

12- [RECEIVED][NOTIFY] Received Notify Message - Traffic Selectors Unacceptable [IKEV2_TS_UNACCEPTABLE]","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

What I think I'm seeing here is in line 3 they are sending a TS proposal, and in line 4 we are agreeing to it. However, in line 10 we are sending another TS proposal and they are rejecting it in line 12. Does that seem accurate? Why would Azure be requesting the TS for their BGP peer alone?

Also, the above interaction between our gateways only happens once or twice an hour. But, every 5 seconds or so I get the following:

[SEND][CHILD_QM_SA] Sending CREATE_CHILD QM_SA request message for tunnelId 0x36 and tsId 0x755E","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

[SEND]Sending IPSec policy Payload for tunnel Id 0x36, tsId 0x755E: Policy1:Integrity=SHA256 Cipher=AES-CBC-256 ","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

[SEND] Proposed (Data Triggered) Traffic Selector payload will be- Number of TSIs 1: StartAddress 10.10.0.0 EndAddress 10.10.255.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 169.254.21.2 EndAddress 169.254.21.2 PortStart 0 PortEnd 65535 Protocol 0","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

Process Payload Notify - NotifyType = 38","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

[RECEIVED][NOTIFY] Received Notify Message - Traffic Selectors Unacceptable [IKEV2_TS_UNACCEPTABLE]","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

IkeCleanupQMNegotiation called with error 13999 and flags 1","instance":"GatewayTenantWorker_IN_1"}, "ClientOperationId": "00000000-0000-0000-0000-000000000000", "CorrelationRequestId": "00000000-0000-0000-0000-000000000000", "GatewayManagerVersion": "23.2.100.14"}

Which is the same thing that seems to kill the process in the first interaction. IDK, maybe those are unrelated, but it's filling the log. And again, I'm configured as ResponderOnly.

Another thing I'm curious about is our custom APIPA address and whether it's actually getting applied. As I showed in our VNG config above, the VNG says it has a BGP peer IP Address of 10.10.2.254, but also a Custom Azure APIPA BGP IP address of 169.254.21.3. How do I know if the custom IP is actually being applied? I can't find either of those IP addresses in any of the logs.
Ty 25 Reputation points

2023-05-24T20:54:12.3466667+00:00

Also, I have a live troubleshooting call tomorrow at 14:00 UTC with the other end of the connection. Do you have any suggestions for me as we try to figure this out?
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-25T08:58:28.04+00:00
@Ty

Thanks for such a detailed log and sharing your analysis.

Looking at your logs, Lines(3,4) and Lines(10) are not related.

You should filter using "Tsid" and Lines(3,4) are "0x71c1" while Lines(10) are "0x71C2".

Nevertheless, I believe the tunnel should get connected when the TrafficSelectors are accepted for 0x71c1.

Is it not the case?

If not, I would suggest we need a specialized 1:1 session, where a support engineer can have a screen share session to pinpoint the issue. If you have a support plan you may file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.

Let me know how the troubleshooting session goes.

Cheers,

Kapi
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-26T06:11:46.3866667+00:00

@Ty

Reaching out to check if there are any updates on the Troubleshooting call.

Please let us know if we can be of further assistance

Thanks,

Kapil
Ty 25 Reputation points

2023-05-26T17:41:41.3233333+00:00

@KapilAnanth-MSFT I have good news to report. After deleting and recreating our connection and some steps taken on the other end (which I'm not fully aware of the details), we have stable connections with active BGP peering. We left the connections in default mode and are not using custom traffic selectors.

At this point it seems that we're good to go and I'm thinking the issue seems to have been an issue on the FortiGate end of the connection.

I appreciate the time you've put into this. The logging that you helped me set up has been invaluable!
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-29T05:07:22.7833333+00:00

@Ty

I am glad the issue no longer persists.

I shall summarize our discussion and post it as an answer.

I woul greatly appreciate if you could "Accept the answer" and close this thread

Cheers,

Kapil :)

Accepted answer

0 additional answers

Your answer

Boris Von Dahle 3,221 Reputation points

2023-05-22T20:35:22.9433333+00:00

Hello,

The error message shows that Azure is using 10.10.0.0/16 as the local network and 169.254.21.2 as the remote network, but FortiGate is expecting 10.1.0.0/16 as the local network.

Azure should have the FortiGate local network in its Local Network Gateway, and FortiGate should have the Azure subnet range in its configuration.

There is a few steps to further investigate :

Make sure the FortiGate is also configured to use a route-based VPN.

The traffic selectors should include all the IP addresses that could traverse the VPN from both sides.

Make sure that the BGP community values are set correctly and that you're advertising the correct routes to Azure

Ensure that the IP address spaces for the Azure VNet and your on-premises network do not overlap

If you found this answer helpful, please mark it as accepted so others can find this topic.
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-24T05:27:35.2366667+00:00

@Ty

May I know if you got a chance to review my previous comment?

Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them.

Thanks,

Kapil
Ty 25 Reputation points

2023-05-24T16:31:23.3266667+00:00

Edit: Looks like I accidentally double posted. See below.
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-24T17:22:06.0233333+00:00

@Ty

Please disable Use custom traffic selectors and let the BGP update the routes

I would say Azure will accept the TrafficSelectors from OnPrem VPN Device

I don't think so Azure will go ahead and specify the traffic selector as 0.0.0.0/0.

It will simply accept this traffic selector if proposed.

So, what is the response from your VPN device when Azure Proposes the Traffic Selector?

Also, you can let the OnPrem device dictate your TrafficSelectors by setting the VPN Connection to "Responder-Only" mode

Cheers,

Kapil
Ty 25 Reputation points

2023-05-24T20:54:12.3466667+00:00

Also, I have a live troubleshooting call tomorrow at 14:00 UTC with the other end of the connection. Do you have any suggestions for me as we try to figure this out?
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-25T08:58:28.04+00:00

@Ty

Thanks for such a detailed log and sharing your analysis.

Looking at your logs, Lines(3,4) and Lines(10) are not related.

You should filter using "Tsid" and Lines(3,4) are "0x71c1" while Lines(10) are "0x71C2".

Nevertheless, I believe the tunnel should get connected when the TrafficSelectors are accepted for 0x71c1.

Is it not the case?

If not, I would suggest we need a specialized 1:1 session, where a support engineer can have a screen share session to pinpoint the issue. If you have a support plan you may file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.

Let me know how the troubleshooting session goes.

Cheers,

Kapi
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-26T06:11:46.3866667+00:00

@Ty

Reaching out to check if there are any updates on the Troubleshooting call.

Please let us know if we can be of further assistance

Thanks,

Kapil
Ty 25 Reputation points

2023-05-26T17:41:41.3233333+00:00

@KapilAnanth-MSFT I have good news to report. After deleting and recreating our connection and some steps taken on the other end (which I'm not fully aware of the details), we have stable connections with active BGP peering. We left the connections in default mode and are not using custom traffic selectors.

At this point it seems that we're good to go and I'm thinking the issue seems to have been an issue on the FortiGate end of the connection.

I appreciate the time you've put into this. The logging that you helped me set up has been invaluable!
KapilAnanth-MSFT 49,616 Reputation points Microsoft Employee Moderator

2023-05-29T05:07:22.7833333+00:00

@Ty

I am glad the issue no longer persists.

I shall summarize our discussion and post it as an answer.

I woul greatly appreciate if you could "Accept the answer" and close this thread

Cheers,

Kapil :)

Answer 1

@Ty

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you are in the middle of setting up Any-to-Any traffic selectors in your Azure S2S VPN Connection.

I suggested we enable Gateway using diagnostic logs for VPN Gateway

Especially,

TunnelDiagnosticLog
IKEDiagnosticLog

Looking at your logs, it looked like a TrafficSelectorMismatch issue.

I recommended that the below steps could help to mitigate the issue

Are you using any custom configuration in Azure or just default?
https://learn.microsoft.com/en-us/azure/vpn-gateway/ipsec-ike-policy-howto#step-3---configure-a-custom-ipsecike-policy-on-the-s2s-vpn-connection
- If so, you can go for default and give it a try
Since you are using BGP, please leave the address range in LNG empty
Or, you can also set the VPN Connection to "Responder-Only" mode.

Later, you had a troubleshooting session with VPN Device vendor and they were able to resolve this issue

Please let us know if we can be of any further assistance here, and I shall be glad to assist as always :)

Thanks,

Kapil

Kindly Accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer.

Share via

Azure to FortiGate VPN Phase 2 Traffic Selector Mismatch Problem

0 additional answers

Your answer