Bug 56796

Summary:	Server dies when iptables and cisco vpn are both running
Product:	[Retired] Red Hat Linux	Reporter:	Mike Smith <mike>
Component:	iptables	Assignee:	Bernhard Rosenkraenzer <bero>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-11-27 22:12:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mike Smith 2001-11-27 22:12:45 UTC

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:
Always

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 23:25:30 UTC

Since it locks up the machine, it's caused by the proprietary kernel modules 
from Cisco. This is their bug, not ours.