simple nat question

simple nat question

[Ben]

I've got a basic nat setup:

  internet
     |
+====+=====+ eth0: 1.2.3.4
| firewall |
+====+=====+ eth1: 10.0.0.1
     |
+====+=====+ eth0: 10.0.0.2
|  server  |
+==========+


What I would like is for packets coming from the server (10.0.0.2) to get
SNAT'd to the firewall's IP address, 1.2.3.4. It seems easy enough to do:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.2 -j SNAT --to 1.2.3.4

But now I don't see how return packets are going to make it back to my
server, because the firewall is going to think they are destined for it.
If I add the rule:

iptables -t nat -A PREROUTING -d 1.2.3.4 -i ! eth0 -j DNAT --to 10.0.0.2

Then it seems I loose the ability for the firewall to run anything
accessable to the outside world, like ssh.

Re: simple nat question

[Antony Stone]

On Tuesday 02 July 2002 8:34 pm, Ben wrote:

> I've got a basic nat setup:
>
>   internet
> +====+=====+ eth0: 1.2.3.4
> | firewall |
> +====+=====+ eth1: 10.0.0.1
>
> +====+=====+ eth0: 10.0.0.2
> |  server  |
> +==========+
>
> What I would like is for packets coming from the server (10.0.0.2) to get
> SNAT'd to the firewall's IP address, 1.2.3.4. It seems easy enough to do:
>
> iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.2 -j SNAT --to 1.2.3.4
>
> But now I don't see how return packets are going to make it back to my
> server, because the firewall is going to think they are destined for it.

You forget that there is magic inside netfilter :-)

Just use the above rule (along with the appropriate FORWARD rules for 
server-bound requests and internet-bound replies), and it will all work 
wonderfully :-)

> If I add the rule:
>
> iptables -t nat -A PREROUTING -d 1.2.3.4 -i ! eth0 -j DNAT --to 10.0.0.2
>
> Then it seems I lose the ability for the firewall to run anything
> accessable to the outside world, like ssh.

Yes, you are correct, so do not add the above rule :-)

 

Okay, for a more serious answer....

You are thinking only about IP addresses, and forgetting about port numbers.

The firewall can use the port numbers to identify which incoming packets from 
the Internet are responses to packets it previously translated from the 
server, and it will automatically translate these replies back to the server; 
however any other packets with port numbers which do not correspond to 
previously sent packets do not get automagically translated, and therefore 
terminate on the firewall (eg SSH).

