Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Heeelllp Mr. Wizard!!!

0 views
Skip to first unread message

Jeffrey S. Mulliken

unread,
Feb 2, 2001, 2:20:51 AM2/2/01
to
My company is really having a serious problem, and I'm pleading for
anyone who can, to help us.

Here's the situation:

At the Corporate H.Q.:

RedHat Linux 2.2.17 Kernel machine as a gateway / VPN (via PPTP)

server
RedHat Linux 2.2.17 Kernel machine serving NIS and Sendmail
services
A Sun Ultra 2 as a file server, serving NFS mounts on Solaris
2.6
A couple of Sun Enterprise 3000's used as compilers and
ClearCase view servers.

At the Developers Homes:

RedHat Linux 2.2.17 Kernel machines running PPTP VPN tunnels
Linksys 4 port Router/hub's
Win9X or 2K machines also behind the Linksys boxes
Throug a variety of ISP's to the net...i.e. @home/Sprint
DSL/PacBell DSL...etc.

Everyone is able to boot their Linux machines up successfully, and
the PPTP sessions get established,NIS connects to the remote domain, and

NFS mounts happen. All seem ok, until any large amount of data is moved

via the NFS mounts. Performance is VERY slow. Even if NFS mounts are
not used, at random intervals, the PPTP connection will just drop,
causing the NIS domain to lose it's bind. The recovery is to init 1,
and then init 5.

The Linksys boxes have a limitation that restricts you to only one
VPN connection through the router, so the remote Windoze machines can't
be VPN'ed in while the Linux boxes are, but with the Linux box down,
they can establish VPN with their Windoze machine, but it will also lose

it's connection after some period. We have tried eliminating the
Linksys boxes from the equation, and it does not seem to buy us much, if

any, improvement. We don't have the VPN with IPMasq. patch on the
kernels anywhere, because we aren't doing the IPMasq. stuff.

Any 'gurus' out there who have any ideas as to what the problem
might be here?

Help us Obiewan Kenobe, you're our only hope!

Jeff Mulliken
mull...@v-stor.com

Feel free to email me your response

Tauno Voipio

unread,
Feb 2, 2001, 3:57:21 AM2/2/01
to

"Jeffrey S. Mulliken" <mull...@home.com> wrote in message
news:3A7A5FC1...@home.com...

Could you think of changing it to using CIPE instead of PPTP?

The Linux machines of each end of the connection could be used as routers
for the internal IP traffic, so the rest of the networks is transparent. It
can also double as a IP-Masquerade router to the Internet at the same time.
CIPE uses one UDP port / connected client, it is pretty easy to firewall.

I have some of these installations running. The only problem seen so far is
actually a fault in the XDMCP protocol: it is not possible to log in as a
XDM session from one Linux router to the other Linux router - other internal
network combinations are OK. The reason is that the payload in the XDMCP
protocol carries the IP addresses and it misleads the X client to select
wrong IP address when starting the session.

Tauno Voipio
tauno voipio @ iki fi


Jeffrey S. Mulliken

unread,
Feb 2, 2001, 12:06:02 PM2/2/01
to
We would consider any change that would enable our objectives, but one of the
objectives is to be able to connect to the corporate servers with either Linux,
or Windoze machines. We talked about changing to IPSec, but it's my
understanding that Win98 doesn't support IPSec. So, would Win9x work with CIPE?
(Which I have not heard of. Where would I find info on it?)

Thanks again,

Jeff

Steve Davies

unread,
Feb 3, 2001, 9:15:14 AM2/3/01
to
Linux NFS out-of-the-box is complete pants, and will often freeze its
networking subsystem. (I like Linux BTW, just not its 2.2.x NFS
implementation.)

You might find that upgrading to a 2.4 kernel fixes this, but this is
non-trivial. Otherwise the only real workaround I've found is to reduce the
rsize and wsize parameters on the NFS mount to 1024 or less (1024 works for me
on a LAN) This slows nfs down a lot, but over a CM link, you'll probably not
even notice.

Let me know if this helps.
Steve

--
Steve Davies st...@one47.demon.co.uk
http://www.one47.demon.co.uk
PGP Fingerprints:
DH/DSS : 5D85 8164 91D7 E9CC 4F80 842B AB86 93D9 8938 7612
RSA : 4E2E E60F 3D76 9E7E 70F9 901B 70FA 56C8

