Azure Virtual WAN
An Azure virtual networking service that provides optimized and automated branch-to-branch connectivity.
197 questions
BGP sessions over dual VPN Ipsec tunnels only work on Instance 0, Instance1 stays in connecting status, resulting in lost packets
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(160, 49%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMP%3C/text%3E%3C/svg%3E)
Martin Petder
0
Reputation points
Standard dual-path VPN from Virtual WAN hub to single virtual FortiGate with two public IPs in AWS, using BGP routing.
Azure side shows only half of the BGP paths connected (ones related to Instance0 via both VPN tunnels) while virtual FortiGate in AWS shows all paths connected, but only half of them receiving routing adverts.
As a result, connections utilizing Instance1 paths are losing packets. Instance0 connections seem to flap often as well.
On working paths routes are propagated correctly both ways. Seems like we're missing something obvious either on Azure or FortiGate side. Has anyone observed something similar?
{count} votes
-
KapilAnanth-MSFT 39,366 Reputation points Microsoft Employee2023-06-05T05:15:49.77+00:00 Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.
I understand that you are facing issues with your BGP session between Azure vWAN VPN Gateway and a Fortigate instance in AWS.
Can you please elaborate on what do you mean by "Azure side shows only half of the BGP paths connected (ones related to Instance0 via both VPN tunnels)"
- Are you talking about the BGP routes advertised and/or learned?
- AFAIK, BGP routes learned will be same in both the instances.
- Instance0 will establish two connections, with both the Public IPs from AWS and so does Instance1.
- So, the same BGP routes will be learned by both the tunnels.
- Is it not the case?
- Are you facing issues with routes learned/advertised wrt Azure end?
Cheers,
Kapil
-
KapilAnanth-MSFT 39,366 Reputation points Microsoft Employee
2023-06-06T04:00:13.5533333+00:00 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
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 69%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMP%3C/text%3E%3C/svg%3E)
Martin Petder 0 Reputation points2023-06-06T05:31:29.4666667+00:00 Hithe issue is not with route propagation, the issue is with established bgp connections. We have two instances (0 and 1) over two vpn connections, both instances are using both connections, so total of 4 routing paths. However only instance0 is show as connected (over both vpn's) while instance1 remains in connecting status from the viewpoint of Azure. At the same time underlying ipsec connections (2 of them between separate public interfaces in Azure and in aws) both show up as connected in Azure and in virtual fortigate in aws. However as the virtual fortigate tries to communicate with both instance0 and instance1, but all packets Sent to instance1 are lost.
-
KapilAnanth-MSFT 39,366 Reputation points Microsoft Employee
2023-06-06T06:04:31.65+00:00 When you mean Instance0 and Instance1, are you referring to the VPN Gateway instances or Fortigate Instances from AWS side?
Can you share the screeshot of Azure showing the status as "Connecting" ?
Thanks,
Kapil
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(188.79999999999998, 49%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMP%3C/text%3E%3C/svg%3E)
Martin Petder 0 Reputation points2023-06-06T12:57:25.7833333+00:00 Unfortunately I can only switch the other VPN connection live tomorrow, then I can send the correct screenshot as well. Currently the screenshot as it is at the moment - with full screenshot the second "instance0" row would also show status "Connected" with duration, messages sent and messages received with values and routes received 2. Both lines with "Instance1" remain in "Connecting" status.
-
KapilAnanth-MSFT 39,366 Reputation points Microsoft Employee
2023-06-07T04:48:18.7466667+00:00 Thanks for the screenshot.
If Instance0 is showing connected (two out of 4 Tunnels), and Instance1 is still connecting, the same should be reflected in the Fortigate side as well.
- It is strange as to why Fortigate would consider the connection to be connected and direct traffic towards these 2 Tunnels (of Instance1).
- Also, it is not an expected behavior/design consideration to have the Tunnels in a "Connecting" state.
- I would suggest you to enable Diagnostics for the VPN tunnel and check the IKEDiagnostic and TunnelDiagnostic
- Also, please check the Fortigate logs as to why connection is not establishing with Interface1.
Thanks,
Kapil
-
KapilAnanth-MSFT 39,366 Reputation points Microsoft Employee
2023-06-09T06:31:30.1733333+00:00 Can you please update us if the action plan provided was helpful?
Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
Thanks,
Kapil
Sign in to comment