[clue-tech] VPN using ipip tunnelling

Ryan Kirkpatrick ug at rkirkpat.net
Wed Aug 16 18:02:52 MDT 2000


On Wed, 16 Aug 2000, Jim Ockers wrote:

> > There was a two part article in Linux Journal about January this year.
> > This discussed using pppd and ssh to implement a VPN. This might
> > help.

> I am re-doing the VPN between two of the links to NOT use the PPP/SSH
> because of too high latency on one link (messes up our app - Citrix
> Winframe) and an unexplained loss of bandwidth on the other link (for no
> apparent reason, we suddenly start getting 50% packet loss at the 64-byte
> packet-size, and 100% packet loss at 256-byte or more packet-size). 
> 
> The second link is the one that is mysterious to me.  It should work 
> fine.  I have 6 or 7 other VPN links with PPP/SSH that never exhibit this 
> behavior.  The only way to restore functionality is to kill pppd/ssh and 
> let the link restart.

	I haven't read the article (LJ piling up on me as well), but if I
understand the VPN correctly, I think I know what is going wrong. With the
PPP/SSH vpn setup that I am familar with, you establish a SSH tunnel
between two machines, and then run PPP through that tunnel by redirecting
a socket to a pty with a little C program. 
	The major problem with this setup is that you have two TCP/IP
stacks layered on top of each other. What this means, is if a packet at
the SSH level is dropped (overloaded router, etc...), then the TCP/IP
stack starts performing retransmissions at ever increasing intervals
(known as backoff I think). Meanwhile, the PPP level is losing packets as
a result of the SSH level losing packets, and so it too starts performing
retransmissions at ever increasing intervals. 
	The end result is that your bandwidth goes into the gutter real
quick. Even if the SSH level starts getting its packets through, there is
a time delay until the PPP level sees this happen (since it sending
packets at long intervals by now). If the connection starts dropping even
a small to moderate number of packets, your VPN connection gets messed up
pretty quick.
	The moral of this story is that layering TCP on top of TCP is just
asking for trouble. Unless the VPN is across an internal, all ethernet,
low traffic network, this solution is not really feasiable (esp given the
high load present on the Internet as a whole). Most "real" VPN solutions
setup a straight IP or UDP/IP connection (or from what I have seen they
do), and leave the dropped packet handling to the protocol running over
the VPN link (i.e. TCP/IP with PPP or the like). This is how Microsoft's
PPTP protocol works, for which there are available servers and clients for
Linux (search for PoPToP).
	I don't claim to be a TCP/IP guru, so my explaination may not be
perfect. This is just what I have learned from my own experiences and from
people who do profess to be TCP/IP gurus. :) Either way, my two cents.
TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------




More information about the clue-tech mailing list