RE: iptables - Trying to understand "no longer support implicit source local NAT"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> * bump *
>
> There must be someone out there who knows why this message is written out. Have I sent this inquiry to the correct list? Should I send this to the devel list instead?
>
> Perhaps I should submit this as a bug.
 
 
My apologies.  It would appear that I either goofed my e-mail somehow or threads don't survive the transition from one month to the next (this question is 2.5 weeks old now).
 
Here is the content of my original question:
 
 
-----
List:       netfilter
Subject:    iptables - Trying to understand "no longer support implicit source
From:       Data Shock 
Date:       2009-03-19 19:43:03
Message-ID: BLU149-W20F12BA9B98E9D4E82C7CBA3960 () phx ! gbl
-----
 
Hello,
 
I have been trying to understand a new error message I've been seeing
since I updated to a new version of Linux.  The message is:  "kernel:
NAT: no longer support implicit source local NAT".  It shows up once in
/var/log/messages, and on my console screen, when the offending rule is
used for the first time.
 
I've had a heck of a time trying to
find any information at all about this change.  I can't seem to find
any definitive post/thread about the reason for the change and what to
do about the message.  I've searched the mail archives, the
documentation, and googled for hours.
 
Here is my situation:
 
My linux box has a finicky program (let's call it the "Sender") on it that
refuses to send to 127.0.0.1.  However, I have another program running
on that same box that needs to receive the UDP traffic from the
Sender.  We'll call that one the "Receiver".  These two programs must
reside on the same device.
 
So to get around this software quirk,
the Sender is configured with a bogus destination address.  I then have
the following iptables NAT rules to dnat the UDP packets to the local
address:
 
*nat
-A POSTROUTING -d 127.0.0.1 -p udp -m udp --dport 1234 -j SNAT --to-source 127.0.0.1
-A OUTPUT -p udp -m udp --dport 1234 -j sendtolocal
-A sendtolocal -d 10.1.2.3 -j DNAT --to-destination 127.0.0.1
 
 
A few notes:
1) The "sendtolocal" chain was made for ease of modifying the DNAT rule
programatically since the bogus address can change at any time.  (The
whole chain can be cleared and a new rule added in its place).
2) I am explicitly SNAT-ing the packet to 127.0.0.1 (it gets discarded otherwise)
3) The bogus address in this example is 10.1.2.3
4) The communication is one way, so the Sender does not expect replies from the Receiver.
 
 
This set up worked fine previously, and curiously, still seems to work fine despite the error message.
 
>From what I've read, I'm guessing that iptables complains when the source
address of the original packet doesn't match the address that will be
used to route the packet to its new destination.  That's fine, but I'm
SNAT-ing it myself.  Is it really necessary to spit out a message like
that when no actual error occured?  I'm sure I'm missing something here.
 
So the questions are:
1) What the heck was the actual reason and impact of the change?
2) What can I do to stop the error message?
3) Am I actually doing anything wrong with my rules?
 
I sure hope someone can help me.
 
 
Many thanks,
 
Frank
_________________________________________________________________
Rediscover Hotmail®: Now available on your iPhone or BlackBerry
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Mobile1_042009--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux