Bug 55254 - Bad: iptables masquerading after network restart has a problem
Summary: Bad: iptables masquerading after network restart has a problem
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i586 Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-10-28 12:49 UTC by Tanel
Modified: 2014-03-17 02:24 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-06 14:13:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Tanel 2001-10-28 12:49:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)

Description of problem:
after I have done network restart (/etc/init.d/network restart), iptables 
will not masquerade any more connections to the same public IP Network, 
which itself belongs to. Connections to all other IP-s will still be 
masqueraded properly. 

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


How reproducible:
Always

Steps to Reproduce:
1.Redhat 7.2 has 2IP-s, for example, 193.40.10.118 and alias 192.168.4.1
1.iptables -t nat -D POSTROUTING -s 192.168.4.0/24 -j MASQUERADE
2./etc/init.d/network restart
3.ping or telnet or whatever from client (192.168.4.2) to 193.40.10.117 
(_same_ subnetwork which Redhat 7.2 belongs to)
	

Actual Results:  Packets coming from 192.168.4.2 will not be masqueraded 
as coming from 193.40.10.118 but as 192.168.4.1. Destination host 
193.40.10.117 receives packets from 192.168.4.1, which were originally 
created from 192.168.4.2

Expected Results:  packets coming from 192.168.4.2 should have been 
masqueraded as 193.40.10.118 and routed to destination IP (193.40.10.117)

Additional info:

Redhat 7.2, kernel 2.4.9-7.

Comment 1 Bernhard Rosenkraenzer 2001-10-30 11:54:09 UTC
Guess the ifup script should run iptables on the new device...


Comment 2 Tanel 2001-10-30 16:19:20 UTC
Flushing all iptables chains, incl. POSTROUTING and reinserting rule
iptables -t nat -A POSTROUTING -s 192.168.4.0/24 -j MASQUERADE will not solve 
the problem, as well as killing and reloading masquerade and nat modules.


Comment 3 Oliver Schulze L. 2003-02-06 14:03:28 UTC
The reporter does not runs the correct commands.
This should be run to resolve the issue:
1.iptables -t nat -D POSTROUTING -s 192.168.4.0/24 -j MASQUERADE
2. service iptables save
3. service network restart
4. service iptables restart
5. ping or telnet or whatever from client (192.168.4.2) to 193.40.10.117 

Please close as NOTABUG



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