Windguard Tunnel Issue

CntrlAltDel

CntrlAltDel

Well-Known Member
Joined
Jul 21, 2010
Messages
397
Reaction score
37
Hi Peeps,

Posting on behalf of a friend who is a CISP+Openserve fibre client (migrated from MTS).

They use a WireGuard VPN (UDP). For the last 3 days, the tunnel still connects, but any traffic routed via the tunnel outbound drops and services behind the VPN become unreachable (even simple pages). Normal internet access (not via VPN) works.

We ruled out the VPN/server side because:
  • The same VPN works immediately when the user switches to an LTE hotspot.
  • The issue happens on multiple devices on the home network.
Troubleshooting done:
  • Tested various MTU values on the router PPPoE interface and on client NICs, no change.
  • Attempted PPPoE direct from a Mac connected to the ONT (ONT is bridged so no DHCP, macOS shows self-assigned 169.254.x.x which is expected).
I'm thinking there might be a AWS peering issue downstream. There was a Openserve fibre outage in the same area which lines up with when the user started experiencing this issue.

The ticket that was logged contains a lot more detailed information about the test scenarios and outputs thereof that were done:
COOL-20260203-2590359
 
Hi, this does sound more MTU or potentially CGNAT related. Will have the team have a look.
 
PBCool said:
Hi, this does sound more MTU or potentially CGNAT related. Will have the team have a look.
Click to expand...

The Wireguard tunnel is MTU 1380 so I don't think fragmentation is the issue.
The user also incrementally tested different MTU sizes client side and the router side is set to 1450 which we stepped back to 1420 also based on instructions from the support agent.

Thanks for looking into it.
 
CntrlAltDel said:
The Wireguard tunnel is MTU 1380 so I don't think fragmentation is the issue.
The user also incrementally tested different MTU sizes client side and the router side is set to 1450 which we stepped back to 1420 also based on instructions from the support agent.

Thanks for looking into it.
Click to expand...
Yeah it shouldn't be an issue but it is definitely behaving like it is. Can you see what public IP they are being issued?
 
CntrlAltDel said:
The Wireguard tunnel is MTU 1380 so I don't think fragmentation is the issue.
The user also incrementally tested different MTU sizes client side and the router side is set to 1450 which we stepped back to 1420 also based on instructions from the support agent.

Thanks for looking into it.
Click to expand...
Hi there, we have noticed that the customers MTU is set to 1450, which likely is the reason for the fault.

You should be able to adjust this to 1492.
We see the issue started at the same time when there was an issue on Openserve, (which caused the MTU to be clamped at 1450), however this was soon resolved.

Unless you have already tried this approach?
 
CoolEscalator said:
Hi there, we have noticed that the customers MTU is set to 1450, which likely is the reason for the fault.

You should be able to adjust this to 1492.
We see the issue started at the same time when there was an issue on Openserve, (which caused the MTU to be clamped at 1450), however this was soon resolved.

Unless you have already tried this approach?
Click to expand...

I’ve not tried WAN MTU 1492 yet but will do so and get back to you.

The router’s PPPoE WAN MTU has always been 1450 by default.

TR-069 is not configured on the router, so I don’t think any remote config could have changed the router MTU setting (I'm sure this is not what you mean but just in case it is). I’m assuming you mean the MTU was being clamped from upstream on the FNO side during the Openserve incident.

If that upstream clamp was lifted when the Openserve issue was resolved, I would expect the MTU behaviour to return to normal considering the MTU size was still 1450 as it was before.

I do agree the symptoms strongly suggests MTU related issues, but we’re mostly flying blind on our side without visibility to confirm if a misalignment of configurations is the cause or faulty equipment that requires onsite input from CISP.
 
CntrlAltDel said:
I’ve not tried WAN MTU 1492 yet but will do so and get back to you.

The router’s PPPoE WAN MTU has always been 1450 by default.

TR-069 is not configured on the router, so I don’t think any remote config could have changed the router MTU setting (I'm sure this is not what you mean but just in case it is). I’m assuming you mean the MTU was being clamped from upstream on the FNO side during the Openserve incident.

If that upstream clamp was lifted when the Openserve issue was resolved, I would expect the MTU behaviour to return to normal considering the MTU size was still 1450 as it was before.

I do agree the symptoms strongly suggests MTU related issues, but we’re mostly flying blind on our side without visibility to confirm if a misalignment of configurations is the cause or faulty equipment that requires onsite input from CISP.
Click to expand...
Any sort of decent router should negotiate the respective MTU automatically, have we tried testing what the max MTU you can pass is?

You could try ping specifying frame size over the VPN as well.
 
PBCool said:
Any sort of decent router should negotiate the respective MTU automatically, have we tried testing what the max MTU you can pass is?

You could try ping specifying frame size over the VPN as well.
Click to expand...
Yes, I've done incremental step tests between 1380 - 1450, I didn't think to go over because this was the default (working before) values.

I will run the test again between 1450 - 1500.
 
CntrlAltDel said:
Yes, I've done incremental step tests between 1380 - 1450, I didn't think to go over because this was the default (working before) values.

I will run the test again between 1450 - 1500.
Click to expand...
Yeah so tweak MTU, then try ping across the VPN to a host and define the frame size. Should tell you whats going on.

We can also get you an afrihost test account to play with to help narrow down the issue.
 
CoolEscalator said:
Hi there, we have noticed that the customers MTU is set to 1450, which likely is the reason for the fault.

You should be able to adjust this to 1492.
We see the issue started at the same time when there was an issue on Openserve, (which caused the MTU to be clamped at 1450), however this was soon resolved.

Unless you have already tried this approach?
Click to expand...
I can confirm setting PPPoE MTU to 1492 as per your suggestion resolved the issue.

Thanks guys!
 
Isn't MTU auto sets by FNO but what if router goes through power circle?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X