DMZ trouble!

DMZ trouble!

[David Collodel]

Hi,

I've recently been working on a firewall using IPtables to create a
DMZ/LAN setup.

I have a system with 3 NIC's. 

eth0 has the "real" static IP's from my ISP. I'm using NAT to translate
from the IP bound on this NIC to the internal DMZ and LAN hosts.
eth1 is set to 172.16.12.1 and is used as the DMZ interface. Hosts
connected to this interface are all 172.16.12.x
eth2 is set to 172.16.11.1 and is used as the LAN interface.Hosts
connected here are all 172.16.11.x

Most things seem to be working, I can connect from the LAN to the DMZ
and to the Internet. I can connect from the DMZ to the Internet, but not
to the LAN, but already established connections work. Only the ports I
specify are open from the Internet to the DMZ.

The problem I'm having is this:

When I try to connect to a host in the DMZ from the LAN, it does not
work when I use the "real" IP address.

An example of the error in the logs is this:
-----
IPT INPUT packet died: IN=eth1 OUT=
MAC=00:10:5a:1b:48:8a:00:10:5a:00:ff:b8:08:00 SRC=172.16.11.2
DST=66.92.171.152 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3514 DF PROTO=TCP
SPT=32949 DPT=80 WINDOW=5440 RES=0x00 SYN URGP=0
----

Does anyone have any idea why this might be happening?

Much thanks.

-- 
David Collodel <dave@crawlspaceradio.com>

Re: DMZ trouble!

[Dharmendra.T]

On Thu, 2003-01-09 at 09:12, David Collodel wrote:
> Hi,
> 
> I've recently been working on a firewall using IPtables to create a
> DMZ/LAN setup.
> 
> I have a system with 3 NIC's. 
> 
> eth0 has the "real" static IP's from my ISP. I'm using NAT to translate
> from the IP bound on this NIC to the internal DMZ and LAN hosts.
> eth1 is set to 172.16.12.1 and is used as the DMZ interface. Hosts
> connected to this interface are all 172.16.12.x
> eth2 is set to 172.16.11.1 and is used as the LAN interface.Hosts
> connected here are all 172.16.11.x
> 
> Most things seem to be working, I can connect from the LAN to the DMZ
> and to the Internet. I can connect from the DMZ to the Internet, but not
> to the LAN, but already established connections work. Only the ports I
> specify are open from the Internet to the DMZ.
> 
> The problem I'm having is this:
> 
> When I try to connect to a host in the DMZ from the LAN, it does not
> work when I use the "real" IP address.
> 
> An example of the error in the logs is this:
> -----
> IPT INPUT packet died: IN=eth1 OUT=
> MAC=00:10:5a:1b:48:8a:00:10:5a:00:ff:b8:08:00 SRC=172.16.11.2
> DST=66.92.171.152 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3514 DF PROTO=TCP
> SPT=32949 DPT=80 WINDOW=5440 RES=0x00 SYN URGP=0
> ----
> 
> Does anyone have any idea why this might be happening?
> 
> Much thanks.
> 
> -- 
> David Collodel <dave@crawlspaceradio.com>
> 
> 

You have to configure your DNS server so that whenever a request comes
from the internal it should be sent to DMZ.

If from internal you can connect to any of the servers which are there
in the external, then you should also be able to connect to the DMZ
using the external ip. 


And tell me how the connetivity is going on from external to the DMZ? 

-- 
Dharmendra.T
Linux Enthu

Re: DMZ trouble!

[Joel Newkirk]

On Thursday 09 January 2003 12:34 am, David Collodel wrote:

{Very heavily snipped}

> Perhaps it would help if I included my entire script? Or at least the
> relevant parts of it.

It seems you included it entire.  :^)

> Thanks for any help you can offer.

[snipped lengthy but self-explanatory IP & interface aliases]

> $IPTABLES -P INPUT DROP
> $IPTABLES -P OUTPUT DROP
> $IPTABLES -P FORWARD DROP
>
> $IPTABLES -F
>
> $IPTABLES -F INPUT
> $IPTABLES -F OUTPUT
> $IPTABLES -F FORWARD
>
> $IPTABLES -F -t mangle
> $IPTABLES -t mangle -X

Why are you not flushing nat table as well?  BTW, the "$IPTABLES -F" 
encompasses all the filter table chains, so the following three flushes 
are redundant.

