DNAT question..

DNAT question..

[Rio Martin.]

Dear all,
I describe first about my network:

INTERNET --- eth0 [ NAT+Firewall Linux ] eth1 --- LAN

eth0 would be my public ip = 211.1.1.10
eth1 would be my private ip = 192.168.1.1

On NAT+Firewall Linux i applied this rule:
iptables -t nat -A PREROUTING -p tcp -d 211.1.1.10 --dport 80 -j DNAT --to 
192.168.1.2:80
This is rule for redirecting to local webserver.

I tried to test it from outside network (internet), surf to http://211.1.1.10 
and it succeed.
But from inside LAN network (192.168.1.3) i am unable to browse to 
http://211.1.1.10

Let me know how to make this also worked from inside LAN Network.
Thanks ..

Regards,
Rio Martin.
-- 
Don't cook tonight -- starve a rat today!

Re: DNAT question..

[Philip Craig]

Rio Martin. wrote:
> Dear all,
> I describe first about my network:
> 
> INTERNET --- eth0 [ NAT+Firewall Linux ] eth1 --- LAN
> 
> eth0 would be my public ip = 211.1.1.10
> eth1 would be my private ip = 192.168.1.1
> 
> On NAT+Firewall Linux i applied this rule:
> iptables -t nat -A PREROUTING -p tcp -d 211.1.1.10 --dport 80 -j DNAT --to 
> 192.168.1.2:80
> This is rule for redirecting to local webserver.
> 
> I tried to test it from outside network (internet), surf to http://211.1.1.10 
> and it succeed.
> But from inside LAN network (192.168.1.3) i am unable to browse to 
> http://211.1.1.10

You need to SNAT internal connections so that replies go via the
firewall instead of directly to the client, otherwise the firewall
cannot reverse the DNAT and the client drops the reply packet.

Try this rule:

iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 192.168.1.2 --dport 80 -j SNAT --to 192.168.1.1

-- 
Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
SnapGear - Custom Embedded Solutions and Security Appliances

Re: DNAT question..

[Rio Martin.]

On Thursday 24 July 2003 15:29, you wrote:
> Rio Martin. wrote:
> > Dear all,
> > I describe first about my network:
> > INTERNET --- eth0 [ NAT+Firewall Linux ] eth1 --- LAN
> > eth0 would be my public ip = 211.1.1.10
> > eth1 would be my private ip = 192.168.1.1
> > On NAT+Firewall Linux i applied this rule:
> > iptables -t nat -A PREROUTING -p tcp -d 211.1.1.10 --dport 80 -j DNAT
> > --to 192.168.1.2:80
> > This is rule for redirecting to local webserver.
> > I tried to test it from outside network (internet), surf to
> > http://211.1.1.10 and it succeed.
> > But from inside LAN network (192.168.1.3) i am unable to browse to
> > http://211.1.1.10
> You need to SNAT internal connections so that replies go via the
> firewall instead of directly to the client, otherwise the firewall
> cannot reverse the DNAT and the client drops the reply packet.
> Try this rule:
> iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 192.168.1.2
> --dport 80 -j SNAT --to 192.168.1.1

i dont know, i tried but it still wont connect to webserver.
Connection Refused.

Regards,
Rio Martin.
-- 
You can measure a programmer's perspective by noting his attitude on
the continuing viability of FORTRAN.
		-- Alan Perlis

Re: DNAT question..

[Chris Wilson]

Hi Rio,

> > You need to SNAT internal connections so that replies go via the
> > firewall instead of directly to the client, otherwise the firewall
> > cannot reverse the DNAT and the client drops the reply packet.
> > Try this rule:
> > iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 192.168.1.2
> > --dport 80 -j SNAT --to 192.168.1.1
> 
> i dont know, i tried but it still wont connect to webserver.
> Connection Refused.

Is it possible that an earlier rule in the POSTROUTING chain is overriding 
this one? Could you try:

	iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.1.2
		-p tcp --dport 80 -j MASQUERADE

If that doesn't work, please send your ruleset (iptables -L -n -v; 
iptables -t nat -L -n -v) and tcpdump of packets on the internal interface 
of your firewall when you try to connect.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

Re: DNAT question..

[Gonzalez, Federico]

Hi Rio,

   I think the problem is in the destination IP address, you have to use the
external IP, so i think the rule should be:

iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 211.1.1.10
   --dport 80 -j SNAT --to 192.168.1.1

Hope this help

Federico.

Chris Wilson wrote:

> Hi Rio,
>
> > > You need to SNAT internal connections so that replies go via the
> > > firewall instead of directly to the client, otherwise the firewall
> > > cannot reverse the DNAT and the client drops the reply packet.
> > > Try this rule:
> > > iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 192.168.1.2
> > > --dport 80 -j SNAT --to 192.168.1.1
> >
> > i dont know, i tried but it still wont connect to webserver.
> > Connection Refused.
>
> Is it possible that an earlier rule in the POSTROUTING chain is overriding
> this one? Could you try:
>
>         iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.1.2
>                 -p tcp --dport 80 -j MASQUERADE
>
> If that doesn't work, please send your ruleset (iptables -L -n -v;
> iptables -t nat -L -n -v) and tcpdump of packets on the internal interface
> of your firewall when you try to connect.
>
> Cheers, Chris.
> --
>    ___ __     _
>  / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
> / (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
> \ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

Re: DNAT question..

[Cedric Blancher]

Le jeu 24/07/2003 à 15:37, Gonzalez, Federico a écrit :
>    I think the problem is in the destination IP address, you have to use the
> external IP, so i think the rule should be:
> iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 211.1.1.10
>    --dport 80 -j SNAT --to 192.168.1.1

Don't think so. In POSTROUTING chain, DNAT has already occured, then
original destination (211.1.1.10) has already been changed to
192.168.1.2.

Problem must sit elsewhere (next to the truth out there) ;)

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Not quite understanding DNAT

[Coutts, Ashe (Testing Account)]

I have set up a very basic firewall for our system. 
We have 126 addresses to be used to/from the outside world (204.48.178.0/25) 
and are using 10.x numbers on the inside.

It is working almost as I expected except for the following. The DNAT 
connections come into the system fine but are seen as originating from the 
eth0 interface rather than their eth0:x interface. So, when attaching to a linux 
cpu with ssh I am needing to place the ip# for the eth0 interface in the 
hosts.allow file rather than the much more restrictive eth0:x ip#. Can it be set 
up so the connection is between the external eth0:x ip# and its linked internal 
ip#?

Any help or suggestions would be greatly appreciated.

Thanks

============  Start iptables script ================
#!/bin/sh
/root/bin/NatReset

# First the "outside" eth0 interface on the firewall
/sbin/ifconfig eth0 204.48.178.2 netmask 255.255.255.128  \
        broadcast 204.48.178.127 up

### Now add aliases to eth0 to users/hosts from the  outside.
/sbin/ifconfig eth0:3 204.48.178.3 netmask 255.255.255.128  \
       broadcast 204.48.178.127 up
/sbin/ifconfig eth0:4 204.48.178.4 netmask 255.255.255.128  \
       broadcast 204.48.178.127 up
/sbin/ifconfig eth0:4 204.48.178.5 netmask 255.255.255.128  \
       broadcast 204.48.178.127 up

###  ethernet "eth1", i.e. the "inside" interface for the firewall 
/sbin/ifconfig eth1 10.0.0.1 netmask 255.255.255.248  \
       broadcast 10.0.0.7 up


## Set up outside access to the mainframe
/sbin/iptables --table nat --append PREROUTING  --destination 204.48.178.3   \
               --jump DNAT --to 10.5.2.104

## Set up outside access to a Windows 2000 cpu
/sbin/iptables --table nat --append PREROUTING  --destination 204.48.178.4   \
               --jump DNAT --to 10.5.2.105
               
#  Set up inside and outside 1 to 1 mapping for W2K user
/sbin/iptables --table nat --append PREROUTING  --destination 204.48.178.5   \
                           --jump DNAT --to 10.5.2.107
/sbin/iptables --table nat --append POSTROUTING --source 10.5.2.107/32       \
               --jump SNAT --to 204.48.178.5

