MASQUERADE: Route sent us somewhere else.

MASQUERADE: Route sent us somewhere else.

[Luke Worthy]

Hi hi,

      I am a Linux admin, and recently set up an IP Tables firewall at work.  
Whenever I set up these things, I like to use nice programs with interfaces 
to quickly and easily change things, at the moment, my fav de jour is Jay's 
Firewall (if you havn't seen it - it's very slick).

Anyways, it doesn't use SNAT, just MASQ, and it is on a static IP....so I 
started seeing them msgs:

MASQUERADE: Route sent us somewhere else.

A quick google, and I saw the msgs about Rusty's brain breaking etc.

So I put an older kernel on the firewall, and it's all sweet.  So what I want 
to know is, is 2.4.25 good-to-go using this MASQ technique, or should I talk 
to Jay about incorporating SNAT - or some other suggestion?

Luke

(using Debian Woody)

MASQUERADE: Route sent us somewhere else

[Delian Krustev]

Hi,

I've red the postings about similar messages in the syslog posted in the
mailing list. However my problem is quite different. Here's the setup:

                                 eth1
              eth0  +---------+ static ip 
   *LAN* -----------|         |-------- \
                    |linux-box|           *INTERNET*
                    |         |-------- /
                    +---------+  eth2
                              dhcp configured


*mangle
-A FORWARD -j MARK --set-mark 0x1

*nat
-A POSTROUTING -o eth1 -j SNAT --to-source <eth1 ip>
-A POSTROUTING -o eth2 -j MASQUERADE

/sbin/ip ru add fwmark 0x1 lookup FW prio 40

The main table routes internet traffic via eth2 by default. I'me referencing
the FW table for forwarded traffic, which routes inet traffic via eth1.

However, the SNAT rule in the nat table is ignored(eth1 is not
correctly selected) and the MASQUERADE rule takes place. The packets
are not sent trough eth2 either, and here comes the syslog msg:

MASQUERADE: Route sent us somewhere else

I'm using similar setup for localy generated packets(

*mangle
-A OUTPUT -o eth2 -m owner --uid-owner dev -j MARK --set-mark 0x1

), which works just fine.

Currenly I'm able to workaround the problem by adding the following rule :

/sbin/ip ru add iif eth0 lookup FW prio 45   # [1]

I think there should be two routing decigions(RD) for forwarded packets:

-->PREROUTING-->RD1-->FORWARD-->RD2-->POSTROUTING

, right ?
At least it's that way for the OUTPUT chain. My additional rule [1],
makes both the RDs refer to the same table - FW. Without it the main
table is refered by RD1 and FW by RD2, which breaks the things down.

I'm running kernel 2.4.24 with all the submitted/pending patches from 
p-o-m 20030912 applied.

Any ideas ?

Cheers,
Delian

p.s. please CC me when replying since I'm not subscribed to the list.

MASQUERADE: Route sent us somewhere else

[Horváth Szabolcs]

Hello!

We have a firewall, and it's inside many UML's.
I can't establish new connections from UML, kernel log says
"MASQUERADE: Route sent us somewhere else".

The host system:

# ip rule
0:      from all lookup local
32760:  from 192.168.14.2 lookup uml
32761:  from 192.168.13.2 lookup uml
32762:  from 192.168.12.2 lookup uml
32763:  from 192.168.11.2 lookup uml
32764:  from 213.253.196.232 lookup pantel
32765:  from 213.253.196.226 lookup pantel
32766:  from all lookup main
32767:  from all lookup default

# ip route list table uml
192.168.14.0/24 dev tap4  scope link
192.168.13.0/24 dev tap3  scope link
192.168.12.0/24 dev tap2  scope link
192.168.11.0/24 dev tap1  scope link
10.1.0.0/24 dev eth2  scope link
10.0.0.0/8 via 10.1.0.3 dev eth2
default via 213.253.196.225 dev eth1

# ifconfig
eth1      Link encap:Ethernet  HWaddr 00:0D:88:B4:1C:9F
          inet addr:213.253.196.226  Bcast:213.253.195.255 
Mask:255.255.255.240

eth1:1    Link encap:Ethernet  HWaddr 00:0D:88:B4:1C:9F
          inet addr:213.253.196.232  Bcast:213.253.195.255 
Mask:255.255.255.240

eth2      Link encap:Ethernet  HWaddr 00:50:8D:E9:29:90
          inet addr:10.1.0.1  Bcast:10.255.255.255  Mask:255.255.255.0

ppp0      Link encap:Point-to-Point Protocol
          inet addr:81.182.243.194  P-t-P:195.228.253.19 
Mask:255.255.255.255

tap4 is masqed through eth1. We use shorewall, and it logs any rejected
or dropped packet, but we didn't find this entry, so I think
there isn't rule which drops the packet.

The all we see is the following:
Jan 11 14:53:14 localhost kernel: MASQUERADE: Route sent us somewhere else.

What is this message means? How can I debug more precisely?
What manual I need to read?

Thanks in advance,
Szabolcs Horvath

Re: MASQUERADE: Route sent us somewhere else

[Jason Opperisano]

On Tue, 2005-01-11 at 08:48, Horváth Szabolcs wrote:
> Hello!
> 
> We have a firewall, and it's inside many UML's.
> I can't establish new connections from UML, kernel log says
> "MASQUERADE: Route sent us somewhere else".

this is basically a known issue with policy routing + MASQUERADE.

possible work-arounds:

- use SNAT instead of MASQ (if you have static IPs you should be doing
this anyway)
- use ROUTE to force the --oif (messy)

try an untested patch:

http://marc.theaimsgroup.com/?l=netfilter-devel&m=109866543308978&w=2

please refer to the following thread from netfilter-devel for more
details:

http://marc.theaimsgroup.com/?t=109389731400005&r=2&w=2


--
"Okay, retrace your steps. Woke up, fought with Marge, ate Guatemalan
 insanity peppers, then I... Oh..."
	--The Simpsons

MASQUERADE: Route sent us somewhere else.

[Tim Evans]

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/	|