You never normally need to include the second rule you've written unless you 
really do want all packets for IP 1.2.3.4 to be sent on to 10.0.0.2 - in most 
cases you only want this to happen for a few special port numbers (eg TCP 
port 80 if the server is a web server, TCP port 25 is it's a mail server, UDP 
& TCP ports 53 if it's a DNS server, etc).

Therefore I suggest you use something like the following rules (I am assuming 
for this example that the server is a web server running http and not https):

iptables -A PREROUTING -t nat -d 1.2.3.4 -p tcp --dport 80 -i eth0 -j DNAT 
--to 10.0.0.2
iptables -A FORWARD -p tcp--dport 80 -d 10.0.0.2 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -s 10.0.0.2 -o eth0 -j SNAT --to 1.2.3.4

Then if you want to allow SSH to the firewall itself:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

(it would be good to add a -s a.b.c.d option to this if you can restrict the 
source address range you will be SSHing from)

 

Antony.

Re: simple nat question

[Jan Humme]

Ain't this what masquerading is all about?

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Jan Humme.


On Tuesday 02 July 2002 21:55, Antony Stone wrote:
> On Tuesday 02 July 2002 8:34 pm, Ben wrote:
> > I've got a basic nat setup:
> >
> >   internet
> > +====+=====+ eth0: 1.2.3.4
> >
> > | firewall |
> >
> > +====+=====+ eth1: 10.0.0.1
> >
> > +====+=====+ eth0: 10.0.0.2
> >
> > |  server  |
> >
> > +==========+
> >
> > What I would like is for packets coming from the server (10.0.0.2) to get
> > SNAT'd to the firewall's IP address, 1.2.3.4. It seems easy enough to do:
> >
> > iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.2 -j SNAT --to 1.2.3.4
> >
> > But now I don't see how return packets are going to make it back to my
> > server, because the firewall is going to think they are destined for it.
>
> You forget that there is magic inside netfilter :-)
>
> Just use the above rule (along with the appropriate FORWARD rules for
> server-bound requests and internet-bound replies), and it will all work
> wonderfully :-)
>
> > If I add the rule:
> >
> > iptables -t nat -A PREROUTING -d 1.2.3.4 -i ! eth0 -j DNAT --to 10.0.0.2
> >
> > Then it seems I lose the ability for the firewall to run anything
> > accessable to the outside world, like ssh.
>
> Yes, you are correct, so do not add the above rule :-)
>
>
>
> Okay, for a more serious answer....
>
> You are thinking only about IP addresses, and forgetting about port
> numbers.
>
> The firewall can use the port numbers to identify which incoming packets
> from the Internet are responses to packets it previously translated from
> the server, and it will automatically translate these replies back to the
> server; however any other packets with port numbers which do not correspond
> to previously sent packets do not get automagically translated, and
> therefore terminate on the firewall (eg SSH).
>
> You never normally need to include the second rule you've written unless
> you really do want all packets for IP 1.2.3.4 to be sent on to 10.0.0.2 -
> in most cases you only want this to happen for a few special port numbers
> (eg TCP port 80 if the server is a web server, TCP port 25 is it's a mail
> server, UDP & TCP ports 53 if it's a DNS server, etc).
>
> Therefore I suggest you use something like the following rules (I am
> assuming for this example that the server is a web server running http and
> not https):
>
> iptables -A PREROUTING -t nat -d 1.2.3.4 -p tcp --dport 80 -i eth0 -j DNAT
> --to 10.0.0.2
> iptables -A FORWARD -p tcp--dport 80 -d 10.0.0.2 -j ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A POSTROUTING -t nat -s 10.0.0.2 -o eth0 -j SNAT --to 1.2.3.4
>
> Then if you want to allow SSH to the firewall itself:
>
> iptables -A INPUT -p tcp --dport 22 -j ACCEPT
>
> (it would be good to add a -s a.b.c.d option to this if you can restrict
> the source address range you will be SSHing from)
>
>
>
> Antony.

Re: simple nat question

[Antony Stone]

On Tuesday 02 July 2002 9:13 pm, Jan Humme wrote:

> Ain't this what masquerading is all about?
>
> # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Are you asking about the difference between MASQUERADE and SNAT ?

If so, the answer's not a lot, except:

1. MASQUERADE checks the address of the interface for each packet it 
translates, therefore it's better for interfaces with dynamic addresses.

2. MASQUERADE checks the address of the interface for each packet it 
translates, therefore it's slightly less efficient for interfaces with static 
addresses.

 

Antony.

Re: simple nat question

[Jan Humme]

On Tuesday 02 July 2002 22:18, Antony Stone wrote:
> On Tuesday 02 July 2002 9:13 pm, Jan Humme wrote:
> > Ain't this what masquerading is all about?
> >
> > # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> Are you asking about the difference between MASQUERADE and SNAT ?

No, I just wanted to point out that masquerading provides an easy way to get 
the desired results.


> If so, the answer's not a lot, except:
>
> 1. MASQUERADE checks the address of the interface for each packet it
> translates, therefore it's better for interfaces with dynamic addresses.
>
> 2. MASQUERADE checks the address of the interface for each packet it
> translates, therefore it's slightly less efficient for interfaces with
> static addresses.

Hey! I didn't realize that, thank you.

On the other hand, taking into consideration the elegance of a one-line 
masquerading rule (one test) vs. your 4-line solution (more tests), would you 
still argue that a masquerading solution is less efficient?

Jan Humme.

Re: simple nat question

[Ben]

On Tue, 2 Jul 2002, Jan Humme wrote:

> No, I just wanted to point out that masquerading provides an easy way to get
> the desired results.

It does, true, but the howto recommends not using MASQ for static IPs. If
I had just done what told me what to do instead of worrying about problems
that didn't exist, I wouldn't have had to post this question to begin
with. :)

> On the other hand, taking into consideration the elegance of a one-line
> masquerading rule (one test) vs. your 4-line solution (more tests), would you
> still argue that a masquerading solution is less efficient?