Why do you have so many (snipped) rules for INPUT to the firewall box 
itself?  Do you really need to allow all ports and all protocols from 
the DMZ and the LAN??  Unless you are running some services on the box 
(which should probably be run on a server on the LAN or in the DMZ) you 
really shouldn't allow ANY access, except SSH if you must.  Other than 
SSH I can't conceive of why you need ANY access to this box from the 
Internet.  Even the EST/REL shouldn't be necessary.

> $IPTABLES -A FORWARD -i $DMZ_IFACE -o $EXT_IFACE -j ACCEPT

This should probably be dropped in favor of individual rules to allow 
each (if any other than DNS) connection that the DMZ machines would need 
to initiate.

> $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT

Do you trust the LAN machines and users this much?  You'd probably be 
much better off if you just have a handful of rules to ACCEPT the 
services they really require.  If someone needs something that doesn't 
get through the firewall, you'll certainly get a call. :^)  You can then 
decide if you want to allow it, and if so then add an appropriate rule.  
On my home network, where I control all machines, I STILL only allow 
four ports through FORWARD, and log everything else.  And my INPUT rules 
are tighter than this, and my firewall IS my desktop machine, web 
server, and an Unreal Tournament server, and runs P2P sometimes.  (Both 
those are toggled through a script, so I open the ports manually with 
"fw ut" for example then close with "fw utx")

> $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

This one makes all your other FORWARD state rules rather unnecessary, 
since they are all tighter than this, and this accepts any interface.

> $IPTABLES -A OUTPUT -p ALL -s $EXT_IP -j ACCEPT

Again, what need do you have for this box to communicate directly with 
anything on the internet?  I would lock this sucker down TIGHT.  Set up 
a script owned by root that you can execute to temporarily open INPUT 
and OUTPUT only as far as absolutely necessary if there's anything you 
need to do from the box.  Other than that leave OUTPUT and INPUT at just 
DROP, with SSH allowed in and responded only if you have to.  If 
somebody gets this box, they own your network.  Don't invite trouble.  
(especially now that your complete firewall is part of a publicly 
accessibly archive...)

I'm not sure why you bothered with a DROP policy on OUTPUT with the four 
OUTPUT rules you use.  The ONLY thing you prevent from going out is an 
incorrect IP.

> $IPTABLES -F -t nat

Ah, here's the nat table flush, 2/3 of the way through the script... :^)  
Not a big deal, just that everything else is organized fairly clearly.

> # 3.2 PREROUTING chain

> # 3.2.3 DMZ DNAT
> #
>
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP
> --dport 80 -j DNAT --to-destination $DMZ_HTTP_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP
> --dport 22 -j DNAT --to-destination $DMZ_HTTP_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP
> --dport 443 -j DNAT --to-destination $DMZ_HTTP_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP
> --dport 8000 -j DNAT --to-destination $DMZ_HTTP_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP
> --dport 8001 -j DNAT --to-destination $DMZ_HTTP_IP
>
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
> 53 -j DNAT --to-destination $DMZ_DNS_IP
> $IPTABLES -t nat -A PREROUTING -p UDP -i $EXT_IFACE -d $DNS_IP --dport
> 53 -j DNAT --to-destination $DMZ_DNS_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
> 443 -j DNAT --to-destination $DMZ_DNS_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
> 22 -j DNAT --to-destination $DMZ_DNS_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
> 25 -j DNAT --to-destination $DMZ_DNS_IP
> $IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
> 995 -j DNAT --to-destination $DMZ_DNS_IP

Hmmm.  Well, this is the answer to your 'real' question.  I don't see ANY 
rules in PREROUTING to DNAT connections from the LAN. Those would be 
addressed -d $DNS_IP, but would be -i $LAN_IFACE.

You should seriously reconsider what communications the firewall box 
itself requires, and what traffic the LAN is allowed to conduct.

j

RE: DMZ trouble!

[David Collodel]

Perhaps it would help if I included my entire script? Or at least the
relevant parts of it.

Thanks for any help you can offer.

#
# 1.1 Internet Configuration.
#

#
# 1.1.1 Device and network configs.
#

EXT_IFACE="eth0"				# External Interface
LAN_IFACE="eth1"				# Internal Interface
DMZ_IFACE="eth2"				# DMZ Interface
LO_IFACE="lo"					# Loopback Interface
GATEWAY="66.91.171.1"				# Our External gateway.
EXT_IP="66.92.171.151"				# Primary IP address of $EXT_IFACE
NET_BCAST="66.92.171.255"			# Broadcast addy of external (ISP's) net.

