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

[Mike Wright <mike.wright@mailinator.com>]

Data Shock wrote:
>> * 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
>

Hi Frank,

I'm not certain about the meaning of "implicit source local NAT" but the 
second rule may be the culprit.  Rather than imply 127.1 perhaps the 
rule needs to specifically mention the source IP:  e.g.

-A OUTPUT -s 127.0.0.1 -p udp -mudp --dport 1234 -j sendtolocal

Out of curiosity, does the following work and not produce an error?

*nat
-A PREROUTING -p udp --dport 1234 -j DNAT --to-destination 127.0.0.1
-A POSTROUTING -p udp --sport 1234 -j SNAT --to-source 10.1.2.3

Please reply on list.  My subscribed email address is a throw-away.

:m)

>  
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>