Also, those
128.0.0.0 network-masks are both highly unusual and very broad: they're testing
a single bit! Do some
route commands to see where various IP-addresses are really being directed. I think you'll find that those routes are sweeping far more information than you expect into the tunnel.
I would ordinarily expect to find only a very-few routes being added: maybe, only one.
All that you want, in this case, is for the specific range of addresses corresponding to the subnet to be swept into the tunnel, using netmasks that contain only "255's" and "0's." (No "128's.")
If you want to sweep
10.8.0.xx and
128.x.x.x into the tunnel, then that's exactly what
(two ...) added route commands should say. And, nothing more:
(for example... maybe ...)
Code:
# Dest. Netmask Gateway
route 10.8.0.0 255.255.0.0 10.8.0.17
route 128.0.0.0 255.0.0.0 10.8.0.17
When creating routing rules,
"less is more."
I suspect that many connections, if made while the tunnel is "up," are being directed through the tunnel when you don't expect them to. Consequently, they are lost when the tunnel is taken down.
