Static NAT Iptables 1.2.7a

Static NAT Iptables 1.2.7a

Post by Edward van der Maa » Tue, 17 Jun 2003 04:05:43



Hi,

Is there anyone who has experience with creating static nats with iptables
1.2.7a.

What is it that I exactly want.
We have a linux firewall with two NICs. One for the Internet and one for the
DMZ (most obvious). In our DMZ we have a couple of webservers and on the
public NIC I've created a couple virtual interfaces (eth1:1, eth1:2 etc.)
for the extra ipaddresses.

The problem now is that when I want to create a DNAT based on the interfaces
iptables starts complaining that I can't use those virtual nics. Basically
it has a problem with the ":".

I'm aware that there is a new target introduced in iptables 1.2.8 called
NETMAP but I can't use that. In that case I need to rebuild a kernel which
is not an option here.

Is there anyone who can help me out with this "problem" ?

Many thanks,
Edward

 
 
 

Static NAT Iptables 1.2.7a

Post by Ida » Tue, 17 Jun 2003 12:28:43


IPTABLES rules are comparatively hard to be designed and maintained. You can
get a advanced firewall, such as ITShield firewall
(http://www.itshield.com).



Quote:> Hi,

> Is there anyone who has experience with creating static nats with iptables
> 1.2.7a.

> What is it that I exactly want.
> We have a linux firewall with two NICs. One for the Internet and one for
the
> DMZ (most obvious). In our DMZ we have a couple of webservers and on the
> public NIC I've created a couple virtual interfaces (eth1:1, eth1:2 etc.)
> for the extra ipaddresses.

> The problem now is that when I want to create a DNAT based on the
interfaces
> iptables starts complaining that I can't use those virtual nics. Basically
> it has a problem with the ":".

> I'm aware that there is a new target introduced in iptables 1.2.8 called
> NETMAP but I can't use that. In that case I need to rebuild a kernel which
> is not an option here.

> Is there anyone who can help me out with this "problem" ?

> Many thanks,
> Edward


 
 
 

Static NAT Iptables 1.2.7a

Post by Edward van der Maa » Tue, 17 Jun 2003 15:19:47


If you use webmin to maintain your rule "database" it is quite easy.

Anyone else has information on my issue ?


> IPTABLES rules are comparatively hard to be designed and maintained. You
can
> get a advanced firewall, such as ITShield firewall
> (http://www.itshield.com).



> > Hi,

> > Is there anyone who has experience with creating static nats with
iptables
> > 1.2.7a.

> > What is it that I exactly want.
> > We have a linux firewall with two NICs. One for the Internet and one for
> the
> > DMZ (most obvious). In our DMZ we have a couple of webservers and on the
> > public NIC I've created a couple virtual interfaces (eth1:1, eth1:2
etc.)
> > for the extra ipaddresses.

> > The problem now is that when I want to create a DNAT based on the
> interfaces
> > iptables starts complaining that I can't use those virtual nics.
Basically
> > it has a problem with the ":".

> > I'm aware that there is a new target introduced in iptables 1.2.8 called
> > NETMAP but I can't use that. In that case I need to rebuild a kernel
which
> > is not an option here.

> > Is there anyone who can help me out with this "problem" ?

> > Many thanks,
> > Edward

 
 
 

Static NAT Iptables 1.2.7a

Post by Gary Gapinsk » Wed, 18 Jun 2003 00:00:39



Quote:> Hi,

> Is there anyone who has experience with creating static nats with iptables
> 1.2.7a.

> What is it that I exactly want.
> We have a linux firewall with two NICs. One for the Internet and one for the
> DMZ (most obvious). In our DMZ we have a couple of webservers and on the
> public NIC I've created a couple virtual interfaces (eth1:1, eth1:2 etc.)
> for the extra ipaddresses.

> The problem now is that when I want to create a DNAT based on the interfaces
> iptables starts complaining that I can't use those virtual nics. Basically
> it has a problem with the ":".

Rather than using the eth1:1, eth1:2, etc. notation, perhaps you could
simply declare the additional addresses using the ip (from iproute2)
directive, e.g.,

ip addr add 10.11.12.13/24 brd 10.11.12.255 scope global dev eth1

This avoids the problematic interface names.