one to one NAT

one to one NAT

[Michael]

I've been messing around all day trying to get one to one NAT working 
for my site. This is (I think) a typical DMZ application.

INTERNET <==> linux/iptables <==> localnet

linux ip 1.2.3.4 on eth1
local net 192.168.1.0

local net ip box 192.168.1.19

I want to map 1.2.3.5 to a single address behind the linux box
1.2.3.5 is mapped to eth1:0

I can't determine if I should be using 'mangle' or a combination of 
SNAT DNAT.

A pointer to a good howto that has some details would be appreciated.

Michael
Michael@Insulin-Pumpers.org

Re: one to one NAT

[Antony Stone]

On Tuesday 10 September 2002 2:10 am, Michael wrote:

> I've been messing around all day trying to get one to one NAT working
> for my site. This is (I think) a typical DMZ application.

I don't see a DMZ anywhere in your description...   You seem to have an 
internal network, and an external connection - where's the DMZ ?

> INTERNET <==> linux/iptables <==> localnet
>
> linux ip 1.2.3.4 on eth1
> local net 192.168.1.0
>
> local net ip box 192.168.1.19
>
> I want to map 1.2.3.5 to a single address behind the linux box
> 1.2.3.5 is mapped to eth1:0

iptables -A PREROUTING -a nat -d 1.2.3.5 -j DNAT --to 192.168.1.19
iptables -A FORWARD -d 192.168.1.19 -j ACCEPT

You might want to restrict that last rule a bit with -p tcp --dport 80 or 
whatever, depending on what that machine is running and what you're trying to 
make accessible to the Internet.

Antony.

-- 

In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

Re: one to one NAT

[Anders Fugmann]

Antony Stone wrote:
> On Tuesday 10 September 2002 2:10 am, Michael wrote:
>>I want to map 1.2.3.5 to a single address behind the linux box
>>1.2.3.5 is mapped to eth1:0
 >
> iptables -A PREROUTING -a nat -d 1.2.3.5 -j DNAT --to 192.168.1.19
> iptables -A FORWARD -d 192.168.1.19 -j ACCEPT
> 
This only takes care of the ingoring part. Outgoing would be solved
by using SNAT:
$ iptables -A POSTROUTING -t nat -s 1.2.3.5 -j SNAT \
	--to-source 192.168.1.19
$ iptables -A FORWARD -s 192.168.1.19 -j ACCEPT

(Antony made a small typo - it should have been '-t nat' and not '-a 
nat', unless Im mistaken)

I would suggest that you apply network interface names, where possible.

Regards
Anders Fugmann

-- 
Author of FIAIF
FIAIF Is An Intelligent/Iptables Firewall
http://fiaif.fugmann.dhs.org

Re: one to one NAT

[Anders Fugmann]

Anders Fugmann wrote:
> $ iptables -A POSTROUTING -t nat -s 1.2.3.5 -j SNAT \
>     --to-source 192.168.1.19
Sorry this is wrong. It should have been:

$ iptables -A POSTROUTING -t nat -s 192.168.1.19 -j SNAT \
      --to-source 1.2.3.4

Regards
Anders Fugmann
-- 
Author of FIAIF
FIAIF Is An Intelligent/Iptables Firewall
http://fiaif.fugmann.dhs.org

Re: one to one NAT

[Antony Stone]

On Tuesday 10 September 2002 7:29 am, Anders Fugmann wrote:

> Antony Stone wrote:
> > On Tuesday 10 September 2002 2:10 am, Michael wrote:
> >>I want to map 1.2.3.5 to a single address behind the linux box
> >>1.2.3.5 is mapped to eth1:0
> >
> > iptables -A PREROUTING -a nat -d 1.2.3.5 -j DNAT --to 192.168.1.19
> > iptables -A FORWARD -d 192.168.1.19 -j ACCEPT
>
> This only takes care of the ingoring part. Outgoing would be solved
> by using SNAT:
> $ iptables -A POSTROUTING -t nat -s 1.2.3.5 -j SNAT \
> 	--to-source 192.168.1.19
> $ iptables -A FORWARD -s 192.168.1.19 -j ACCEPT
>
> (Antony made a small typo - it should have been '-t nat' and not '-a
> nat', unless Im mistaken)

Yes, I did make a typo - thanks for spotting that - it should indeed be '-t 
nat'.

However, the SNAT rule is not necessary if all you're doing is making 
services on the internal machine available to the Internet (which is what you 
said you wanted to do).   Incoming connections will be translated by the DNAT 
rule, and outgoing replies will be automatically reverse translated by the 
magic of netfilter.   You do not need a SNAT rule to get the replies back to 
the outside world.

You would want a SNAT rule only if the machine inside your network needs to 
initiate connections to the Internet, *and* they need to come from the same 
public address as that machine is being made accessible on.   If it doesn't 
initiate its own connections, you don't need SNAT, or if it does but it 
doesn't matter what the source address of those connections is, then it can 
just use the normal SNAT or MASQUERADE rule which you presumably have to 
allow the rest of your network to get to the outside world.

Antony.

-- 

Success is a lousy teacher.   It seduces smart people into thinking they 
can't lose.

 - William H Gates III

Re: one to one NAT

[Antony Stone]

On Tuesday 10 September 2002 3:19 am, Michael wrote:

> > iptables -A PREROUTING -t nat -d 1.2.3.5 -j DNAT --to 192.168.1.19
> > iptables -A FORWARD -d 192.168.1.19 -j ACCEPT
> >
> > You might want to restrict that last rule a bit with -p tcp --dport
> > 80 or whatever, depending on what that machine is running and what
> > you're trying to make accessible to the Internet.
>
> gggrrrrr.... this is where I was stuck before. I'm using the "msg"
> port for testing. The linux box has no message but the inside machine
> has a couple of lines of poetry. My rules say:
>
> MERLIN_OS="1.2.3.5"
> MERLIN_IS="192.168.1.19"
>
> $IPTABLES -t nat -A PREROUTING -d $MERLIN_OS \
>   -j DNAT --to-destination $MERLIN_IS
> $IPTABLES -A FORWARD -d $MERLIN_IS -j ACCEPT
>
> no workeeee
> using netcat, the connection just hangs
> nc 1.2.3.5 17
> (stuck, no response)
> sigh.....

Where are you testing this from ?   Hopefully a machine completely outside 
your network ?

Bear in mind it *will not work* if you try to connect to 1.2.3.5 from a 
machine on the same subnet as 192.168.1.19.

Antony.

-- 

Having been asked to provide a reference for this man,
I can confidently state that you will be very lucky indeed
if you can get him to work for you.

one to one NAT

[Brennan, JosephX M]

I have been trying for a couple days to set up one to one nat with iptables
with a few weird results so I would any input out there that could help me
resolve my problem.

First, what I am trying to do is set up a box with a virtual ip that will be
mapped through my iptables box so that essentually the internal box is the
external ip.

I have a dual homed box with interfaces: eth1(internal card):192.168.1.254
and eth2(external card):10.10.10.254.  In addtion I have an external test
box with an ip of 10.10.11.23.  Both the 10.10.10.254 and 10.10.11.23 boxes
are hooked up to a 550T Intel routing switch so they are able to talk to
each other.  On the other side I have an internal test box with an ip of
192.168.1.24 and obviously because the routing box and internal test box are
on the same network they can talk.

My question however is i have tried this command

iptables -t nat -A PREROUTING -d 10.10.10.254 -j DNAT --to 192.168.1.24

and my internal box gets a request from the outside box however it does not
look like there has been any "NAT"ing taken place because when I run a
packet sniffer on the internal box the packets are still coming from the
10.10.10.23 address and obviously the internal box has no idea how to send
the information back.

So if anyone has any suggestions I would appreciate it.

Joe

PS.  I forgot to mention it above but I do have ip forwarding turned on.

Re: one to one NAT

[Antony Stone]

On Tuesday 24 September 2002 1:13 am, Brennan, JosephX M wrote:

> I have a dual homed box with interfaces: eth1(internal card):192.168.1.254
> and eth2(external card):10.10.10.254.  In addtion I have an external test
> box with an ip of 10.10.11.23.
> On the other side I have an internal test box with an ip of
> 192.168.1.24.
>
> My question however is i have tried this command
>
> iptables -t nat -A PREROUTING -d 10.10.10.254 -j DNAT --to 192.168.1.24
>
> and my internal box gets a request from the outside box however it does not
> look like there has been any "NAT"ing taken place because when I run a
> packet sniffer on the internal box the packets are still coming from the
> 10.10.10.23 address and obviously the internal box has no idea how to send
> the information back.

The NAT *has* taken place, otherwise it wouldn't have got to the destination 
machine.

However, you have set up a DNAT rule, so that's what netfilter has done - 
destination NAT.   It has not changed the source address because you have no 
SNAT rule.

Why does the internal box have no idea how to send the information back ?   
What is its default gateway ?

Antony.

-- 

KDE 3.0.3 contains an important fix for handling SSL certificates.  Users of 
Internet Explorer, which suffers from the same problem but which
does not yet have a fix available, are also encouraged to switch to KDE 3.0.3.

http://www.kde.org/announcements/announce-3.0.3.html

One to One NAT

[EricRyd]

I have been given a task to setup One to One NAT on a Linux box.  If I'm
correct I need to do this

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.1-j DNAT --to-destination
172.100.1.1

First off, is this the correct syntax?  If not, I can't find for sure what I
would have to do.  Any suggestions?

Second, here is another scenario I have to do.  I work for Tech Support, and
we have a lab full of devices to assist us when working with Customers.  Our
internal IP Scheme is 192.168.0.0/16.  Some of the devices are
192.168.1.0/24 and can't be changed.  The original plan was to setup a 1:1
NAT with the Linux box to forward to the /24 network so we could use all of
the devices, but since I have been given the project I can't see it working.
How will the Linux box know	 which network to pass information on to
since they are both 192.168.x.x.  Any suggestions or ideas?

Thanks in advance,

Eric

Re: One to One NAT

[Joel Newkirk]

On Wednesday 05 February 2003 01:27 pm, EricRyd@cdw.com wrote:
> I have been given a task to setup One to One NAT on a Linux box.  If
> I'm correct I need to do this
>
> iptables -t nat -A PREROUTING -p tcp -d 192.168.1.1-j DNAT
> --to-destination 172.100.1.1
>
> First off, is this the correct syntax?  If not, I can't find for sure
> what I would have to do.  Any suggestions?

This rule will take any TCP packets entering the box with destIP of 
192.168.1.1 and change that destIP to 172.100.1.1.  If that is the way 
you want the packets changed (and not the other way around) then your 
syntax is correct. :^)  You also have to ensure this traffic is ACCEPTed 
in the FORWARD chain.  Also, you might (depending on the nature of the 
traffic) want/need to allow ESTABLISHED and RELATED state connections 
through FORWARD as well - you'd at least need return traffic ACCEPTed.

> Second, here is another scenario I have to do.  I work for Tech
> Support, and we have a lab full of devices to assist us when working
> with Customers.  Our internal IP Scheme is 192.168.0.0/16.  Some of
> the devices are 192.168.1.0/24 and can't be changed.  The original
> plan was to setup a 1:1 NAT with the Linux box to forward to the /24
> network so we could use all of the devices, but since I have been
> given the project I can't see it working. How will the Linux box know	
> which network to pass information on to since they are both
> 192.168.x.x.  Any suggestions or ideas?

If the are on the same network wiring, and the 192.168.0.0/16 doesn't 
have any machines with IPs overlapping the 192.168.1.0/24, you should be 
fine.  The only problem you would have is the 192.168.1.0/24 machines 
wouldn't realize that the others are actually local.  If there's no 
overlap, and they don't need to talk to each other directly, you should 
be able to do it.

If they are on separate wiring, separate interfaces in the Linux box, I 
think you can get it to work by making sure the /24 route appears first, 
before the /16 route, but I'm not certain of this, and it wouldn't 
really be 'proper'...  Routing itself might be accomplished by marking 
all /16 packets in mangle prerouting then setting up separate routing 
for that mark, but again you couldn't handle any overlaps.

In iptables rules themselves you can 'cheat' and use a mask like 
255.255.1.0 to separate odd and even numbers in the third octet, but 
you'd need to ensure that the /24 network doesn't use any odd numbers 
then.  Still not a good solution, and wouldn't address routing issues 
without getting into full-time marking, since I don't believe that 
iproute2 supports funky masks like this.  (I might be wrong though)

j

> Thanks in advance,
>
> Eric