## Setup NAT from entire WAN to the outside world
/sbin/iptables --table nat  --append POSTROUTING --source 0.0.0.0/0          \
               --jump SNAT --to 204.48.178.2

## Now set the genaral policies
/sbin/iptables --policy INPUT   DROP
/sbin/iptables --policy FORWARD ACCEPT
/sbin/iptables --policy OUTPUT  DROP

echo 1 > /proc/sys/net/ipv4/ip_forward
============  End iptables script ================




"Experience is not what happens to you, it
 is what you do with what happens to you"
       -- Aldous Huxley (1894-1963)

   Ashe Coutts (acoutts@sbsdk12.org)
   805.963.7751 Ext 260
   Fax 805.884.1557

RE: Not quite understanding DNAT

[Aldo S. Lagana]

Ethernet aliases - are just aliases - that means they are a different name
for the same thing.  So your eth0:x interface is actually eth0 to many
services that run on linux.  Netfilter (iptables) works perfectly well with
aliases and you can specify rules with aliases.

It is the end server applications that are not very
alias-friendly...FreeS/WAN is one of them - and like you said - SHH is one
too.


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Coutts, Ashe
(Testing Account)
Sent: Thursday, July 24, 2003 12:23 PM
To: netfilter@lists.netfilter.org

I have set up a very basic firewall for our system. 
We have 126 addresses to be used to/from the outside world (204.48.178.0/25)

and are using 10.x numbers on the inside.

It is working almost as I expected except for the following. The DNAT 
connections come into the system fine but are seen as originating from the 
eth0 interface rather than their eth0:x interface. So, when attaching to a
linux 
cpu with ssh I am needing to place the ip# for the eth0 interface in the 
hosts.allow file rather than the much more restrictive eth0:x ip#. Can it be
set 
up so the connection is between the external eth0:x ip# and its linked
internal 
ip#?

Any help or suggestions would be greatly appreciated.

Thanks

============  Start iptables script ================
#!/bin/sh
/root/bin/NatReset

# First the "outside" eth0 interface on the firewall
/sbin/ifconfig eth0 204.48.178.2 netmask 255.255.255.128  \
        broadcast 204.48.178.127 up

### Now add aliases to eth0 to users/hosts from the  outside.
/sbin/ifconfig eth0:3 204.48.178.3 netmask 255.255.255.128  \
       broadcast 204.48.178.127 up
/sbin/ifconfig eth0:4 204.48.178.4 netmask 255.255.255.128  \
       broadcast 204.48.178.127 up
/sbin/ifconfig eth0:4 204.48.178.5 netmask 255.255.255.128  \
       broadcast 204.48.178.127 up

###  ethernet "eth1", i.e. the "inside" interface for the firewall 
/sbin/ifconfig eth1 10.0.0.1 netmask 255.255.255.248  \
       broadcast 10.0.0.7 up


## Set up outside access to the mainframe
/sbin/iptables --table nat --append PREROUTING  --destination 204.48.178.3
\
               --jump DNAT --to 10.5.2.104

## Set up outside access to a Windows 2000 cpu
/sbin/iptables --table nat --append PREROUTING  --destination 204.48.178.4
\
               --jump DNAT --to 10.5.2.105
               
#  Set up inside and outside 1 to 1 mapping for W2K user
/sbin/iptables --table nat --append PREROUTING  --destination 204.48.178.5
\
                           --jump DNAT --to 10.5.2.107
/sbin/iptables --table nat --append POSTROUTING --source 10.5.2.107/32
\
               --jump SNAT --to 204.48.178.5

## Setup NAT from entire WAN to the outside world
/sbin/iptables --table nat  --append POSTROUTING --source 0.0.0.0/0
\
               --jump SNAT --to 204.48.178.2

## Now set the genaral policies
/sbin/iptables --policy INPUT   DROP
/sbin/iptables --policy FORWARD ACCEPT
/sbin/iptables --policy OUTPUT  DROP

echo 1 > /proc/sys/net/ipv4/ip_forward
============  End iptables script ================




