All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Chemko" <dchemko@smgtec.com>
To: "Coutts, Ashe (Testing Account)" <ATest@sbsdk12.org>,
	netfilter@lists.netfilter.org
Subject: RE: Not quite understanding DNAT
Date: Thu, 24 Jul 2003 10:14:27 -0700	[thread overview]
Message-ID: <7C9884991ADAE0479C14F10C858BCDF5122E08@alderaan.smgtec.com> (raw)

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



             reply	other threads:[~2003-07-24 17:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-24 17:14 Daniel Chemko [this message]
2003-07-24 17:47 ` Not quite understanding DNAT Ramin Dousti
  -- strict thread matches above, loose matches on Subject: below --
2003-07-24 22:06 George Vieira
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

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=7C9884991ADAE0479C14F10C858BCDF5122E08@alderaan.smgtec.com \
    --to=dchemko@smgtec.com \
    --cc=ATest@sbsdk12.org \
    --cc=netfilter@lists.netfilter.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 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.