* Resend: MASQUERADE: Route sent us somewhere else.
@ 2005-04-04 21:55 Tim Evans
2005-04-05 4:49 ` Jason Opperisano
0 siblings, 1 reply; 7+ messages in thread
From: Tim Evans @ 2005-04-04 21:55 UTC (permalink / raw)
To: netfilter
I'm resending this, as this normally vocal list has been unfortunately silent.
------------- Begin Forwarded Message -------------
X-POP3-Rcpt: tkevans@tkevans.com
Date: Sun, 3 Apr 2005 09:39:28 -0400 (EDT)
From: Tim Evans <tkevans@tkevans.com>
To: netfilter@lists.netfilter.org
Content-MD5: nQ1B8/s75ZlYfpSmzC5wHg==
X-Spam-Score: -2.6 (--)
Subject: MASQUERADE: Route sent us somewhere else.
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on osprey.tkevans.com
X-Spam-Level:
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
Since upgrading to RedHat Enterprise Version 4, I've been having goofy routing
problems and iptables has been logging this message regularly:
Apr 3 04:15:01 kestrel kernel: MASQUERADE: Route sent us somewhere else.
My immediate ISP is Comcast, but my main domain is hosted at another ISP.
By "goofy routing problems," I mean I have trouble accessing my *own domain* at
my ISP for POP-ing down e-mail and *all* other connections. There are periods
of anywhere from a few minutes to an hour or longer where all connections to the
domain simply time out. At the same time, I *can* connect to other domains,
including others that belong to me on the same ISP.
During these incidents, traceroutes to my main domain hang at the very first hop
(Comcast's first router); if I run a traceroute to any other site in a different
window at the very same time, it proceeds all the way to its destination
virtually instantly.
The above error consistently corresponds with a cron job that runs fetchmail to
POP my e-mail down from the ISP.
I have the following lines in my iptables script that reference masquerading:
/sbin/modprobe ipt_MASQUERADE
/sbin/iptables -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE
I have not changed the iptables script since upgrading to RHEL 4; I did not see
any such problems with RHEL 3.
What's doubly goofy about these problems is they're intermittent. After a spell
of being unable to connect (again, ranging from just a few minutes to an hour or
more), it'll suddenly begin working.
And, to repeat, this only affects my primary domain; no other connections to any
other domain I try see these failures.
--
Tim Evans, TKEvans.com, Inc. | 5 Chestnut Court
tkevans@tkevans.com | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ |
------------- End Forwarded Message -------------
Tim Evans, TKEvans.com, Inc. | 5 Chestnut Court
tkevans@tkevans.com | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ |
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Resend: MASQUERADE: Route sent us somewhere else.
2005-04-04 21:55 Tim Evans
@ 2005-04-05 4:49 ` Jason Opperisano
0 siblings, 0 replies; 7+ messages in thread
From: Jason Opperisano @ 2005-04-05 4:49 UTC (permalink / raw)
To: netfilter
On Mon, Apr 04, 2005 at 05:55:54PM -0400, Tim Evans wrote:
> I'm resending this, as this normally vocal list has been unfortunately silent.
the error message you refer to in your subject is normally encountered
when using MASQUERADE in conjunction with policy routing, which normally
implies multiple ISP connections.
i cannot find information referencing any of the above in the details of
your post; which could be a possible explanation for the silence.
-j
--
"She's a whiny little runt isn't she?
What? I said runt."
--Family Guy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Resend: MASQUERADE: Route sent us somewhere else.
@ 2005-04-05 10:35 Tim Evans
2005-04-05 14:50 ` Jason Opperisano
0 siblings, 1 reply; 7+ messages in thread
From: Tim Evans @ 2005-04-05 10:35 UTC (permalink / raw)
To: netfilter, opie
Thanks for your reply.
>the error message you refer to in your subject is normally encountered
>when using MASQUERADE in conjunction with policy routing, which normally
>implies multiple ISP connections.
Just one connection.
>i cannot find information referencing any of the above in the details of
>your post; which could be a possible explanation for the silence.
Might it be some sort of conflict between my immediate ISP (Comcast) assigning a
my firewall a domain name via DHCP and my using my "real" domain name on the
inside? Again, however, this problem didn't happen with RHEL 3.
I've also noted that if I run a traceroute to my main domain and let it
finish--it may take a minute or two, but it eventually connects--other
connections then work. Immediate workaround is to insert the traceroute into my
fetchmail cron job.
--
Tim Evans, TKEvans.com, Inc. | 5 Chestnut Court
tkevans@tkevans.com | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ |
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Resend: MASQUERADE: Route sent us somewhere else.
2005-04-05 10:35 Resend: MASQUERADE: Route sent us somewhere else Tim Evans
@ 2005-04-05 14:50 ` Jason Opperisano
2005-04-05 16:12 ` Tim Evans
0 siblings, 1 reply; 7+ messages in thread
From: Jason Opperisano @ 2005-04-05 14:50 UTC (permalink / raw)
To: netfilter
On Tue, Apr 05, 2005 at 06:35:49AM -0400, Tim Evans wrote:
> Thanks for your reply.
>
> >the error message you refer to in your subject is normally encountered
> >when using MASQUERADE in conjunction with policy routing, which normally
> >implies multiple ISP connections.
>
> Just one connection.
>
> >i cannot find information referencing any of the above in the details of
> >your post; which could be a possible explanation for the silence.
>
> Might it be some sort of conflict between my immediate ISP (Comcast) assigning a
> my firewall a domain name via DHCP and my using my "real" domain name on the
> inside? Again, however, this problem didn't happen with RHEL 3.
the error message implies a routing problem--the domain name of the
router is not a factor in the routing decision normally.
the gist of that error message is this: the output interface for this
packet according to the routing table is different from the interface we
are doing a lookup on for the MASQ IP. i cannot fathom how you could
get this message with a standard inside/outside interfaces, single
default gateway, firewall machine.
without seeing some rules[1], some routing tables[2], and some addressing
info[3], i'm pretty sure no one is going to be able to divine what the
problem is.
the reason you're seeing this after an upgrade is because this bug reared
it's head somewhere around 2.4.23 and later kernels (someone else probably
has a better memory than me).
-j
[1] iptables -t mangle -vnxL; iptables -t nat -vnxL; iptables -vnxL
[2] ip ro sh
[3] ip -4 -o addr sh
--
"Peter, you're bribing your daughter with a car?
Ah, c'mon, Lois, isn't 'bribe' just another word for 'love?'"
--Family Guy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Resend: MASQUERADE: Route sent us somewhere else.
2005-04-05 14:50 ` Jason Opperisano
@ 2005-04-05 16:12 ` Tim Evans
2005-04-05 17:03 ` Jason Opperisano
0 siblings, 1 reply; 7+ messages in thread
From: Tim Evans @ 2005-04-05 16:12 UTC (permalink / raw)
To: Jason Opperisano, netfilter
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
On Tue, 5 Apr 2005 10:50:28 -0400, Jason Opperisano wrote
> the gist of that error message is this: the output interface for
> this packet according to the routing table is different from the
> interface we are doing a lookup on for the MASQ IP. i cannot fathom
> how you could get this message with a standard inside/outside
> interfaces, single default gateway, firewall machine.
>
> without seeing some rules[1], some routing tables[2], and some addressing
> info[3], i'm pretty sure no one is going to be able to divine what
> the problem is.
>
> the reason you're seeing this after an upgrade is because this bug reared
> it's head somewhere around 2.4.23 and later kernels (someone else probably
> has a better memory than me).
>
> -j
>
> [1] iptables -t mangle -vnxL; iptables -t nat -vnxL; iptables -vnxL
> [2] ip ro sh
> [3] ip -4 -o addr sh
Thanks, again.
Please see the attached outputs of each of these commands.
--
Tim Evans, TKEvans.com, Inc. | 5 Chestnut Court
tkevans@tkevans.com | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ |
[-- Attachment #2: mangle.out --]
[-- Type: application/octet-stream, Size: 790 bytes --]
Chain PREROUTING (policy ACCEPT 145883 packets, 30299061 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 4992 packets, 854197 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 140831 packets, 29442464 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2218 packets, 256772 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 143002 packets, 29687892 bytes)
pkts bytes target prot opt in out source destination
[-- Attachment #3: nat.out --]
[-- Type: application/octet-stream, Size: 929 bytes --]
Chain PREROUTING (policy ACCEPT 14728 packets, 1311911 bytes)
pkts bytes target prot opt in out source destination
11 524 DNAT tcp -- * * 0.0.0.0/0 69.251.52.64 tcp dpt:22 to:192.168.252.3
Chain POSTROUTING (policy ACCEPT 7 packets, 364 bytes)
pkts bytes target prot opt in out source destination
3 164 SNAT tcp -- * * 0.0.0.0/0 192.168.252.3 tcp dpt:22 to:192.168.252.5
12745 792138 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 726 packets, 53160 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 69.251.52.64 tcp dpt:22 to:192.168.252.3
[-- Attachment #4: all.out --]
[-- Type: application/octet-stream, Size: 5690 bytes --]
Chain INPUT (policy DROP 1164 packets, 339611 bytes)
pkts bytes target prot opt in out source destination
1890 231383 bad_tcp_packets tcp -- * * 0.0.0.0/0 0.0.0.0/0
2835 324223 ACCEPT all -- eth0 * 192.168.252.0/24 0.0.0.0/0
96 11986 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth0 * 0.0.0.0/0 192.168.252.255
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
1008 181579 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
173 8936 tcp_packets tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0
991 330675 udpincoming_packets udp -- eth1 * 0.0.0.0/0 0.0.0.0/0
23 3688 icmp_packets icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 216.158.56.113 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 207.245.84.72 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 199.173.224.20 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 199.173.224.2 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 199.173.225.21 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 147.140.12.128 192.168.252.3 tcp dpt:22
802 229382 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT INPUT packet died: '
Chain FORWARD (policy DROP 8 packets, 360 bytes)
pkts bytes target prot opt in out source destination
123395 27830181 bad_tcp_packets tcp -- * * 0.0.0.0/0 0.0.0.0/0
76379 6657523 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
64793 22816129 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 216.158.56.113 192.168.252.3 tcp dpt:22
2 120 ACCEPT tcp -- * * 207.245.84.72 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 147.140.12.128 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 199.173.224.20 192.168.252.3 tcp dpt:22
1 44 ACCEPT tcp -- * * 199.173.224.2 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * * 199.173.225.21 192.168.252.3 tcp dpt:22
0 0 ACCEPT tcp -- * eth1 192.168.252.3 0.0.0.0/0 tcp spt:22
8 360 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT FORWARD packet died: '
Chain OUTPUT (policy DROP 10 packets, 760 bytes)
pkts bytes target prot opt in out source destination
1435 208898 bad_tcp_packets tcp -- * * 0.0.0.0/0 0.0.0.0/0
96 11986 ACCEPT all -- * * 127.0.0.1 0.0.0.0/0
1121 127751 ACCEPT all -- * * 192.168.252.5 0.0.0.0/0
1076 117843 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
10 760 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT OUTPUT packet died: '
Chain allowed (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
Chain bad_tcp_packets (3 references)
pkts bytes target prot opt in out source destination
64 13844 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x16/0x02 state NEW LOG flags 0 level 4 prefix `New not syn:'
64 13844 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x16/0x02 state NEW
Chain icmp_packets (1 references)
pkts bytes target prot opt in out source destination
23 3688 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
Chain tcp_packets (1 references)
pkts bytes target prot opt in out source destination
Chain udpincoming_packets (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53
0 0 ACCEPT udp -- * * 172.30.12.34 0.0.0.0/0 udp spt:67 dpt:68
[-- Attachment #5: route.out --]
[-- Type: application/octet-stream, Size: 250 bytes --]
192.168.252.0/24 dev eth0 proto kernel scope link src 192.168.252.5
69.251.48.0/21 dev eth1 proto kernel scope link src 69.251.52.64
169.254.0.0/16 dev eth1 scope link
default via 69.251.48.1 dev eth1
default via 192.168.252.254 dev eth0
[-- Attachment #6: addressing.out --]
[-- Type: application/octet-stream, Size: 199 bytes --]
1: lo inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0 inet 192.168.252.5/24 brd 192.168.252.255 scope global eth0
3: eth1 inet 69.251.52.64/21 brd 69.251.55.255 scope global eth1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Resend: MASQUERADE: Route sent us somewhere else.
2005-04-05 16:12 ` Tim Evans
@ 2005-04-05 17:03 ` Jason Opperisano
2005-04-05 17:24 ` Tim Evans
0 siblings, 1 reply; 7+ messages in thread
From: Jason Opperisano @ 2005-04-05 17:03 UTC (permalink / raw)
To: netfilter
On Tue, Apr 05, 2005 at 12:12:38PM -0400, Tim Evans wrote:
> Thanks, again.
>
> Please see the attached outputs of each of these commands.
you have two default routes, one pointing out the external interface and
one pointing out the internal interface:
default via 69.251.48.1 dev eth1
default via 192.168.252.254 dev eth0
get rid of the second one. if you have networks beyond 192.168.252.254
that you need to reach, then add routes for those networks specifically.
IIRC, you're running RedHat, in which case you can add your routes
to the /etc/sysconfig/static-routes file so that they are restored at
each reboot.
the problem here is that it ever worked in the first place, not that it
doesn't work now.
-j
--
"Brian: Ah, if my memory serves me, this is the physics department.
Chris: That would explain all the gravity."
--Family Guy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Resend: MASQUERADE: Route sent us somewhere else.
2005-04-05 17:03 ` Jason Opperisano
@ 2005-04-05 17:24 ` Tim Evans
0 siblings, 0 replies; 7+ messages in thread
From: Tim Evans @ 2005-04-05 17:24 UTC (permalink / raw)
To: Jason Opperisano, netfilter
On Tue, 5 Apr 2005 13:03:49 -0400, Jason Opperisano wrote
> you have two default routes, one pointing out the external interface
> and one pointing out the internal interface:
>
> default via 69.251.48.1 dev eth1
> default via 192.168.252.254 dev eth0
Dang, there it is, right there in /etc/sysconfig/network-scripts/ifcfg-eth0.
Obviously, my mistake, in not blanking out the pre-filled gateway box at
install time.
Thanks, once more.
--
Tim Evans, TKEvans.com, Inc. | 5 Chestnut Court
tkevans@tkevans.com | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ |
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-04-05 17:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-05 10:35 Resend: MASQUERADE: Route sent us somewhere else Tim Evans
2005-04-05 14:50 ` Jason Opperisano
2005-04-05 16:12 ` Tim Evans
2005-04-05 17:03 ` Jason Opperisano
2005-04-05 17:24 ` Tim Evans
-- strict thread matches above, loose matches on Subject: below --
2005-04-04 21:55 Tim Evans
2005-04-05 4:49 ` Jason Opperisano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.