Bug 31054 - iptables rules don't take effect for running apps
Summary: iptables rules don't take effect for running apps
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Miller
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-08 06:25 UTC by James Manning
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-08 10:17:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description James Manning 2001-03-08 06:25:57 UTC
Now on the surface this isn't anything but a cosmetic bug, but it
feels like one of those things that could be a symptom of a deeper
problem.  If that turns out to not be the case, so be it :)

 - masq'ing 2.4.2-0.1.19 box has nothing but a masq'ing rule out eth0.
 - box behind it starts ping to external box, which is working fine.
 - masq'ing box drops masq'ing rule
 - ping on internal box stops working, predictably (don't kill the ping
program, though)
 - masq'ing box re-adds the masq'ing rule
 - existing ping from internal box to external box does *not* start working
 - new ping (while other ping is still running) *does* work fine.

since icmp echo is anything but connection-oriented, this might seem
to indicate a deeper problem with netfilter

I'm going to try and confirm on a "pure" RC2 setup, as this is RC2
kernel with some stuff from earlier betas.

Comment 1 David Miller 2001-03-08 20:45:31 UTC
When the masq rule goes down, the first ping you run (which fails) binds itself
to the destination differently, it retains this binding through the rest of the
sockets life.  This behavior is completely normal.

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