VPN Issues on Static IP

[#1]

I have a static IP and have since I moved into my property in 2019 (Range 80.229.X.X)
I regularly use an L2TP / IPSec VPN to access my work's Office network.

Just before Christmas (22nd Dec) I found I was no longer able to connect to the office VPN via my home network.
I can connect to the VPN via mobile tethering.
I'm using a TP-Link Archer VR2800 v1 as the DSL Modem router and it has not been updated in the time frame in which the VPN stopped working.

Admins of the VPN have confirmed there is no IP block list in place and all other users can still connect.
As far as they can tell the connection is not reaching the VPN server.

At this point i'm going to have to think about moving away from Plusnet as I really need to be able to connect to the office VPN.
It only seems to be that specific type of VPN that is affected as other VPN solutions are working (Azure P2S IKEv2 SSL VPNs, Watchguard VPNs, etc..)

Any help appreciated as i really want to get this issue resolved without having to move ISP and static IP....

[#2]

Can you try a traceroute to the vpn endpoint/IP address ?

[#3]

Yep tracert is working fine, Its making the connection within 13 hops, traversing the plusnet and bt devices along the way.

Unsure if there is exact info you want out of tracert.

[#4]

No, thats fine. If tracert works then that eliminates any routing issues.

Are there any logs from your vpn client ?

The 80.229.x.x range is an established range and not one that is associated with any VPN issues.

Are you sure the VPN endpoint doesnt have any IP block ? There was an instance recently where the VPN admin swore blind there was no IP block, turns out there was ?

[#5]

@nashr

I've been a customer of Plusnet for years (both on FTTC and ADSL) and for work I have used various IPsec/DTLS/TLS VPNs over those years. I've never had a problem. However, I do know that some of our staff have had weird problems with VPNs occasionally, and we found changing the MTU on their laptops fixed it.

Open a CMD command prompt (I think you'll need admin privileges)
Then use the netsh show command to list the interfaces and their existing MTU like this:

C:\> netsh interface ipv4 show subinterface

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  1500                5          0          0  Wi-Fi
4294967295                1          0      15881  Loopback Pseudo-Interface 1
  1500                5          0          0  Local Area Connection* 1
  1500                2     253210     806804  Ethernet 2
  1500                5          0          0  Local Area Connection* 2
  1500                1  303591244  199259141  Ethernet 3
  1500                5          0          0  Ethernet 4

For example with my PC I know that "Ethernet 2" is the LAN connection physically on my laptop (that I was testing with for a moment earlier) but "Ethernet 3" is the LAN connection on my docking station that I actually use all the time (hence the biggest traffic). If I was using Wireless instead, it shows the Interface in my case would be called "Wi-Fi"

You might see the VPN adaptor itself listed, but you don't want to change that - make sure you are disconnected from the VPN first and then change the settings on only the main WiFi or Ethernet interface, that the VPN will be running inside of.

When you have identified the interface, eg say "Ethernet 3" in my case, write down the existing MTU in case you need to go back to it in future (it will proabably be 1500 anyway).

Change the MTU temporarily with

C:\> netsh interface ipv4 set subinterface "Ethernet 3" mtu=1350 store=active

Where "Ethernet 3" is my LAN connection, yours might be "WiFi" or "Wi-Fi" whatever was listed earlier.

Then see if that helps.
The "active" part of the command means the change will only last until the next reboot (ie for the login session that is active now). If you find it fixes the problem, you can change it to "store=persistent" so it survives a reboot.
You can experiment with different MTU values, like 1300 or 1400, whatever works for you. If it doesnt help, just reboot to put the setting back, or issue the same command but with mtu=1500 or whatever it was before.

[#6]

Moderators Note

Post release from automated spam filter.

[#7]

Changing the MTU does not seem to have any effect.

Error code coming from the RasClient in Event Viewer is 809 which again indicates a connectivity issue on ports 500 and 4500.

PortQuery shows the connections as Listening or Filtered.

UDP port 4500 (ipsec-msft service): LISTENING or FILTERED
UDP port 500 (isakmp service): LISTENING or FILTERED

[#8]

Have you checked that the Broadband firewall is OFF https://www.plus.net/member-centre/broadband/firewall ( need to login to the member centre )

I don't see why its status should have changed but its worth a look. Note, if you change the setting , you need to disconnect/reconnect the PPPoE session. Thinking about it, disconnecting/reconnecting may be a good idea anyway ( unless youve already tried it )

[#9]

The Broadband firewall is set to OFF. I will try rebooting the Router later when usage is reduced.

[#10]

Yep unsurprisingly Reboot has not fixed anything,
Broadband Firewall and Router Firewalls are off.
There should be nothing stopping the VPN connection, but its still failing to establish the connection

[#11]

and Router Firewalls are off

I would have thought you would need the router firewall on, so that any IPSEC Passthrough helper will correctly route the incoming UDP traffic on ports 500 and 4500

[#12]

It may well be a MTU size problem. MTU (maximum transmission unit) is the maximum size of a packet of data that can be sent in one piece - larger packets are split into multiple smaller packets.

The problem with VPNs is that they wrap each packet with extra routing data (like putting a letter in an envelope), which increases the overall packet size. If that exceeds the MTU the packet will be split - but lots of network software is not good at reassembling the original packet at the other end, and that's when problems occur.

Default MTU is 1500, but I've had to go as low as 1200 for some VPNs.

Setting the MTU varies with operating system - google may help, or post your OS and version here and someone may be able to help.

[#13]

Switched it back on - no difference.

[#14]

I've tried various settings on MTU this has also not made a difference.

[#15]

It might be worth trying Test_NetConnection from a Windows Powershell ( I'm assuming you're Windows as you mentioned RasClient ) to see if that can show any light on the problem

Try

Test-NetConnection -ComputerName "<vpn-url>" -Port 500 -InformationLevel "Detailed"

It would also be interesting to try a different port , say 80

Test-NetConnection -ComputerName "<vpn-url>" -Port 80 -InformationLevel "Detailed"

Although it wasnt a VPN problem there's a bit more details on the expected results from Test-Netconnection in ths thread https://community.plus.net/t5/Broadband/Azure-file-share-port-445-blocked/td-p/1874604