Without a doubt, the (slightly) faster, (slightly) more complex solution
is better. It takes all of 30 minutes (if you're easily distracted) to get
this part of your firewall up and running, but it'll route packets for
months using the rules you choose.

Re: simple nat question

[Antony Stone]

On Tuesday 02 July 2002 9:51 pm, Ben wrote:

> On Tue, 2 Jul 2002, Jan Humme wrote:
> > No, I just wanted to point out that masquerading provides an easy way to
> > get the desired results.
>
> It does, true, but the howto recommends not using MASQ for static IPs. If
> I had just done what told me what to do instead of worrying about problems
> that didn't exist, I wouldn't have had to post this question to begin
> with. :)

Masquerading will do almost all you want for machines on an internal network 
making contact with the Internet (ie outbound-initiated traffic), but you 
will always need specific DNAT rules if you are running a server on the 
internal network (ie Internet-initiated traffic).

 

Antony.

Re: simple nat question

[Jan Humme]

On Tuesday 02 July 2002 22:58, Antony Stone wrote:
> On Tuesday 02 July 2002 9:51 pm, Ben wrote:
> > On Tue, 2 Jul 2002, Jan Humme wrote:
> > > No, I just wanted to point out that masquerading provides an easy way
> > > to get the desired results.
> >
> > It does, true, but the howto recommends not using MASQ for static IPs. If
> > I had just done what told me what to do instead of worrying about
> > problems that didn't exist, I wouldn't have had to post this question to
> > begin with. :)
>
> Masquerading will do almost all you want for machines on an internal
> network making contact with the Internet (ie outbound-initiated traffic),
> but you will always need specific DNAT rules if you are running a server on
> the internal network (ie Internet-initiated traffic).

Of course, you are absolutely right; my reply was too quick !

Jan Humme.

Re: simple nat question

[Antony Stone]

On Tuesday 02 July 2002 9:47 pm, Jan Humme wrote:

> On Tuesday 02 July 2002 22:18, Antony Stone wrote:
> > On Tuesday 02 July 2002 9:13 pm, Jan Humme wrote:
> > > Ain't this what masquerading is all about?
> > >
> > > # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> >
> > 1. MASQUERADE checks the address of the interface for each packet it
> > translates, therefore it's better for interfaces with dynamic addresses.
> >
> > 2. MASQUERADE checks the address of the interface for each packet it
> > translates, therefore it's slightly less efficient for interfaces with
> > static addresses.
>
> On the other hand, taking into consideration the elegance of a one-line
> masquerading rule (one test) vs. your 4-line solution (more tests), would
> you still argue that a masquerading solution is less efficient?

Masquerading is slightly less efficient for every single packet which goes 
through the machine.

Anyway, the masquerading rule only substitutes for the SNAT rule - the other 
three I proposed are still needed.

 

Antony

Re: simple nat question

[Ben]

Thanks for the quick responses! This worked perfectly... I hadn't realized
that DNAT would also handle the return path.

On Tue, 2 Jul 2002, Antony Stone wrote:

> On Tuesday 02 July 2002 8:34 pm, Ben wrote:
>
> > I've got a basic nat setup:
> >
> >   internet
> > +====+=====+ eth0: 1.2.3.4
> > | firewall |
> > +====+=====+ eth1: 10.0.0.1
> >
> > +====+=====+ eth0: 10.0.0.2
> > |  server  |
> > +==========+
> >
> > What I would like is for packets coming from the server (10.0.0.2) to get
> > SNAT'd to the firewall's IP address, 1.2.3.4. It seems easy enough to do:
> >
> > iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.2 -j SNAT --to 1.2.3.4
> >
> > But now I don't see how return packets are going to make it back to my
> > server, because the firewall is going to think they are destined for it.
>
> You forget that there is magic inside netfilter :-)
>
> Just use the above rule (along with the appropriate FORWARD rules for
> server-bound requests and internet-bound replies), and it will all work
> wonderfully :-)
>
> > If I add the rule:
> >
> > iptables -t nat -A PREROUTING -d 1.2.3.4 -i ! eth0 -j DNAT --to 10.0.0.2
> >
> > Then it seems I lose the ability for the firewall to run anything
> > accessable to the outside world, like ssh.
>
> Yes, you are correct, so do not add the above rule :-)
>
>
>
> Okay, for a more serious answer....
>
> You are thinking only about IP addresses, and forgetting about port numbers.
>
> The firewall can use the port numbers to identify which incoming packets from
> the Internet are responses to packets it previously translated from the
> server, and it will automatically translate these replies back to the server;
> however any other packets with port numbers which do not correspond to
> previously sent packets do not get automagically translated, and therefore
> terminate on the firewall (eg SSH).
>
> You never normally need to include the second rule you've written unless you
> really do want all packets for IP 1.2.3.4 to be sent on to 10.0.0.2 - in most
> cases you only want this to happen for a few special port numbers (eg TCP
> port 80 if the server is a web server, TCP port 25 is it's a mail server, UDP
> & TCP ports 53 if it's a DNS server, etc).
>
> Therefore I suggest you use something like the following rules (I am assuming
> for this example that the server is a web server running http and not https):
>
> iptables -A PREROUTING -t nat -d 1.2.3.4 -p tcp --dport 80 -i eth0 -j DNAT
> --to 10.0.0.2
> iptables -A FORWARD -p tcp--dport 80 -d 10.0.0.2 -j ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A POSTROUTING -t nat -s 10.0.0.2 -o eth0 -j SNAT --to 1.2.3.4
>
> Then if you want to allow SSH to the firewall itself:
>
> iptables -A INPUT -p tcp --dport 22 -j ACCEPT
>
> (it would be good to add a -s a.b.c.d option to this if you can restrict the
> source address range you will be SSHing from)
>
>
>
> Antony.
>

RE: simple nat question

[Aldo S. Lagana]

Umm - I do it by specifying the --dport in PREROUTING:
iptables -t nat -A PREROUTING -p tcp -d X.X.X.X --dport 80 -j DNAT --to
192.1
68.101.10

Where X.X.X.X is my public....

I also need to have a FORWARD rule to the .10 address...don't forget
that the Server's DG (default Gateway) needs to be the iptables box...


> -----Original Message-----
> From: netfilter-admin@lists.samba.org 
> [mailto:netfilter-admin@lists.samba.org] On Behalf Of Ben
> Sent: Tuesday, July 02, 2002 3:35 PM
> To: NetFilter
> Subject: simple nat question
> 
> 
> I've got a basic nat setup:
> 
>   internet
>      |
> +====+=====+ eth0: 1.2.3.4
> | firewall |
> +====+=====+ eth1: 10.0.0.1
>      |
> +====+=====+ eth0: 10.0.0.2
> |  server  |
> +==========+
> 
> 
> What I would like is for packets coming from the server 
> (10.0.0.2) to get SNAT'd to the firewall's IP address, 
> 1.2.3.4. It seems easy enough to do:
> 
> iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.2 -j SNAT 
> --to 1.2.3.4
> 
> But now I don't see how return packets are going to make it 
> back to my server, because the firewall is going to think 
> they are destined for it. If I add the rule:
> 
> iptables -t nat -A PREROUTING -d 1.2.3.4 -i ! eth0 -j DNAT 
> --to 10.0.0.2
> 
> Then it seems I loose the ability for the firewall to run 
> anything accessable to the outside world, like ssh.
> 
> 

Re: simple nat question

[Raymond Leach]

Hi Ben

iptables is clever enough to know and remember where the original packet 
came from and will automagically do the translation necessary for the 
return packets.

Ray

Ben wrote:
> I've got a basic nat setup:
> 
>   internet
>      |
> +====+=====+ eth0: 1.2.3.4
> | firewall |
> +====+=====+ eth1: 10.0.0.1
>      |
> +====+=====+ eth0: 10.0.0.2
> |  server  |
> +==========+
> 
> 
> What I would like is for packets coming from the server (10.0.0.2) to get
> SNAT'd to the firewall's IP address, 1.2.3.4. It seems easy enough to do:
> 
> iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.2 -j SNAT --to 1.2.3.4
> 
> But now I don't see how return packets are going to make it back to my
> server, because the firewall is going to think they are destined for it.
> If I add the rule:
> 
> iptables -t nat -A PREROUTING -d 1.2.3.4 -i ! eth0 -j DNAT --to 10.0.0.2
> 
> Then it seems I loose the ability for the firewall to run anything
> accessable to the outside world, like ssh.
> 
>