Azure VPN latency every 8-12 seconds

Kevin Launey 20

Ping latency issue connecting across Azure VPN. This is a wired connection. We have verify ISP connection is solid when connecting to outside of the VPN.

Reply from 10.x.x.x: bytes=32 time=22ms TTL=128

Reply from 10.x.x.x: bytes=32 time=26ms TTL=128

Reply from 10.x,x,x: bytes=32 time=22ms TTL=128

Reply from 10.x.x.x: bytes=32 time=22ms TTL=128

Reply from 10.x.x.x: bytes=32 time=370ms TTL=128

Reply from 10.x.x.x: bytes=32 time=508ms TTL=128

Reply from 10.x,x,x: bytes=32 time=23ms TTL=128

Reply from 10.x.x.x: bytes=32 time=22ms TTL=128

Reply from 10.x.x.x.: bytes=32 time=23ms TTL=128

Reply from 10.x.x.x: bytes=32 time=22ms TTL=128

Reply from 10.x.x.x: bytes=32 time=37ms TTL=128

Reply from 10.x.x.x: bytes=32 time=22ms TTL=128

Reply from 10.x.x.x: bytes=32 time=246ms TTL=128

Reply from 10.x.x.x: bytes=32 time=394ms TTL=128

Reply from 10.x.x.x: bytes=32 time=22ms TTL=128

Reply from 10.x.x.x: bytes=32 time=302ms TTL=128

Reply from 10.x.x.x: bytes=32 time=35ms TTL=128

Reply from 10.x.x.x: bytes=32 time=22ms TTL=128

KapilAnanth-MSFT 48,261 Reputation points Microsoft Employee

2023-10-09T04:41:22.13+00:00
@Kevin Launey

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

I take it that you have a S2S Connection and not a P2S Connection

Please note that ICMP Ping is not a good indicator of latency with respect to Azure VPN Gateway Connections.

Are you facing any performance issue with RDP or Application?

Can you replicate this with using a TCP Ping tool?

You can use PsPing and please share the results.

You can also use Latte.exe tool to check the performance : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-validate-throughput-to-vnet#test-vms-running-windows

Make sure you allow it via Firewall and run the tests.

Cheers,

Kapil
Hunter London 0 Reputation points

2023-10-09T17:06:02.77+00:00

Reverting to an older version helped for a little while, but now I am also having this same exact issue.
KapilAnanth-MSFT 48,261 Reputation points Microsoft Employee

2023-10-10T05:07:01.58+00:00

@Kevin Launey

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.

Hunter London - did you get a chance to carry out the action plan suggested above?

Thanks,

Kapil
KapilAnanth-MSFT 48,261 Reputation points Microsoft Employee

2023-10-11T05:40:23.6266667+00:00

@Kevin Launey

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
KapilAnanth-MSFT 48,261 Reputation points Microsoft Employee

2023-10-12T03:54:53.4633333+00:00

@Kevin Launey

Reaching out to check if there are any questions on this.

Please let us know if we can be of any further assistance here.

Thanks,

Kapil
Marco G 80 Reputation points

2023-10-12T20:51:53.4+00:00

I got the same problem, even losses up to 3%.
4 different locations over IPSec IKEv2 (pfsense 2.5.2 - 2.7). The problems occur about 1-2 weeks ago.

@KapilAnanth-MSFT Its noticeable in RDP connection too.

Resettet VPN, reboot pfsense, nothing changed.

Any Ideas?

Ping:

Antwort von 10.10.0.10: Bytes=32 Zeit=16ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=372ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=298ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=30ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=15ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=16ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=15ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=17ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=56ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=15ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=17ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=346ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=308ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=15ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=15ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=15ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=394ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=296ms TTL=127
Antwort von 10.10.0.10: Bytes=32 Zeit=14ms TTL=127
KapilAnanth-MSFT 48,261 Reputation points Microsoft Employee

2023-10-13T06:49:53.6533333+00:00
Marco G ,

As stated earlier, ICMP Ping is not a good indicator of latency with respect to Azure VPN Gateway Connections.

Can you replicate this with using a TCP Ping tool?

You can use PsPing and please share the results.

Since you mentioned you can experience the issue with RDP Connections, you can use Port 3389 and test the above.

You can also use Latte.exe tool to check the performance : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-validate-throughput-to-vnet#test-vms-running-windows

Cheers,

Kapil

Marco G 80

@KapilAnanth-MSFT ,

thank you for your fast answer.

TLDR: Same results with all sorts of ping over the VPN (site to site). "normal" traffic to internet and azure local is OK

latte results:

c:\tools>latte.exe -c -a 10.10.0.21:5005 -i 65100
Protocol      TCP
SendMethod    Blocking
ReceiveMethod Blocking
SO_SNDBUF     Default
SO_RCVBUF     Default
MsgSize(byte) 4
Iterations    65100
Latency(usec) -7494.07
CPU(%)        4.4
CtxSwitch/sec -15457    (115.83/iteration)
SysCall/sec   -149964   (1123.84/iteration)
Interrupt/sec -27779    (208.18/iteration)

here are the PsPing results:

local client to azure server

TCP connect to 10.10.0.21:3389:
Infinite iterations (warmup 1) ping test:
Connecting to 10.10.0.21:3389 (warmup): from 192.168.0.142:52409: 612.27ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52434: 242.13ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52442: 14.53ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52455: 15.29ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52459: 16.00ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52465: 15.07ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52470: 15.61ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52471: 14.47ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52477: 15.63ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52482: 14.94ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52484: 15.26ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52488: 251.12ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52493: 241.95ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52495: 15.62ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52501: 15.65ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52508: 14.99ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52518: 53.97ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52524: 15.89ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52529: 15.96ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52532: 18.52ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52537: 16.82ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52538: 15.20ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52543: 461.49ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52563: 483.28ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52565: 14.44ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52571: 14.60ms
Connecting to 10.10.0.21:3389: from 192.168.0.142:52575: 22.09ms

  Sent = 26, Received = 26, Lost = 0 (0% loss),
  Minimum = 14.44ms, Maximum = 483.28ms, Average = 78.87ms

server to firewall:

TCP connect to 10.0.9.1:443:
Infinite iterations (warmup 1) ping test:
Connecting to 10.0.9.1:443 (warmup): from 10.10.26.10:55796: 20.44ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55797: 21.65ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55798: 20.28ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55799: 21.54ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55800: 44.68ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55807: 20.76ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55809: 21.10ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55811: 21.21ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55814: 271.39ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55815: 234.76ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55816: 21.79ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55817: 20.33ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55818: 20.50ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55819: 21.67ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55820: 26.18ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55822: 33.30ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55824: 21.15ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55827: 21.35ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55832: 21.70ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55833: 290.00ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55839: 494.04ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55840: 72.04ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55844: 20.89ms
Connecting to 10.0.9.1:443: from 10.10.26.10:55845: 20.41ms

  Sent = 23, Received = 23, Lost = 0 (0% loss),
  Minimum = 20.28ms, Maximum = 494.04ms, Average = 77.51ms

server to internet:

TCP connect to 142.250.184.206:443:
Infinite iterations (warmup 1) ping test:
Connecting to 142.250.184.206:443 (warmup): from 10.10.26.10:55575: 2.11ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55578: 2.30ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55580: 1.99ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55581: 1.72ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55582: 2.29ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55583: 1.60ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55584: 2.24ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55585: 2.10ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55591: 2.16ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55594: 1.86ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55595: 1.72ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55596: 1.65ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55597: 2.21ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55598: 1.90ms
Connecting to 142.250.184.206:443: from 10.10.26.10:55599: 2.27ms

  Sent = 14, Received = 14, Lost = 0 (0% loss),
  Minimum = 1.60ms, Maximum = 2.30ms, Average = 2.00ms

thanks in advance,

Marco

Maurizio Franzoni 5 Reputation points

2023-10-17T13:19:49.4666667+00:00

Hello, we have same problem both S2S tunnel and P2S tunnel, after 8-10 PSping with 25ms, the latency goes up to 500-700ms for 3 seconds. In Azure there are VMs where Microsoft BC ERP (front-end and back-end) runs; all VMs are affected by the problem. The Azure datacenter is located in west-europe.

I appreciate if someone that has fixed the problem can update.

Best regards,

Maurizio.
Marco G 80 Reputation points

2023-10-17T13:27:34.3333333+00:00

Additional Information: @KapilAnanth-MSFT and @Maurizio Franzoni

Virtual network gateway

Location: Germany West Central
SKU: Basic
Gateway type: VPN
VPN type: Route-based

Kevin Launey 20

Yes, we are seeing performance issues in both RDS and applications

Connecting to 10.x.x.x:xxxx from 192.168.0.142:52501: 15.65msConnecting to 10.x.x.x:xxxx from 192.168.0.142:52508: 14.99msConnecting to 10.x.x.x:xxxx from 192.168.0.142:52518: 53.97msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52524: 15.89msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52529: 15.96msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52532: 18.52msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52537: 16.82msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52538: 15.20msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52543: 371.42msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52563: 512.24msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52565: 14.44msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52571: 14.60msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52575: 22.09ms  Sent = 30, Received = 30, Lost = 0 (0% loss),  Minimum = 14.39ms, Maximum = 512.24.28ms, Average = 71.54ms

Kevin Launey 20

Yes, we are seeing performance issues in both RDS and direct through applications

Connecting to 10.x.x.x:xxxx from 192.168.0.142:52501: 15.65msConnecting to 10.x.x.x:xxxx from 192.168.0.142:52508: 14.99msConnecting to 10.x.x.x:xxxx from 192.168.0.142:52518: 53.97msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52524: 15.89msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52529: 15.96msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52532: 18.52msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52537: 16.82msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52538: 15.20msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52543: 371.42msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52563: 512.24msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52565: 14.44msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52571: 14.60msConnecting to 10.x.x.x:xxxx: from 192.168.0.142:52575: 22.09ms  Sent = 30, Received = 30, Lost = 0 (0% loss),  Minimum = 14.39ms, Maximum = 512.24.28ms, Average = 71.54ms

KapilAnanth-MSFT 48,261 Reputation points Microsoft Employee

2023-10-17T17:57:00.48+00:00

@Kevin Launey , @Maurizio Franzoni , Marco G

I shall check this behavior and get back to you.

I do not think this is a proper indicator of latency and there is a different reason for this spike in after a specific interval/frequency.

Anyways, I shall check this internally and update the thread soon.

Meanwhile, should there be a production issue, I would request you file a support ticket where a support engineer can have a screen share session to pinpoint the issue.

Thanks,

Kapil.

Tobias 0

Hi @KapilAnanth-MSFT ,

we are also having performance issues with our Azure environment:

Pinging x.x.x.x with 32 bytes of data:
200 iterations (warmup 1) ping test:
Reply from x.x.x.x: 22.42ms
Reply from x.x.x.x: 609.43ms
Reply from x.x.x.x: 636.41ms
Reply from x.x.x.x: 42.84ms
Reply from x.x.x.x: 22.49ms
Reply from x.x.x.x: 22.17ms
Reply from x.x.x.x: 21.73ms
Reply from x.x.x.x: 22.05ms
Reply from x.x.x.x: 22.68ms
Reply from x.x.x.x: 21.63ms
Reply from x.x.x.x: 22.14ms
Reply from x.x.x.x: 22.43ms
Reply from x.x.x.x: 857.29ms
Reply from x.x.x.x: 444.56ms
Reply from x.x.x.x: 137.90ms
Reply from x.x.x.x: 22.14ms
Reply from x.x.x.x: 22.61ms
Reply from x.x.x.x: 21.84ms
Reply from x.x.x.x: 22.01ms
Reply from x.x.x.x: 22.13ms
Reply from x.x.x.x: 22.64ms

  Sent = 20, Received = 20, Lost = 0 (0% loss),
  Minimum = 21.63ms, Maximum = 857.29ms, Average = 151.96ms

Any updates on your side?

Thank you!

TobiasF

Marco G 80 Reputation points

2023-10-19T12:45:16.2+00:00

Today the problem disappeared on our site. Previously I opened a ticket at microsoft, wrote back and forth with the technician, but get no positive/resolved notice. I asked and wait for an answer and will post it here.

@Tobias what SKU do you have the problems with?
Tobias 0 Reputation points

2023-10-19T13:13:21.0133333+00:00

Hi @Marco G,

we are using an application gateway SKU basic gen 1
Rickard Borgmäster 0 Reputation points

2023-10-20T10:09:32.12+00:00

Similar observations seen here, including the improvement during night between 18:th and 19:th October. Around 00:30 GMT on 19th the ping spikes seem to have disappeared. We will be opening an MS ticket today to investigate reason behind.
Kevin Launey 20 Reputation points

2023-10-20T18:32:33.69+00:00

UPDATE:

We resoled this issue by upgrading the Azure VPN from Basic to Standard and configuring Tunnel VPN instead of Site to Site.
KapilAnanth-MSFT 48,261 Reputation points Microsoft Employee

2023-11-10T12:56:28.9733333+00:00
@Kevin Launey , Marco G ,

Apologies for the delay, I was working with the Product Team internally to understand this behavior.

We have created a document item to call out the latency issue : https://github.com/MicrosoftDocs/azure-docs/issues/116873

The documents will be soon updated to reflect the same.

For improved latency, the recommendation is to move to higher SKUs such as VpnGw2 Generation1 and above.

Cheers,

Kapil

Siegfried Beitl 116

I have had this exact same problem (delay every 10 seconds) twice now. In each case, a reset of the Virtual Network Gateway fixed it.