"Experience is not what happens to you, it
 is what you do with what happens to you"
       -- Aldous Huxley (1894-1963)

   Ashe Coutts (acoutts@sbsdk12.org)
   805.963.7751 Ext 260
   Fax 805.884.1557

Re: Not quite understanding DNAT

[Philip Craig]

Coutts, Ashe (Testing Account) wrote:
> It is working almost as I expected except for the following. The DNAT 
> connections come into the system fine but are seen as originating from the 
> eth0 interface rather than their eth0:x interface. So, when attaching to a linux 
> cpu with ssh I am needing to place the ip# for the eth0 interface in the 
> hosts.allow file rather than the much more restrictive eth0:x ip#. Can it be set 
> up so the connection is between the external eth0:x ip# and its linked internal 
> ip#?

If all you are doing is DNATing, then the source address should be
the real external source address, not eth0 *or* eth0:x.

> ## Setup NAT from entire WAN to the outside world
> /sbin/iptables --table nat  --append POSTROUTING --source 0.0.0.0/0          \
>                --jump SNAT --to 204.48.178.2

But here we see that you are SNATing everything.  This is probably
not what you want.  I expect you only want to SNAT outgoing traffic:

## Setup NAT from entire WAN to the outside world
/sbin/iptables --table nat  --append POSTROUTING --out-interface eth0          \
                  --jump SNAT --to 204.48.178.2

With this rule, you should now place the real external hosts in
your hosts.allow, rather than any IP address that belongs to the
firewall.

-- 
Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
SnapGear - Custom Embedded Solutions and Security Appliances

Re: Not quite understanding DNAT

[Chris Wilson]

Hi Ashe,

> I have set up a very basic firewall for our system. 
> We have 126 addresses to be used to/from the outside world (204.48.178.0/25) 
> and are using 10.x numbers on the inside.
> 
> It is working almost as I expected except for the following. The DNAT 
> connections come into the system fine but are seen as originating from the 
> eth0 interface rather than their eth0:x interface. So, when attaching to a linux 
> cpu with ssh I am needing to place the ip# for the eth0 interface in the 
> hosts.allow file rather than the much more restrictive eth0:x ip#. Can it be set 
> up so the connection is between the external eth0:x ip# and its linked internal 
> ip#?

You could try:

	route add <internal-server-10.0.0.x> dev eth0 \
		gw <address-of-eth0:x>

Using an address of your own box as the gateway of a route will cause
locally-generated traffic going down that route to come from that address,
instead of the default address on the device. This should mean that the
masquerading uses that address too, but I haven't tested it.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

Re: Not quite understanding DNAT

[Cedric Blancher]

Le ven 25/07/2003 à 11:47, Chris Wilson a écrit :
> You could try:
> 	route add <internal-server-10.0.0.x> dev eth0 \
> 		gw <address-of-eth0:x>
> Using an address of your own box as the gateway of a route will cause
> locally-generated traffic going down that route to come from that address,
> instead of the default address on the device. This should mean that the
> masquerading uses that address too, but I haven't tested it.

I've just tested this, it does not work as I was expecting.

Therefore, you can use iproute2 to achieve this kind of behaviour. You
can specify to use an arbitrary local IP as source for a given route.
Ashe, you should try this :

	ip route add $INSERV dev eth0 src $SRCIP

I use this quite often on net2net VPN using FreeS/WAN to force gateways
to use their private IP when communicating through the tunnel.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

RE: Not quite understanding DNAT

[George Vieira]

basically, I stay away from aliases now. I'd stick to iproute2 commands and put all the IPs into the eth0 devices and not aliases..

so then it becomes..

ip addr add 204.48.178.3/25 broadcast 204.48.178.127 dev eth0
ip addr add 204.48.178.4/25 broadcast 204.48.178.127 dev eth0
ip addr add 204.48.178.5/25 broadcast 204.48.178.127 dev eth0


ifconfig won't see the IPs added so you use iproute2 command to see them.

ip addr show


Thanks,
____________________________________________
George Vieira
Systems Manager
georgev@citadelcomputer.com.au

Citadel Computer Systems Pty Ltd
http://www.citadelcomputer.com.au

Re: Not quite understanding DNAT

