[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Double "VPN"-PPD-SSH network break



Hi,

I've got a interesting-playing-with ssh-vpn type setup where I tunnel over
SSH to a remote machine and start up pppd so these two machines are
networked, the command is something like:

pppd nodetach noauth 192.168.0.1:192.168.0.2 pty 'ssh user@vpnbox
bin/startupvpn.sh'

Where on user@vpnbox:bin/startupvpn.sh I have something like:
pppd notty noauth proxyarp

This works 100% I can transfer large-ish files quite acceptably (surprising
for SSH and PPPD working like that!) and it's up all the time and
re-establishes nicely when my connection drops.

To make things a tad more complicated now, I have a static route to vpnbox2
over vpnbox (route add vpnbox2 gw vpnbox). At this point I can ping/scp/etc
fine to vpnbox2 by going over vpnbox's "VPN". 

I for fun now want to have not only a ppp1 (for vpnbox) on my localbox (as
in my local machine) but a ppp2 (for vpnbox2) which obviously get's routed
via vpnbox (ppp1) anyway (I have no way of reaching vpnbox2 directly being
the reason for this) so I can go mad as-if vpnbox2 is on my own LAN... this
is where the problems start creeping in (using exactly the same pppd scripts
as above).

The connection is made from localbox -> vpn -> vpnbox2, I get my IP address,
etc, I can ping the other side, ssh to it with it's new local ip and it all
looks fine. But - As soon as I start doing anything more
bandwidth-orientated the connection just 'hangs'.

I can reproduce this problem by pinging vpnbox2 through the vpn continiously
(to serve as diagnostic) and then starting a scp, as soon as scp starts
copying the file to vpnbox2 - the ping's just stop.
PPPD on either side does not complain, I'll merely get a LCP timeout after
my pppd option's timeout values gets reached.
I've tried various things, playing with compression & no-compression &
changing algorithms on both the pppd and ssh side on both sides of the
connection (localbox & vpnbox2).
I've tried making the mtu&mru's both big and small and other way round and
one way round with absolutely no effect.

During the 'hanging' phase I can still 'ping' the realworld-ip address (and
see the ports I am supposed to see from the outside world) of vpnbox2 so it
is not a connectivity/firewalling issue as far as I can see. - The only way
to re-establish the vpn to vpnbox2 is to kill the ssh's and pppd's on
localbox and vpnbox2 and re-run my pppd, it is fine again until a big packet
makes it's way through ): The behaviour of when the vpnbox2 connection dies
also seems to have nothing to do with latency of localbox, vpnbox or
vpnbox2.

While yes - I do realise that this is most definitely not the most efficient
way to do the "VPN"'s, it is more a fun experimentation of working around
third world country ISP's with nasty routing and where the end's of the
VPN's cannot necessarily see each other directly without a performance
impact. 

So - does anybody have any idea why a VPN routed over another VPN (in the
SSH-PPPD) sense, just seems to break when (it looks like) fragmentation
happens?!

Many thanks!
Francois Botha








Reply to: