I am not sure about tun0
, but I think the script in /etc/network/if-up.d/
and /etc/network/if-down.d/
are invoked when an interface goes up or down, respectively.
Inside the script you can determine which interface is interested from the content of the variable IFACE
.
To be sure, add a simple script to /etc/network/if-up.d/
which content is
#!/bin/sh
# filename: tun-up
if [ "$IFACE" = tun0 ]; then
echo "tun0 up" >> /var/log/tun-up.log
fi
make it executable
sudo chmod +x /etc/network/if-up.d/tun-up
then see if the up events are recorded in /var/log/tun-up.log
The most frequent cause of an issue like this is related to the router hardware and not your connection.
I have seen this problem before, when a Cisco router was used and configured to use a maximum MTU of 1500, and a VPN concentrator was used with a client MTU setting set to 1500. Your computer sends the vpn concentrator a packet of data that is 1500 bits, but the vpn tunnel it's self adds overhead (about 37 bits if memory serves) which makes the total size 1537 which can't make it through the router. This is a malformed packet and the router drops it.
The reason windows machines connect is because it ignores the concentrator's "suggestion" to set the packet size to 1500 and just uses what ever it wants.
Testing:
To make sure this is the problem, try sending a large file (about 1 meg) across the vpn without ssh. This will isolate any ssh issues from lower layer issues. If you get the same disconnect, it's probably the MTU issue.
The fix:
The proper fix is to have the network admin fix the vpn concentrator, setting a lower MTU then the router. Or perhaps fix the router...
From your side you can adjust the vpn MTU size down to say 1400 and everything will just work. There are several ways to do this but this page should give you a head start.
Best Answer
The old-school way is to put a script in
/etc/network/if-up.d
andif-down.d
. I'm not sure if that still works with NetworkManager or not. There should be scripts in there that you can copy to get started.