I've updated my computer to Windows 10 Build 1809:
After a successfull connection with Big-IP Edge Client VPN the internet connection is broken. Ping to Google DNS servers with connected VPN:
We have configured Network Access with "split tunneling". The very same VPN worked perfectly with the previous build of Windows 10 (1803).
Version of VPN client: 7160,2018,417,2013
Does anyone run into the same problem?
Thank you, John
I just tested with the latest version of the Big IP Edge client (7171.2018.808.2011). Same behavior, it doesn't work either.
Yes, SSL F5 VPN doesn't work on Window 10 1809 machine.Logged a call with F5 support and they advised below
'' At the moment the reported issue is escalated to our Product Development team. New software defect ID745498 with a title "[Windows RS5]OS doesn't using default route 0.0.0.0/0.0.0.0 if config with split tunnel" was created to track that issue. ''
Tested on one of window machine 1809 and it seems working.
Route print -p 0.0.0.0 netmask 126.96.36.199 default gateway
Route print -p 188.8.131.52 netmask 184.108.40.206 default gateway
But ,This is not the fix, but the workaround while the issue is being analyzed by F5 product developers.
Thank you for the useful information! I hope, we will get a fix soon..
NasimMalik, did you say you have found a workaround for this? Your comment suggests as much, but there is no info on what you did.
Looks like a known issue article has been published. Per the article, the workaround is to force all traffic through the tunnel (i.e. disable split tunnel).
Below are workaround instructions that worked for me as an end user. This is not intended as central workaround a for a multi-user deployment.
Start cmd as administrator. One way to do this is
Find the Gateway ip address for your Internet connection using the route print command in the administrator command prompt. You'll find it in the first entry in the IPv4 Route Table where Network Destination is 0.0.0.0 and the Netmask is 0.0.0.0. You will use the Gateway ip address in the next step. The following step assumes that the Gateway ip address is 192.168.1.1
Enter the following commands to route Internet traffic through your Internet connection's gateway. Use your gateway's IP address for the last address in the following commands. The first two commands make certain that the appropriate entries exist and may generate a benign error message.
route add 0.0.0.0 mask 220.127.116.11 192.168.1.1
route add 18.104.22.168 mask 22.214.171.124 192.168.1.1
route change 0.0.0.0 mask 126.96.36.199 192.168.1.1
route change 188.8.131.52 mask 184.108.40.206 192.168.1.1
rem hit enter to make certain that the prior command is executed
Great, but could we apply this workaround to large scale (I mean to say a organisation who has more than 100 sites and each site has own default gateway) ?
This workaround is for an end client and is not for a multi-user deployment. I just needed it to work for me. I'm not an administrator and not able to recommend a workaround for a multi-user environment.
Update: F5 VPN with split tunnling is working again with Windows 10 Insider Preview 18272.1000.
I think there is a good chance that Microsoft will include this fix in the next official cumulative update.
I encountered a similar issue today after receiving the 1809 update yesterday. I have no Internet access when the VPN is connected. I haven't found a workaround.
Any workaround is appreciated.
There's a Knowledge Center article describing this issue and a workaround. As an end user I don't have the configuration utility that is mentioned.
If you're an administrator on the device, you may be able to update add a static route to force traffic through the tunnel. But that won't work if the access policy is setup to drop the connection if the routing table changes.
In that case, your APM admin must update the policy with the workaround.
Please see below the latest update from F5 support.
Thank you for an update. Yes, the workaround should work.
I don't have right now much info about the bug details and when the permanent fix is ready. Currently, I'd recommend not moving other machines which normally use SSL VPN to release 1809 until the fix is ready. For those machines which have been already moved to 1809, you can use the mentioned workaround.
1803 (RS4) version shouldn't be affected by the mentioned bug but you can double-check.
Windows 10 version history
I propose the following -> you will fully test the workaround and update me; from my end I will monitor the bug related updates (it is being handled with high priority by our product developers) and when I have something I will let you know.
I haven't tested it to windows 1803 version and as it looks to me as temporary fix and hard to implement on large scale.
Sorry to mention the whole process of this temporary work around.
Here you go.
On each affected PC split the default gateway for two routes:
Step : 1
Step: 2 ( add 0.0.0.0/1 and 220.127.116.11/1)
I applied below command.
Route print -p 0.0.0.0 netmask 18.104.22.168 default gateway (Ip address of your default gateway)
Route print -p 22.214.171.124 netmask 126.96.36.199 default gateway(Ip address of your default gateway)
I hope, this temporary workaround can fix the issue. Thanks
Hi all, Is this something we could cure using a different version of APM [i.e 13.1.1 or v.14]?? I am on version 188.8.131.52
We have some users on windows build 1809, and experiencing issues as can't go to the internet while on the F5-VPN. On our APM policy, routing changes while on the VPN are not allowed and drop the connection. So if we can not change the routing table on the desktop as workaround, Can the Windows 10 be upgraded or downgraded to a newer or older version far from 1809 build? How ease or difficult is this?
Same problem. Cannot be on VPN without losing internet connections due to split tunnel set by my admins. I am not an admin so cannot change the settings to rout all traffic as suggested above. Microsoft is not able to help me, and in fact does not admit to knowing about the problem!! Any suggestions as to how to contact f5?
The problem is known by Microsoft. See https://support.microsoft.com/en-us/help/4464619/windows-10-update-history. This article says that Microsoft is working on a resolution and will provide an update in an upcoming release.
So hopefully it will be fixed in the december cumulative updates (coming next week).
At present, the link describes the problem (Nov 14) but the suggested workaround is to force all tunneling to one channel. This is not an option for my organization, so there is no present workaround. And microsoft support denies knowing about the problem when I called them to find out if there was any progress! So I guess the only solution is to patiently suffer an wait for them to issue a release that miraculously makes the problem go away.