Bug 55254 - Bad: iptables masquerading after network restart has a problem
Bad: iptables masquerading after network restart has a problem
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
7.2
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-28 07:49 EST by Tanel
Modified: 2014-03-16 22:24 EDT (History)
3 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Tanel 2001-10-28 07:49:15 EST
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 06:54:09 EST
Guess the ifup script should run iptables on the new device...
Comment 2 Tanel 2001-10-30 11:19:20 EST
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 09:03:28 EST
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.