[Ramin Dousti]

> 'ip addr' would look like this to me:
> 
> 1: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
>     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/27 brd 192.168.1.31 scope global eth0
> inet 192.168.1.2/27 brd 192.168.1.31 scope global secondary eth0:0
> inet 192.168.1.3/27 brd 192.168.1.31 scope global secondary eth0:1
> inet 192.168.1.4/27 brd 192.168.1.31 scope global secondary eth0:2
> ...
> inet 192.168.1.30/27 brd 192.168.1.31 scope global secondary eth0:30

Absolutely. The "ip" utility must be used instead of "ifconfig", "route",
"arp" and other obsolete utilities.

Another note is that you can change the name of the interface with:

ip link set DEVICE name NEW-NAME

which will get rid of the ':' notation. This is most of the time the
casue of the problem with some applications...

Ramin

RE: Not quite understanding DNAT

[Daniel Chemko]

This behavior is to be expected, if not counter-intuitive to what you
could imagine, yes. ifconfig is b0rked in that way.

'ip addr' gives a more realistic appearance as to what is going on
internally if you use it instead of ifconfig or the like. I have had
issues with Redhat 9 and aliases, so I basically rewrote their aliasing
code to use 'ip addr' instead of ifconfig. It works a lot better than
eth:x even though I do create the aliases, I just use the ip addresses
for the real filtering.

Example:

I have 2 Interfaces

Internal: 192.168.1.0/27
External: 10.1.1.0/27

'ip addr' would look like this to me:

1: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/27 brd 192.168.1.31 scope global eth0
inet 192.168.1.2/27 brd 192.168.1.31 scope global secondary eth0:0
inet 192.168.1.3/27 brd 192.168.1.31 scope global secondary eth0:1
inet 192.168.1.4/27 brd 192.168.1.31 scope global secondary eth0:2
...
inet 192.168.1.30/27 brd 192.168.1.31 scope global secondary eth0:30

2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/27 brd 10.1.1.31 scope global eth1
inet 10.1.1.2/27 brd 10.1.1.31 scope global secondary eth1:0
inet 10.1.1.3/27 brd 10.1.1.31 scope global secondary eth1:1
inet 10.1.1.4/27 brd 10.1.1.31 scope global secondary eth1:2
...
inet 10.1.1.30/27 brd 10.1.1.31 scope global secondary eth1:30


Now when you want to use 192.168.1.4, or eth0:2 for ssh for instance,
you would just define it as:

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

Some people might get anal and include the -i eth0 but that is pretty
redundant unless you are worried about spoofers and have rp_filter
/source route disabled, (bridging) etc..

That meets your requirements. All it means is that iptables needs to use
destination addresses instead of interface addresses to use
multiple-ip-per-if filtering. 

-----Original Message-----
From: Aldo S. Lagana [mailto:alagana@discmail.com] 
Sent: Thursday, July 24, 2003 9:44 AM
To: 'Coutts, Ashe (Testing Account)'; netfilter@lists.netfilter.org
Subject: RE: Not quite understanding DNAT

Ethernet aliases - are just aliases - that means they are a different
name
for the same thing.  So your eth0:x interface is actually eth0 to many
services that run on linux.  Netfilter (iptables) works perfectly well
with
aliases and you can specify rules with aliases.

It is the end server applications that are not very
alias-friendly...FreeS/WAN is one of them - and like you said - SHH is
one
too.


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Coutts, Ashe
(Testing Account)
Sent: Thursday, July 24, 2003 12:23 PM
To: netfilter@lists.netfilter.org

I have set up a very basic firewall for our system. 
We have 126 addresses to be used to/from the outside world
(204.48.178.0/25)

and are using 10.x numbers on the inside.

It is working almost as I expected except for the following. The DNAT 
connections come into the system fine but are seen as originating from
the 
eth0 interface rather than their eth0:x interface. So, when attaching to
a
linux 
cpu with ssh I am needing to place the ip# for the eth0 interface in the

hosts.allow file rather than the much more restrictive eth0:x ip#. Can
it be
set 
up so the connection is between the external eth0:x ip# and its linked
internal 
ip#?