All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: Not quite understanding DNAT
@ 2003-07-24 22:06 George Vieira
  0 siblings, 0 replies; 8+ messages in thread
From: George Vieira @ 2003-07-24 22:06 UTC (permalink / raw)
  To: netfilter

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Not quite understanding DNAT
  2003-07-25  9:47     ` Chris Wilson
@ 2003-07-25 10:10       ` Cedric Blancher
  0 siblings, 0 replies; 8+ messages in thread
From: Cedric Blancher @ 2003-07-25 10:10 UTC (permalink / raw)
  To: Chris Wilson; +Cc: Coutts, Ashe (Testing Account), netfilter

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Not quite understanding DNAT
  2003-07-24 16:22   ` Not quite understanding DNAT Coutts, Ashe (Testing Account)
  2003-07-24 16:43     ` Aldo S. Lagana
  2003-07-25  0:14     ` Philip Craig
@ 2003-07-25  9:47     ` Chris Wilson
  2003-07-25 10:10       ` Cedric Blancher
  2 siblings, 1 reply; 8+ messages in thread
From: Chris Wilson @ 2003-07-25  9:47 UTC (permalink / raw)
  To: Coutts, Ashe (Testing Account); +Cc: netfilter

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 |



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Not quite understanding DNAT
  2003-07-24 16:22   ` Not quite understanding DNAT Coutts, Ashe (Testing Account)
  2003-07-24 16:43     ` Aldo S. Lagana
@ 2003-07-25  0:14     ` Philip Craig
  2003-07-25  9:47     ` Chris Wilson
  2 siblings, 0 replies; 8+ messages in thread
From: Philip Craig @ 2003-07-25  0:14 UTC (permalink / raw)
  To: Coutts, Ashe (Testing Account); +Cc: netfilter

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Not quite understanding DNAT
  2003-07-24 17:14 Daniel Chemko
@ 2003-07-24 17:47 ` Ramin Dousti
  0 siblings, 0 replies; 8+ messages in thread
From: Ramin Dousti @ 2003-07-24 17:47 UTC (permalink / raw)
  To: netfilter

> '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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: Not quite understanding DNAT
@ 2003-07-24 17:14 Daniel Chemko
  2003-07-24 17:47 ` Ramin Dousti
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Chemko @ 2003-07-24 17:14 UTC (permalink / raw)
  To: Coutts, Ashe (Testing Account), netfilter

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#?



^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: Not quite understanding DNAT
  2003-07-24 16:22   ` Not quite understanding DNAT Coutts, Ashe (Testing Account)
@ 2003-07-24 16:43     ` Aldo S. Lagana
  2003-07-25  0:14     ` Philip Craig
  2003-07-25  9:47     ` Chris Wilson
  2 siblings, 0 replies; 8+ messages in thread
From: Aldo S. Lagana @ 2003-07-24 16:43 UTC (permalink / raw)
  To: 'Coutts, Ashe (Testing Account)', netfilter

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Not quite understanding DNAT
  2003-07-24  8:56 ` Rio Martin.
@ 2003-07-24 16:22   ` Coutts, Ashe (Testing Account)
  2003-07-24 16:43     ` Aldo S. Lagana
                       ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Coutts, Ashe (Testing Account) @ 2003-07-24 16:22 UTC (permalink / raw)
  To: netfilter

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2003-07-25 10:10 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-24 22:06 Not quite understanding DNAT George Vieira
  -- strict thread matches above, loose matches on Subject: below --
2003-07-24 17:14 Daniel Chemko
2003-07-24 17:47 ` Ramin Dousti
2003-07-24  8:29 DNAT question Philip Craig
2003-07-24  8:56 ` Rio Martin.
2003-07-24 16:22   ` Not quite understanding DNAT Coutts, Ashe (Testing Account)
2003-07-24 16:43     ` Aldo S. Lagana
2003-07-25  0:14     ` Philip Craig
2003-07-25  9:47     ` Chris Wilson
2003-07-25 10:10       ` Cedric Blancher

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.