that makes some sense to me as it would explain why it works using the wireless interface which doesn't come up at boot time. I;ll give it a try tomorrow.

I followed your instructions and it worked like a charm! The only issue that I had is that iptables is in /sbin on Fedora Core. I didn't have to prevent the cisco init at boot time, just restart it. I wonder if this is even necessary or just setting the MTU after connection is sufficient? Anyway, this should work for Fedora Core 3 users:

/etc/rc.d/init.d/vpnclient_init stop
/sbin/iptables -F
/etc/rc.d/init.d/vpnclient_init start
vpnclient connect <yoru profile here>
ifconfig eth0 mtu 1500


I've succeeded in establishing connections with Perforce, rdesktop, and also an SQLServer connection.

wankelrx8 : i am confirming that your workaround did work on my Gentoo 2.6.9 box. Thank you very much ...now we need to figure out if it's possible to set this value somewhere in the vpnclient settings. I've looked all over Cisco website and looks like you can only preconfigure it for WIndows only, and have to manually change for *nix os. Oh well..it's much better than using my VMvware Xp machine . Thanks again man.

Great find. works good for all remote login functions except NFS. I am still having the NFS mount problems. It usually takes about 20-30 seconds before the entire machine locks up. I have tried using a -o soft and using a bg but to no avail. Any Ideas?

Found this on the cisco bug tracker -

Sound familiar?

They say it is fixed in version 4.0(3)C. I think this is the overall release version number rather than the specific version quoted above as 4.0 is the highest version listed. It looks like a bug where they are setting the physical mtu too low for no reason.

There are no bugs listed regarding nfs.

Changing the MTU size worked also for me.

I am running Fedora Core 3 with kernel version 2.6.9-1.681_FC3 and Cisco VPN Client for Linux, release 4.6.00.0045. I have the firewall and SElinux enabled. After booting, I issue:

/etc/init.d/vpnclient_init start
/usr/local/bin/vpnclient connect "my vpn"
/sbin/ifconfig eth0 mtu 1500

That's it. Would be great if Cisco mentioned that. They haven taken note of the problem, but offer no help. See http://vpn.doit.wisc.edu/download/te...045-readme.txt

Best wishes,
Michael

saved by the forums once again. I've been struggling with this for about a week now, can't believe it was such a simple fix.

Thanks!

Leave it to the folks here to solve my annoying problem.

Much thanks wankelrx. This fixed my problem exactly and things are working smoothly.

Try setting your MTU size in the Advanced settings of your Linksys router to 1500 (enabled).

Then after bringinng up your VPN connection, for receiving emails with attachments, set the MTU size to 1385.

For sending emails with attachments, set it to 1500.

I'm using Apani Networks netlock and I've found this to be the case with 2.6.9 kernel on Redhat.

jm2cts,
MacDuff

My story:

I've got a Broadcom 570x NIC running under Fedora Core 3. The VPN client authenticates fine but I get the fragmentation/mtu problem:

This works:

ping -s 1000 remotehost

This fails:

ping -s 2000 remotehost

At home, using the workaround

/sbin/ifconfig eth0 mtu 1500

fixes that problem and all is good. However from work (remote site trying to connect to the home office), it does not help (I can still ping -s 1000, but not ping -s 1400 from the remote site). After STFW for a little while, I'm still not exactly sure why the workaround works at home - and why it might fail elsewhere.

by setting /sbin/ifconfig to 1500, there should be no chance that the network driver would drop the packet+ip-sec header (which was presumably happening when vpnclient set the eth0 mtu to 1352(?)).








For completeness, I'm including the Cisco known issue that seems to be at the heart of all this consternation.


Unresolved Issues

CSCee60154

Symptoms
After making a VPN Client connection, some traffic types no longer work.
Specifically applications that send large packets like SMTP, HTTP, and SSH.

Conditions
The 2.6.4 Kernel enabled a feature of certain ethernet cards that discards
packets larger than the configured MTU. Since the VPN Client lowers the MTU
visible to the applications in order to add it's overhead without exceeding
the original MTU, the resulting packets are bigger than the newly configured
MTU. Therefore the card throws out the large encrypted packets.

This can easily be tested with a ping.
ping -s 500 x.x.x.x should pass
ping -s 2600 x.x.x.x should fail

Workarounds
If an lsmod shows that the "e100" driver is in use for the network card, it
can be replaced with the "eepro100" driver.

ifdown eth0
rmmod e100
modprobe eepro100
ifup eth0