Kor Kiley wrote:
> Let this be my official complaint. I'm sure there are pros and cons for
> implementing this. But I agree with Chris. It's extremely annoying.
> I've been silently bearing it for some time but I wish it were otherwise.
I thought this had been addressed previously but perhaps not on this list...
We USED to have split-tunneling enabled on the VPN such that only
18.104.22.168 traffic would take the tunnel.
In conjunction with this configuration, we had a very long list of
exceptions-- primarily library resources which are only accessible from
a 22.214.171.124 address.
So in addition to 126.96.36.199 traffic, all networks in the exception
list would also take the tunnel.
This worked well until we added one more exception address. This
exceeded the maximum number of allowed exceptions and COMPLETELY broke
the off-campus VPN. The only way to return functionality without
disallowing access to these library resources from an off-campus VPN
connection was to turn off split-tunneling and have all traffic take the
We realised at the time that this was not a great solution but the
alternative -having one configuration without split-tunneling and a
separate Library VPN configuration with no split-tunneling seemed to
introduce even more confusion.
We can certainly revisit the idea of having two separate VPN
configurations, with only one allowing access to these library
resources, and the other allowing split-tunneling.