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

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

[Data Shock]

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
_________________________________________________________________
Windows Live™ Contacts: Organize your contact list. 
http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009

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

[Jonathan Knight]

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

Is it that it can't send to 127.0.0.1 or is it the loopback interface 
that's the problem?

If it's just the IP number then you could use a stub host on a 
non-routed network.  I.e.

ifconfig lo\:1 10.1.1.1 netmask 255.255.255.255 up

Now, if you can get your Receiver to listen to all the interfaces 
including the lo:1 interface and you can get your Sender to talk to 
10.1.1.1 then you don't need to use NAT at all.


Jon.

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

[Data Shock]

Thank you for the reply Jon.  I didn't expect any replies so soon.  :)


> Is it that it can't send to 127.0.0.1 or is it the loopback interface
> that's the problem?


Well, actually, the Sender program refuses to send to "itself", so it won't use any address on the device.  I appologize, I should have been more specific about that.


I really would LOVE to get an answer to the actual iptables issue.  There seems to be no real information on this, so I'm hoping that this thread will lead to some conclusive information.

For the sake of this thread, lets assume that iptables is the only solution.  Assuming that, and given my iptables configuration, what is the reason for the error message? And how can I correct it?

Many thanks,

Frank

_________________________________________________________________
Express your personality in color! Preview and select themes for Hotmail®. 
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme

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

[Data Shock]

* bump *



Is this perhaps a bug?  If the rule is valid, then no message should be
output like that.  This is akin to giving a warning ticket for
speeding just as I pull out of the garage.



Does this message still appear in newer versions?  I don't have
permission myself to update iptables on the server in question, but if
I know a later version fixes this, then I might be able to request an
update.



Thanks,



Frank
_________________________________________________________________
Express your personality in color! Preview and select themes for Hotmail®.
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme

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

[Data Shock]

* 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.

_________________________________________________________________
Rediscover Hotmail®: Get quick friend updates right in your inbox. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009

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

[Data Shock]

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

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

[Mike Wright]

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

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

[Data Shock]

Hi Mike,

Thank you for the reply.  I have added my comments into your message.


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


Unfortunately, that won't work because the source address at this point in the chain is not actually 127.0.0.1, but an outside interface, so it won't match the rule.  I did try replacing "127.0.0.1" in your suggested rule with the external interface, and that did function.  However I still see the message "NAT: no longer support implicit source local NAT" in /var/log/messages.


That error message (warning, friendly reminder, nagging pain in the fanny?) actually seems to happen the first time the "sendtolocal" chain is traversed.  It doesn't seem to be about matching the source address.  It seems to be complaining about changing the destination address without changing the source address.  However, I have a POSTROUTING rule that does the SNAT.  If I could SNAT from an OUTPUT chain I would, but that's not allowed.  SNAT has to be in the POSTROUTING chain.

I believe it is complaining about something a later chain is about to do anyway.  It's like a preemptive nag, assuming you are going to mess up.  Since you can't SNAT in the OUTPUT chain, how the heck can I get around this?


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


The first PREROUTING rule won't match because the packets are generated locally, and thus don't traverse the PREROUTING chain.  It must be a rule on the OUTPUT chain.

The second rule doesn't really make a difference.  I get this error message if that rule is there, not there at all, or if there is one like my original (which SNATed to 127.0.0.1).



I really appreciate the response Mike.  I'm beginning to lean towards entering a bug for this.

Perhaps our comments will help to get the conversation going.  :)


-Frank


_________________________________________________________________
Quick access to your favorite MSN content and Windows Live with Internet Explorer 8. 
http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A

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

[Mart Frauenlob]

netfilter-owner@vger.kernel.org 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
>  
>  
> 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
>
>   
Hello,

I'm not 100% sure, but maybe the REDIRECT target is of use for that 
particular case:

from `man iptables':

   REDIRECT
       This  target  is  only  valid  in the nat table, in the 
PREROUTING and OUTPUT chains, and user-defined chains which are only 
called from those chains.  It
       redirects the packet to the machine itself by changing the 
destination IP to the primary address of the incoming interface 
(locally-generated packets  are
       mapped to the 127.0.0.1 address).  It takes one option:

       --to-ports port[-port]
              This  specifies  a  destination port or range of ports to 
use: without this, the destination port is never altered.  This is only 
valid if the rule
              also specifies -p tcp or -p udp.


Greets

Mart

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

[Data Shock]

Hot diggity!  Thanks Mart.

This seems to be the solution.

I replaced the nat rule:

-A sendtolocal -d 10.1.2.3 -j DNAT --to-destination 127.0.0.1


with:

-A sendtolocal -d 10.1.2.3 -j REDIRECT


and that did it.  WooHoo!  It seems so simple now.  Why didn't I find that? :)

I'll experiment some more with this approach and then try it with our live system.  I'll report back with the final verdict.


FYI:  I tried this on an older Linux box too (with iptables v1.2.8) and found that it automatically SNATed the packet to 127.0.0.1.  However on my newer box (with iptables v1.3.5), it didn't SNAT the packet.  Its source remained the external interface of the box.  Interesting...


Thanks,

-Frank


>
> I'm not 100% sure, but maybe the REDIRECT target is of use for that
> particular case:
>
> from `man iptables':
>
> REDIRECT
> This target is only valid in the nat table, in the
> PREROUTING and OUTPUT chains, and user-defined chains which are only
> called from those chains. It
> redirects the packet to the machine itself by changing the
> destination IP to the primary address of the incoming interface
> (locally-generated packets are
> mapped to the 127.0.0.1 address). It takes one option:
>
> --to-ports port[-port]
> This specifies a destination port or range of ports to
> use: without this, the destination port is never altered. This is only
> valid if the rule
> also specifies -p tcp or -p udp.
>
>
> Greets
>
> Mart


_________________________________________________________________
Rediscover Hotmail®: Get quick friend updates right in your inbox. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009

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

[Data Shock]

I have now had a chance to exercise this new iptable rule, and it has worked out well.  I no longer see the strange error message.

It is unfortunate that nobody seems to know why this message is there, or really what it means.  However, I'm past the message now and I'm happy with the solution that Mart provided.

Many thanks to all.

-Frank


----------------------------------------
> Hot diggity! Thanks Mart.
>
> This seems to be the solution.
>
> I replaced the nat rule:
>
> -A sendtolocal -d 10.1.2.3 -j DNAT --to-destination 127.0.0.1
>
>
> with:
>
> -A sendtolocal -d 10.1.2.3 -j REDIRECT
>
>
> and that did it. WooHoo! It seems so simple now. Why didn't I find that? :)
>
> I'll experiment some more with this approach and then try it with our live system. I'll report back with the final verdict.
>
>
> FYI: I tried this on an older Linux box too (with iptables v1.2.8) and found that it automatically SNATed the packet to 127.0.0.1. However on my newer box (with iptables v1.3.5), it didn't SNAT the packet. Its source remained the external interface of the box. Interesting...
>
>
> Thanks,
>
> -Frank
>
>
>>
>> I'm not 100% sure, but maybe the REDIRECT target is of use for that
>> particular case:
>>
>> from `man iptables':
>>
>> REDIRECT
>> This target is only valid in the nat table, in the
>> PREROUTING and OUTPUT chains, and user-defined chains which are only
>> called from those chains. It
>> redirects the packet to the machine itself by changing the
>> destination IP to the primary address of the incoming interface
>> (locally-generated packets are
>> mapped to the 127.0.0.1 address). It takes one option:
>>
>> --to-ports port[-port]
>> This specifies a destination port or range of ports to
>> use: without this, the destination port is never altered. This is only
>> valid if the rule
>> also specifies -p tcp or -p udp.
>>
>>
>> Greets
>>
>> Mart

_________________________________________________________________
Rediscover Hotmail®: Get quick friend updates right in your inbox. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates2_042009

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

[Pascal Hambourg]

Hello,

Data Shock a écrit :
> 
> It is unfortunate that nobody seems to know why this message is there,
> or really what it means.

It is just a warning and remainder. As you saw, it would occur at most 
once after the DNAT module is loaded. So I do not understand why so much 
complain for a message happening mostly once a boot at most.

In 2.4 kernels and 2.6 kernels older that 2.6.11, the DNAT target used 
to implicitly change the source address to reflect the new output 
interface. Kernels 2.6.11 and above do not do it any more, possibliy 
causing a loss of connectivy in some special cases. This is the reason 
of this message, giving the opportunity to add an explicit SNAT rule 
when required. The given reason for removing explicit source NAT is that 
the submitter believed it was not strictly necessary.

The REDIRECT target never changed the source address, so it does not 
produce the message.

Note that it should not be necessary to explicitly change the source 
address with a SNAT rule anyway. Don't you have too restrictive 
filtering rules on the loopback interface ?