"NAT redirection", or NAT from inside to inside?

"NAT redirection", or NAT from inside to inside?

[Philipp Periventas]

Hello there,

I've got a server, running two virtual machines on it. The server
itself serves as router. I forwarded some ports, among port 80 to one
of the machines. The port forwarding works fine from the outside (from
the WAN, e.g. my computer at home) - but what doesn't work is the
access to the forwarded port 80 from INSIDE using my external IP. That
means, when I try to use lynx from my webserver, and enter the
external IP, it says connection refused.

I tried to rebuild the problem with my own home linksys router, but it
worked! Then I found an option called "Filter Internet NAT
Redirection" in my linksys webinterface, and after activating that, it
didnt work any longer.

Finally, I'm looking for the iptables command(s) which offer exactly
the same features as my linksys router does - permitting LAN-clients
to access LAN-services by using the EXTERNAL ip of the router.

Has anyone an idea how to resolve this "problem"?

Thanks in advance

Re: "NAT redirection", or NAT from inside to inside?

[Grant Taylor]

On 8/14/2008 4:17 AM, Philipp Periventas wrote:
> I've got a server, running two virtual machines on it. The server 
> itself serves as router. I forwarded some ports, among port 80 to one 
> of the machines. The port forwarding works fine from the outside 
> (from the WAN, e.g. my computer at home) - but what doesn't work is 
> the access to the forwarded port 80 from INSIDE using my external IP. 
> That means, when I try to use lynx from my webserver, and enter the 
> external IP, it says connection refused.

*nod*  I (loosely) refer to this a "looping through its self" type of 
problem.

/Usually/ port forwarding is associated with the incoming interface and 
the destination IP.  So, when you have traffic coming in (to the NATing 
config) from the WAN the external interface is matched everything works 
fine.  However when you have traffic coming in (to the NATing config) 
from the LAN the external interface is not matched and as such NATing is 
not done.  Thus you end up with traffic coming in to your router that is 
not DNATed any where and thus coming directly in to the router which 
does not have any thing listening on it.

To work around this, you will need to either not care about the incoming 
interface, or handle each incoming interface appropriately.  You can not 
care by removing the interface portion of your DNAT rule.  However when 
you do this, you will DNAT any traffic destined to your external IP over 
to an internal system.  The problem is that when you are DNATing 
internal traffic to an internal host, the internal host will reply 
directly back to the original internal client.  This may seem ok, but 
the internal host will reply with it's internal IP as its the source IP 
of the packet, which is not what the original client is expecting.

You can get around this "TCP Triangle" (as I and others call it) by 
SNATing traffic before it is DNATed to the internal host.  However I'm 
betting that you do not want to SNAT your external requests.  So, this 
is why I say handle your internal and external DNATing separately.  Have 
the external requests DNATed to the internal host as they are and have 
your internal requests DNATed to the internal host and SNATed to the 
internal IP of the NATing router.  By SNATing your internal traffic the 
internal host will see the traffic as coming from the router and will 
reply there which will allow the router to unDNAT the traffic and send 
it back to the original internal client.

You may be able to get away using a common DNATing rule (in the 
PREROUTING chain) that does not match any interfaces while using a 
SNATing rule (in the POSTROUTING chain) that will SNAT any traffic that 
is both from and to the internal network.  This way any traffic that 
comes into the router from the local LAN that is redirected back out to 
the local LAN will pass back through the router on its return trip back 
to the original client.

> I tried to rebuild the problem with my own home linksys router, but 
> it worked! Then I found an option called "Filter Internet NAT 
> Redirection" in my linksys webinterface, and after activating that, 
> it didnt work any longer.

I wonder if the Linksys router is SNATing / MASQUERADing any traffic 
from the LAN that is being DNATed back to the LAN.  This rule would be 
based on source and destination IP.  If this rule is not based on the 
interface, it would be trivial to spoof IPs on traffic coming in the 
external interface and thus potentially be an exploit vector, thus we 
would want to have the option to filter this type of spoofing.  I'm not 
quite sure how they came up with the name "Filter Internet NAT 
Redirection", unless it means to apply the NAT rules in such a way as 
they do care what interface they come in on.