#
# 1.1.2 Define our "real" ip's to be NAT'ed
#       More can be added, but additional rules will need to be created
#       below to specify their access.
#

HTTP_IP="66.92.171.152"				# WWW server IP
DNS_IP="66.92.171.150"				# Mail, DNS IP
SQL_IP="66.92.171.149"				# Data service IP



#
# 1.1.3 Local Area Network configuration.
#
# LAN IP range and localhost IP. /24 means to only use the first 24
# bits of the 32 bit IP address. the same as netmask 255.255.255.0
#

LAN_IP="172.16.11.1"				# IP bound to $LAN_IFACE
LAN_NET="172.16.11.0/24"			# Internal Net range
LAN_BCAST="172.16.11.255"			# LAN Broadcast Address

#
# 1.1.4 DMZ Configuration.
#

DMZ_HTTP_IP="172.16.12.2"			# IP where $HTTP_IP will be NAT'ed
DMZ_DNS_IP="172.16.12.3"			# IP where $DNS_IP will be NAT'ed
DMZ_SQL_IP="172.16.12.4"			# IP where $SQL_IP will be NAT'ed
DMZ_IP="172.16.12.1"				# IP bound to $DMZ_IFACE
DMZ_NET="172.16.12.0/24"			# DMZ Network range
DMZ_BCAST="172.16.12.255"			# DMZ Broadcast Address

#
# 1.1.5 Localhost Configuration.
#

LO_IP="127.0.0.1"

#
# 1.2 IPTables Configuration.
#

#
# 1.2.1 Define IPtables binary

IPTABLES="/sbin/iptables"


#
# 2. rules set up.
#


# 2.1 Filter table
#

#
# 2.1.1 Set policies first, then flush chains
#

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

$IPTABLES -F

$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD

$IPTABLES -F -t mangle
$IPTABLES -t mangle -X

$IPTABLES -X

#
# 2.2 Create userspecified chains
#

#
# 2.2.1 Create chain for bad tcp packets
#

$IPTABLES -N bad_tcp_packets
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG
\
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

## DROP packets associated with an "INVALID" connection.
$IPTABLES -A bad_tcp_packets -m state --state INVALID $LOG "INVALID
STATE: "
$IPTABLES -A bad_tcp_packets -m state --state INVALID -j DROP


#
# 2.2.2 Create chain to handle various stateful connections
#

$IPTABLES -N KEEP_STATE
$IPTABLES -F KEEP_STATE

## ACCEPT certain packets which are starting a new connection or are
## related to an established connection.
$IPTABLES -A KEEP_STATE -p TCP --syn -j ACCEPT
$IPTABLES -A KEEP_STATE -m state --state RELATED,ESTABLISHED -j ACCEPT

## ACCEPT packets whose input interface is anything but the external
interface.
$IPTABLES -A KEEP_STATE -i ! $EXT_IP -m state --state NEW -j ACCEPT

## DROP packets associated with an "INVALID" connection.
$IPTABLES -A KEEP_STATE -m state --state INVALID $LOG "INVALID STATE: "
$IPTABLES -A KEEP_STATE -m state --state INVALID -j DROP

## Drop the rest
$IPTABLES -A KEEP_STATE -p TCP -j DROP

#
# 2.2.3 Create chain for ICMP control
#

$IPTABLES -N icmp_packets
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 3 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 4 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

#
# 2.3  INPUT chain
#

#
# 2.3.1 Take out the nasties first.
#

$IPTABLES -A INPUT -p tcp -j bad_tcp_packets

#
# 2.3.2 Filter ICMP Packets from the Internet to this box
#

$IPTABLES -A INPUT -p ICMP -i $EXT_IFACE -j icmp_packets

#
# 2.3.3 Packets from LAN, DMZ or LOCALHOST
#
# From External Interface, for SSH management
$IPTABLES -A INPUT -p TCP -i $EXT_IFACE -d $EXT_IP --dport 22 -j ACCEPT

# From DMZ Interface to DMZ firewall IP
$IPTABLES -A INPUT -p ALL -i $DMZ_IFACE -d $DMZ_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $DMZ_IFACE -s $DMZ_IP -d $DMZ_NET -j
KEEP_STATE

