Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Kapetanakis Giannis <bilias@edu.physics.uoc.gr>
To: netfilter@vger.kernel.org
Subject: Re: NAT overlaps with ports
Date: Wed, 23 Sep 2009 14:14:49 +0300	[thread overview]
Message-ID: <4ABA0329.70102@edu.physics.uoc.gr> (raw)
In-Reply-To: <4AB9FC72.9000906@plouf.fr.eu.org>

On 23/09/09 13:46, Pascal Hambourg wrote:
> This IP range is private, not public.
> If you made it up, please use the 192.0.2.0/24 range reserved for
> examples and documentation instead.
>    
Yes I made it up.
>> 10.0.0.0/24 is my private IP range (eth1)
>> 192.168.1.1 public IP of server
>> 10.0.0.1 private IP of server
>>
>> I'd like to add the following rules in the nat table:
>>
>> [1] -A PREROUTING -i eth0 -d 192.168.1.1 -p tcp --dport 8080 -j DNAT
>> --to-destination 10.0.0.1:8080
>> [2] -A POSTROUTING -o eth0 -s 10.0.0.1 -p tcp --sport 8080 -j SNAT
>> --to-source 192.168.1.1:8080
>> [3] -A POSTROUTING -o eth0 -s 10.0.0.0/24 --to-source
>> 192.168.1.1-192.168.1.10
>>      
> Rule [2] is pointless. Packets with source port 8080 are obviously
> replies, and Netfilter NAT implicitly takes care of reply packets
> packets. Actually, the 'nat' chains don't even see reply packets.
>    
You're right, I will remove it.
>> According to http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html
>> iptables is clever enough to avoid overlaps and clashes.
>> Are we sure that there isn't any chance to map a random packet (not from
>> the server)
>> to 192.168.1.1:8080 in rule [3]?
>>      
> No. That could happen as long as it does not create a collision with an
> existing mapping. Why do you worry about it ?
> The important point is that netfilter avoids collisions between existing
> NAT mappings. Rules do not create mappings by themselves, a mapping is
> created only for each new connection created by a packet.
>    

What I'm worried of is than a random connection could be created which uses
the mapping of port 8080 of 192.168.1.1 and then the internal server 
would not be available.
But I guess this is not a problem since a connection has 4 parameters 
src/dst ip/port.

thanks for answering

Giannis



  reply	other threads:[~2009-09-23 11:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-23  9:51 NAT overlaps with ports Kapetanakis Giannis
2009-09-23 10:46 ` Pascal Hambourg
2009-09-23 11:14   ` Kapetanakis Giannis [this message]
2009-09-23 13:45     ` Pascal Hambourg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ABA0329.70102@edu.physics.uoc.gr \
    --to=bilias@edu.physics.uoc.gr \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox