Altocumulus
EmployeeThe routing that Edge Client (EC) sets is derived from the current routing and whatever the settings are on the client. Windows does have some DNS and proxy idiosyncrasies that necessitate the client to push a "route all traffic over the tunnel" route as 0.0.0.0/1 & 128.0.0.1/1 in some cases, because Windows treats devices with a 0.0.0.0/0 route differently than devices with both 0.0.0.0/1 and 128.0.0.1/1 routes, even though at L3 they're effectively equivalent. You might try to adjust your client PC to a more common "192.168" subnet to see how the behavior changes.
You can find in the Edge Client log files very detailed logging about what is the current (before EC does anything) and what is the result (after EC adjusts the routes) that are set.
Examine these EC logs closely to see how this compares to your Network Access List settings.
AltocumulusI am familiar with those settings, and this issue does not happen to any other win10 outside my local network.
This happens only to my local network, and cannot change it now to 192.168. because it is complicated
but the question is why the F5 decides to route my local network 128.0.0.0 to its VPN gateway ?
I contacted TAC and they asked to gather some logs from CTU... but they still investigating this issue
It worth mentioning that this is issue not not occur if using browser with network connect enabled after the connection established. This issue only happens with BigIP Edge Client.
AltocumulusUpdate#2:
Adding 128.0.0.0 to "IPV4 Exclude Address Space" has resolved the issue.
But, Why we needed to add this?
We have not added 128.0.0.0 to "IPV4 LAN Address Space". So why edge client rerouting 128.0.0.0 to tunnel ?
I asked F5 TAC and waiting for them to answer