# From LAN Interface to LAN firewall IP
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_BCAST -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_NET -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_NET -d $LAN_IP -j ACCEPT

# From Localhost interface to Localhost IP's
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $EXT_IP -j ACCEPT

# Special rule for DHCP requests from LAN, which are not caught properly
# otherwise.
$IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT

# All established and related packets incoming from the internet to the
# firewall
$IPTABLES -A INPUT -p ALL -d $EXT_IP -m state --state
ESTABLISHED,RELATED \
-j ACCEPT

# Prevent MS multicast from nailing the logs.
$IPTABLES -A INPUT -i $EXT_IFACE -d 224.0.0.0/8 -j DROP

# Log weird packets that don't match the above.
$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT INPUT packet died: "

#
# 2.4 Forward chain
#

#
# 2.4.1 Take out the nasties first.
#

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets


#
# 2.4.2 DMZ section
#

# General rules

$IPTABLES -A FORWARD -i $DMZ_IFACE -o $EXT_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $EXT_IFACE -o $DMZ_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j KEEP_STATE
$IPTABLES -A FORWARD -i $DMZ_IFACE -o $LAN_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -p icmp -i $DMZ_IFACE -j icmp_packets

# HTTP server
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP
--dport 80 -j KEEP_STATE
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP
--dport 443 -j KEEP_STATE
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP
--dport 8000 -j KEEP_STATE
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP
--dport 8001 -j KEEP_STATE
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP
--dport 22 -j KEEP_STATE
$IPTABLES -A FORWARD -p ICMP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP
-j icmp_packets

# DNS server
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP
--dport 53 -j KEEP_STATE
$IPTABLES -A FORWARD -p UDP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP
--dport 53 -j ACCEPT
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP
--dport 443 -j KEEP_STATE
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP
--dport 25 -j KEEP_STATE
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP
--dport 22 -j KEEP_STATE
$IPTABLES -A FORWARD -p TCP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP
--dport 995 -j KEEP_STATE
$IPTABLES -A FORWARD -p ICMP -i $EXT_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP
-j icmp_packets

#
# 2.4.3 LAN section
#

$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Log weird packets that don't match the above.
$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT FORWARD packet died: "


#
# 2.5 OUTPUT chain
#

#
# 2.5.1 Take out the nasties first
#

$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

#
# Special OUTPUT rules to decide which IP's to allow.
#

$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LAN_NET -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $EXT_IP -j ACCEPT

# Log weird packets that don't match the above.
$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

#
# 3 NAT table
#

#
# 3.1 Flush the NAT table
#

$IPTABLES -F -t nat


#
# 3.2 PREROUTING chain
#

#
# 3.2.3 DMZ DNAT
#

$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP --dport
80 -j DNAT --to-destination $DMZ_HTTP_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP --dport
22 -j DNAT --to-destination $DMZ_HTTP_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP --dport
443 -j DNAT --to-destination $DMZ_HTTP_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP --dport
8000 -j DNAT --to-destination $DMZ_HTTP_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $HTTP_IP --dport
8001 -j DNAT --to-destination $DMZ_HTTP_IP

$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
53 -j DNAT --to-destination $DMZ_DNS_IP
$IPTABLES -t nat -A PREROUTING -p UDP -i $EXT_IFACE -d $DNS_IP --dport
53 -j DNAT --to-destination $DMZ_DNS_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
443 -j DNAT --to-destination $DMZ_DNS_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
22 -j DNAT --to-destination $DMZ_DNS_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
25 -j DNAT --to-destination $DMZ_DNS_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $EXT_IFACE -d $DNS_IP --dport
995 -j DNAT --to-destination $DMZ_DNS_IP

#
# 3.3 POSTROUTING chain
#

#
# 3.3.1 Enable simple IP Forwarding and Network Address Translation
#

$IPTABLES -t nat -A POSTROUTING -o $EXT_IFACE -j SNAT --to-source
$EXT_IP


-- 
David Collodel <dave@crawlspaceradio.com>

RE: DMZ trouble!

[David Collodel]

Yes. I've got the following for my generic FORWARD rules:
-----
$IPTABLES -A FORWARD -i $DMZ_IFACE -o $EXT_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $EXT_IFACE -o $DMZ_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j KEEP_STATE
$IPTABLES -A FORWARD -i $DMZ_IFACE -o $LAN_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT
-----