Reply from 10.2.1.7: bytes=32 time=27ms TTL=127
Reply from 10.2.1.7: bytes=32 time=410ms TTL=127
Reply from 10.2.1.7: bytes=32 time=37ms TTL=127
Reply from 10.2.1.7: bytes=32 time=32ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=25ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=31ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=339ms TTL=127
Reply from 10.2.1.7: bytes=32 time=169ms TTL=127
Reply from 10.2.1.7: bytes=32 time=24ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=24ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=93ms TTL=127
Reply from 10.2.1.7: bytes=32 time=44ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=26ms TTL=127
Reply from 10.2.1.7: bytes=32 time=29ms TTL=127
Reply from 10.2.1.7: bytes=32 time=325ms TTL=127
Reply from 10.2.1.7: bytes=32 time=25ms TTL=127
Reply from 10.2.1.7: bytes=32 time=30ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=30ms TTL=127
Reply from 10.2.1.7: bytes=32 time=25ms TTL=127
Reply from 10.2.1.7: bytes=32 time=24ms TTL=127
Reply from 10.2.1.7: bytes=32 time=24ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=479ms TTL=127
Reply from 10.2.1.7: bytes=32 time=217ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=24ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=25ms TTL=127
Reply from 10.2.1.7: bytes=32 time=25ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=366ms TTL=127
Reply from 10.2.1.7: bytes=32 time=194ms TTL=127
Reply from 10.2.1.7: bytes=32 time=22ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=24ms TTL=127
Reply from 10.2.1.7: bytes=32 time=27ms TTL=127
Reply from 10.2.1.7: bytes=32 time=23ms TTL=127
Reply from 10.2.1.7: bytes=32 time=27ms TTL=127

Garrett Lynch 0 Reputation points

2023-12-13T04:13:54.92+00:00

Same identical issue for us, VpnGw1, route based, NCUS, and latency spikes from 300+ ms. Resetting the gateway did not resolve the issue.

For us, we moved to a Wireguard VM to broker traffic but ideally I would like to move back to IPSec for BGP.
Siegfried Beitl 116 Reputation points

2023-12-13T20:36:27.75+00:00

I have opened a support case.
*edit: SKU is VpnGw1

@Garrett Lynch have you tried resetting it twice in short succession? As per description of how their VPN gateways work, resetting it once, just switches over to another virtual machine, whereas resetting it twice, in short order, will restart both VMs. That is, if I read all that correctly.

Oddly enough, the first time it happened for me, two resets were needed but the second time, one reset fixed it.

Gateway reset A VPN gateway is composed of two VM instances running in an active-standby configuration. When you reset the gateway, it reboots the gateway, and then reapplies the cross-premises configurations to it. The gateway keeps the public IP address it already has. This means you won’t need to update the VPN router configuration with a new public IP address for Azure VPN gateway. When you issue the command to reset the gateway, the current active instance of the Azure VPN gateway is rebooted immediately. There will be a brief gap during the failover from the active instance (being rebooted), to the standby instance. The gap should be less than one minute. If the connection isn't restored after the first reboot, issue the same command again to reboot the second VM instance (the new active gateway). If the two reboots are requested back to back, there will be a slightly longer period where both VM instances (active and standby) are being rebooted. This will cause a longer gap on the VPN connectivity, up to 30 to 45 minutes for VMs to complete the reboots. After two reboots, if you're still experiencing cross-premises connectivity problems, please open a support request from the Azure portal.
Garrett Lynch 0 Reputation points

2023-12-13T20:41:06.2666667+00:00

@Siegfried Beitl I unfortunately did this once and should have tried it twice for testing sake. For us, we cannot afford the variability / risk of it happening again as the latency spikes caused a significant headache for a very sensitive cloud app.

Accepted answer

Marco G 80 Reputation points

2023-10-20T23:00:23.79+00:00

After the problem disappeared the technician responded, he had "tried to synchronize" the VPN. I dont know what this means, but it helps.

@Kevin Launey the technician also advised to change to a higher SKU, but we cant simple switch without creating it from scratch. He also mentioned that the basis SKU is EOL and will be retired in the future.
Please sign in to rate this answer.
Marco G 80 Reputation points

2023-12-14T01:49:20.3433333+00:00

About two weeks after the problem disappeared it came back and the technician submitted a request to fix it , this time with a positive answer, that they found an issue with the agent and fixed it. Since than (7th dec) the problem is gone again. hope forever ...

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Lars Sloots 0 Reputation points

2023-12-19T07:41:46.9+00:00

Still having the issue on my side with latest version of the azure vpn client.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure VPN latency every 8-12 seconds

0 additional answers

Your answer