> Finally, I'm looking for the iptables command(s) which offer exactly 
> the same features as my linksys router does - permitting LAN-clients 
> to access LAN-services by using the EXTERNAL ip of the router.

I don't have a way to test this at the moment, but I believe the 
following two types of rules would do what you are wanting to do.

    iptables -t nat -A PREROUTING -d $WAN_IP -p TCP --dport 80 -j DNAT 
--to-destination $Internal_Server:80

and

    iptables -t nat -A POSTROUTING -s $LAN -d $LAN -j SNAT --to-source 
$LAN_IP

or

    iptables -t nat -A POSTROUTING -s $LAN -d $LAN -j MASQUERADE

> Has anyone an idea how to resolve this "problem"?

Again, I /think/ I understand what the problem is but I'm not 100% 
positive.  Also I don't currently have a way to test this.  (Do to "Life 
Happening" I'm currently using $hit-sco routers for my NATing needs. 
Yes I'm sorry for it too.)

> Thanks in advance

*nod*

You are welcome.



Grant. . . .

Re: "NAT redirection", or NAT from inside to inside?

[Philipp Periventas]

Hello Grant,

thank you very much for your mail and your effort! I finally solved  
the problem with exactly the commands you wrote in your mail, plus a  
command for letting the firewall itself getting access to the  
webserver by manipulating the NAT output chain. I found this advice on  
the website http://iptables-tutorial.frozentux.net/chunkyhtml/ 
x4033.html - unfortunately, I found it a bit too late!

The website also addresses the problem with "manipulated logs" - but I  
guess by defining a source LAN address (like you did) I can live with  
this constraint...

Damn! There should be special term for this kind of stupid - yet easy  
to solve problem, because I was looking and asking for about a whole  
week in forums, irc channels and so on...

So, over again, thanks!


On Aug 15, 2008, at 3:12 AM, Grant Taylor wrote:

> On 8/14/2008 4:17 AM, Philipp Periventas wrote:
>> I've got a server, running two virtual machines on it. The server  
>> itself serves as router. I forwarded some ports, among port 80 to  
>> one of the machines. The port forwarding works fine from the  
>> outside (from the WAN, e.g. my computer at home) - but what doesn't  
>> work is the access to the forwarded port 80 from INSIDE using my  
>> external IP. That means, when I try to use lynx from my webserver,  
>> and enter the external IP, it says connection refused.
>
> *nod*  I (loosely) refer to this a "looping through its self" type  
> of problem.
>
> /Usually/ port forwarding is associated with the incoming interface  
> and the destination IP.  So, when you have traffic coming in (to the  
> NATing config) from the WAN the external interface is matched  
> everything works fine.  However when you have traffic coming in (to  
> the NATing config) from the LAN the external interface is not  
> matched and as such NATing is not done.  Thus you end up with  
> traffic coming in to your router that is not DNATed any where and  
> thus coming directly in to the router which does not have any thing  
> listening on it.
>
> To work around this, you will need to either not care about the  
> incoming interface, or handle each incoming interface  
> appropriately.  You can not care by removing the interface portion  
> of your DNAT rule.  However when you do this, you will DNAT any  
> traffic destined to your external IP over to an internal system.   
> The problem is that when you are DNATing internal traffic to an  
> internal host, the internal host will reply directly back to the  
> original internal client.  This may seem ok, but the internal host  
> will reply with it's internal IP as its the source IP of the packet,  
> which is not what the original client is expecting.
>
> You can get around this "TCP Triangle" (as I and others call it) by  
> SNATing traffic before it is DNATed to the internal host.  However  
> I'm betting that you do not want to SNAT your external requests.   
> So, this is why I say handle your internal and external DNATing  
> separately.  Have the external requests DNATed to the internal host  
> as they are and have your internal requests DNATed to the internal  
> host and SNATed to the internal IP of the NATing router.  By SNATing  
> your internal traffic the internal host will see the traffic as  
> coming from the router and will reply there which will allow the  
> router to unDNAT the traffic and send it back to the original  
> internal client.
>
> You may be able to get away using a common DNATing rule (in the  
> PREROUTING chain) that does not match any interfaces while using a  
> SNATing rule (in the POSTROUTING chain) that will SNAT any traffic  
> that is both from and to the internal network.  This way any traffic  
> that comes into the router from the local LAN that is redirected  
> back out to the local LAN will pass back through the router on its  
> return trip back to the original client.
>
>> I tried to rebuild the problem with my own home linksys router, but  
>> it worked! Then I found an option called "Filter Internet NAT  
>> Redirection" in my linksys webinterface, and after activating that,  
>> it didnt work any longer.
>
> I wonder if the Linksys router is SNATing / MASQUERADing any traffic  
> from the LAN that is being DNATed back to the LAN.  This rule would  
> be based on source and destination IP.  If this rule is not based on  
> the interface, it would be trivial to spoof IPs on traffic coming in  
> the external interface and thus potentially be an exploit vector,  
> thus we would want to have the option to filter this type of  
> spoofing.  I'm not quite sure how they came up with the name "Filter  
> Internet NAT Redirection", unless it means to apply the NAT rules in  
> such a way as they do care what interface they come in on.
>
>> Finally, I'm looking for the iptables command(s) which offer  
>> exactly the same features as my linksys router does - permitting  
>> LAN-clients to access LAN-services by using the EXTERNAL ip of the  
>> router.
>
> I don't have a way to test this at the moment, but I believe the  
> following two types of rules would do what you are wanting to do.
>
>   iptables -t nat -A PREROUTING -d $WAN_IP -p TCP --dport 80 -j DNAT  
> --to-destination $Internal_Server:80
>
> and
>
>   iptables -t nat -A POSTROUTING -s $LAN -d $LAN -j SNAT --to-source  
> $LAN_IP
>
> or
>
>   iptables -t nat -A POSTROUTING -s $LAN -d $LAN -j MASQUERADE
>
>> Has anyone an idea how to resolve this "problem"?
>
> Again, I /think/ I understand what the problem is but I'm not 100%  
> positive.  Also I don't currently have a way to test this.  (Do to  
> "Life Happening" I'm currently using $hit-sco routers for my NATing  
> needs. Yes I'm sorry for it too.)
>
>> Thanks in advance
>
> *nod*
>
> You are welcome.
>
>
>
> Grant. . . .
> --
> 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: "NAT redirection", or NAT from inside to inside?

