[Bug 63] New: fwmark loopback routing issue
bugzilla-daemon@netfilter.org
bugzilla-daemon@netfilter.org
Sat, 15 Mar 2003 16:34:08 +0100
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=63
Summary: fwmark loopback routing issue
Product: netfilter/iptables
Version: linux-2.4.x
Platform: i386
OS/Version: RedHat Linux
Status: NEW
Severity: normal
Priority: P2
Component: ip_tables (kernel)
AssignedTo: laforge@netfilter.org
ReportedBy: imitev@obs.bg
CC: netfilter-buglog@lists.netfilter.org
hi,
summary: setting a fwmark in the INPUT chain of mangle makes ping echo-replies
go into the lo device.
network structure:
inet
|
cisco rtr
/ (.61/30) \ (.125/30)
/ \
/ .(62) \ (.126)
lnx rtr cisco rtr
/ (.49/29) \ .(.113/29)
/ \
A (.50) B (.114)
when i try to ping B from A, i get no reply; but tcpdump on B (on all ifs) gives:
213.91.169.50 > 213.91.169.114: icmp: echo request (DF) [tos 0x30]
213.91.169.114 > 213.91.169.114: icmp: echo reply [tos 0x30]
!! .114 > .114 !!; tcpdump on B on lo dev confirms that the echo-reply goes to
the lo device and is not sent back to A.
strange thing: i get the same behavior pinging A from B. but when i ping from an
"outside" host in the internet, everything works. moreover, i get this only for
icmp. eg. ssh A<->B works. really strange.
A and B machines were running 2.4.20 custom kernel with iptables 1.2.7a, + IMQ
patch; they are ipsec gws; thinking it was maybe a kernel or ipsec problem, i
reverted to the stock rh kernel (2.4.18-5); but still with the same problem
after playing with routes and iptables, i found that doing :
(everything flushed and cleaned, filter accepts everything, no nat, etc.)
iptables -t mangle -A INPUT -j MARK --set-mark 1
"breaks" the echo-reply, sending things into the lo and mangling the dst address
into the local one
however, no prob when marking is done elsewhere (eg. in PREROUTING)
any clue ? i spent a whole afternoon on it, but i didn't find any error in my
network settings...
i can provide more details if needed
ivan
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.