Jeffrey Mulliken

unread,
Feb 5, 2001, 2:54:53 AM2/5/01
to
Steve,

I appreciate the suggestions, but whereas the folks that do NFS mounting over
the VPN connection do wind up with the 'NFS blah blah can't get a request slot'
errors, we have guys just using Win2K to get mail over the VPN, and THEY loose
thier connections. So, I know that it is some issue with Linux as a PPTP VPN
server that we are wrestling with here. I sure hope that someone has some ideas.
I really like Linux, but there is some issue here that doesn't exist with an NT
VPN server.

Anyone?....Anyone? (Ben Stein in Fast Times at Ridgemont High)

HEEEEELLLLLP!!!!


Jeff.

Steve Davies

unread,
Feb 5, 2001, 5:17:20 PM2/5/01
to
Jeffrey,

I believe that limited IPSec is possible (Transport-only mode) from Linux to
Win-XX systems, but my experiments proved this to be in the "Very hard, and
lots of tweaking" category. Probably not what you want to roll-out for non
Unix-technical users :-( On Linux to Linux IPSec is an excellent option -
Consider mixing protocols.

I assume that you're using PoPToP for your Linux VPN software? You sound like
the FAQ's already been tried, but from the FAQ:

7.3.11. The VPN link works for a while, but then stops working,
and the /var/log/debug file shows messages like the following:
pppd[11170]: sent [LCP ProtRej id=0xb 51 19 ...
pppd[11170]: rcvd [proto=0xbe1b] df 60 4e 4e ...
pppd[11170]: Unsupported protocol 0xbe1b received
(where the hex data and the protocol numbers may vary)

This is probably caused by dropped packets with mppe running in
stateful mode (i.e. mppe-stateless disabled). In stateful mode,
decryption of a packet requires successful decryption of the previous
packet. In stateless mode, a packet can always be decrypted as long
as the sequence number is known.

Solution: add the "mppe-stateless" option to the /etc/ppp/options.pptp
file.


From my own thoughts:

Do you have the latest and greatest OpenSSL? Is PPTP linked to it OK?

What random-number source has OpenSSL or PPTP been configured to use? If
/dev/random, the try changing to /dev/urandom. I think this is the
default, but I'm not sure...

Let us know when you DO find the answer...
Steve

Jeffrey Mulliken wrote:
>
> Steve,
>
> I appreciate the suggestions, but whereas the folks that do NFS mounting over
> the VPN connection do wind up with the 'NFS blah blah can't get a request slot'
> errors, we have guys just using Win2K to get mail over the VPN, and THEY loose
> thier connections. So, I know that it is some issue with Linux as a PPTP VPN
> server that we are wrestling with here. I sure hope that someone has some ideas.
> I really like Linux, but there is some issue here that doesn't exist with an NT
> VPN server.
>
> Anyone?....Anyone? (Ben Stein in Fast Times at Ridgemont High)
>
> HEEEEELLLLLP!!!!
>
> Jeff.
>

--

Tyler Larson

unread,
Feb 15, 2001, 12:57:34 AM2/15/01
to
We had a similar problem on one of our networks. I wasn't the admin then,
so I don't remember all the gritty details, but I remember the what and the
why. We run a RH6.2 deritive on all our machines, about 200 workstations and
3 servers. The main fileserver (NFS) was running a modified RH6.2 with
a journaling filesystem. We experienced the same symptoms you described:
everything worked fine as long as NFS requests were light. When things
got heavy too heavy, the main fileserver stopped responding and the whole
network came to an abrupt halt.

The problem was somewhere in the journaling FS, I believe, because once we
set the fileserver to running just a no-frills ext2 FS, all our problems
went away. Completely.

I realize that this is just a shot in the dark: chances are your
problem is entirely different, but I just figured I'd throw out the
suggestion: every little bit helps.

BTW, were now running NFS servers and workstations on the 2.2.17 kernel
with quite heavy network traffic and are experiencing virtually no
problems with it.

HTH

Tyler

--
Tyler Larson | http://www.tlarson.com | Tyl...@writeme.com
Many hands make light work.
-- John Heywood

0 new messages