Bug 56796 - Server dies when iptables and cisco vpn are both running
Server dies when iptables and cisco vpn are both running
Product: Red Hat Linux
Classification: Retired
Component: iptables (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Depends On:
  Show dependency treegraph
Reported: 2001-11-27 17:12 EST by Mike Smith
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-27 17:12:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Smith 2001-11-27 17:12:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
I have 2 different servers with Redhat 7.2 installed. Both have all the 
current updates installed. Kernel is 2.4.9-13....

 If I disable iptables and run the cisco vpn client, everything works as 
advertised. When I turn iptables on, all seems well until I try to access 
something that needs to go down the vpn. Then the box dies. No response, 
can't kill the X Server or 3 finger the machine. Requires a power cycle. 
There are no strange messages in the log files either.

 Not sure how to go about tracking this down. No core dumps or anything to 
look at. 

 Only thing is it is reproducable on 2 different machines.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. /etc/rc.d/init.d/iptables start
2. /usr/local/bin/vpnclient connect foo 
3. nslookup www.google.com
 Machine dies at this point. 

Actual Results:  VPN makes secure connection and all looks fine, until you 
try to do a nslookup, dig, lynx, ping, netscape, etc.

Expected Results:  Machine not to lock up completly.

Additional info:
Comment 1 Bernhard Rosenkraenzer 2001-11-27 18:25:30 EST
Since it locks up the machine, it's caused by the proprietary kernel modules 
from Cisco. This is their bug, not ours.

Note You need to log in before you can comment on or make changes to this bug.