[Grant Taylor]

On 08/15/08 05:31, Philipp Periventas wrote:
> Hello Grant,

Morning.

> thank you very much for your mail and your effort! I finally solved the 
> problem with exactly the commands you wrote in your mail, plus a command 
> for letting the firewall itself getting access to the webserver by 
> manipulating the NAT output chain. I found this advice on the website 
> http://iptables-tutorial.frozentux.net/chunkyhtml/x4033.html - 
> unfortunately, I found it a bit too late!

*nod*

I'm glad that what I suggested worked as I had not had a chance to try 
it my self.

I *always* forget about the firewall its self being able to access 
things as I so seldom need it to be able to do so.

> The website also addresses the problem with "manipulated logs" - but I 
> guess by defining a source LAN address (like you did) I can live with 
> this constraint...

Yes.  I think who ever wrote that web page was working through things 
evolutionary (at least that's how it reads to me) and solved their 
problems as they came to them.  A simple TCPDump of unSNATed connections 
will show the problem which would prompt an SNAT rule.  After that 
looking at logs on the web server would it become obvious that you don't 
want to SNAT everything, just the LAN traffic.  This is one of the 
*many* reasons why having a DMZ be on a separate subnet is such a good ting.

> Damn! There should be special term for this kind of stupid - yet easy to 
> solve problem, because I was looking and asking for about a whole week 
> in forums, irc channels and so on...

Eh.  Most firewalling documentation is written around the idea that both 
the request and reply packets pass through the firewall (as opposed to 
some other route) and really one set of query / reply packets at that. 
When you start getting in to more complex things where the traffic might 
or might not pass through the firewall or you may want to deal with 
different IP addresses in subsequent query / reply sets or even 
different source / dest IPs in the query and reply (see the recent 
thread on SNMP and CUPS printing) the amount of documentation drops off 
and your need to truly understand what the packets are doing goes way 
up.  Try throwing hardware (switches) in there that do not like seeing 
the same MAC address on multiple VLANs and have to work around that...

> So, over again, thanks!

*nod*

You are quite welcome.  I'm glad that my ramblings helped.



Grant. . . .