DMZ_IFACE = eth1
EXT_IFACE = eth0
LAN_IFACE = eth2

The traffic gets forwarded everywhere if I use the internal IP
addresses. It only seems to have a problem if I try to connect from a
LAN address to a "real" ip that's bound to eth0

something like  172.16.11.2 -> 172.16.12.2  works fine.

However, 172.16.11.2 -> 66.92.171.152  does not work.

66.92.171.152 is bound to eth0, and when someone on the OUTSIDE tries to
connect to it, it gets properly forwarded and NAT'ed to 172.16.12.2


On Wed, 2003-01-08 at 23:22, John A. Novak wrote:
> Do you have rules that allow traffic to be forwarded from the LAN to the DMZ and back ?
> 
> John Novak
> 
> -----Original Message-----
> From: David Collodel [mailto:dave@crawlspaceradio.com]
> Sent: Wednesday, January 08, 2003 7:43 PM
> To: netfilter@lists.netfilter.org
> Subject: DMZ trouble!
> 
> 
> Hi,
> 
> I've recently been working on a firewall using IPtables to create a
> DMZ/LAN setup.
> 
> I have a system with 3 NIC's. 
> 
> eth0 has the "real" static IP's from my ISP. I'm using NAT to translate
> from the IP bound on this NIC to the internal DMZ and LAN hosts.
> eth1 is set to 172.16.12.1 and is used as the DMZ interface. Hosts
> connected to this interface are all 172.16.12.x
> eth2 is set to 172.16.11.1 and is used as the LAN interface.Hosts
> connected here are all 172.16.11.x
> 
> Most things seem to be working, I can connect from the LAN to the DMZ
> and to the Internet. I can connect from the DMZ to the Internet, but not
> to the LAN, but already established connections work. Only the ports I
> specify are open from the Internet to the DMZ.
> 
> The problem I'm having is this:
> 
> When I try to connect to a host in the DMZ from the LAN, it does not
> work when I use the "real" IP address.
> 
> An example of the error in the logs is this:
> -----
> IPT INPUT packet died: IN=eth1 OUT=
> MAC=00:10:5a:1b:48:8a:00:10:5a:00:ff:b8:08:00 SRC=172.16.11.2
> DST=66.92.171.152 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3514 DF PROTO=TCP
> SPT=32949 DPT=80 WINDOW=5440 RES=0x00 SYN URGP=0
> ----
> 
> Does anyone have any idea why this might be happening?
> 
> Much thanks.
-- 
David Collodel <dave@crawlspaceradio.com>

RE: DMZ trouble!

[John A. Novak]

Do you have rules that allow traffic to be forwarded from the LAN to the DMZ and back ?

John Novak

-----Original Message-----
From: David Collodel [mailto:dave@crawlspaceradio.com]
Sent: Wednesday, January 08, 2003 7:43 PM
To: netfilter@lists.netfilter.org
Subject: DMZ trouble!


Hi,

I've recently been working on a firewall using IPtables to create a
DMZ/LAN setup.

I have a system with 3 NIC's. 

eth0 has the "real" static IP's from my ISP. I'm using NAT to translate
from the IP bound on this NIC to the internal DMZ and LAN hosts.
eth1 is set to 172.16.12.1 and is used as the DMZ interface. Hosts
connected to this interface are all 172.16.12.x
eth2 is set to 172.16.11.1 and is used as the LAN interface.Hosts
connected here are all 172.16.11.x

Most things seem to be working, I can connect from the LAN to the DMZ
and to the Internet. I can connect from the DMZ to the Internet, but not
to the LAN, but already established connections work. Only the ports I
specify are open from the Internet to the DMZ.

The problem I'm having is this:

When I try to connect to a host in the DMZ from the LAN, it does not
work when I use the "real" IP address.

An example of the error in the logs is this:
-----
IPT INPUT packet died: IN=eth1 OUT=
MAC=00:10:5a:1b:48:8a:00:10:5a:00:ff:b8:08:00 SRC=172.16.11.2
DST=66.92.171.152 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3514 DF PROTO=TCP
SPT=32949 DPT=80 WINDOW=5440 RES=0x00 SYN URGP=0
----

Does anyone have any idea why this might be happening?

Much thanks.

-- 
David Collodel <dave@crawlspaceradio.com>