Forward to DMZ addresses

Forward to DMZ addresses

[jonathan]

I have a machine that I using as a firewall, separting WAN / LAN / DMZ

Rules thus far are to NAT all outgoing packets that come in from the LAN
interface.

From the machine itself, I can ping machines on my DMZ interface (eth2)
and my LAN interface (eth0)

I'm having trouble getting through the firewall to my DMZ machines, but I
can access the NIC that routes to the DMZ machine via SSH...  I've tried
various forwarding rules, and even changed the default FORWARD policy to
ACCEPT anything.  Here is a basic rule I'm trying:

#eth1 = WAN NIC
#eth2 = DMZ NIC
iptables -A FORWARD -i eth1 -o eth2 -d xx.xx.xx.xx  -p tcp --dport 22 -j
ACCEPT

now, if I do a netstat on the firewall nothing... if I do a netstat on the
machine I'm attempting to connect from... all I see is SYN_SENT

**I'm trying from external machines...i.e. machines not on my network.

physical network is

router -> vlan -> firewall -> DMZ
router -> vlan -> firewall -> LAN

I can also access the DMZ machine via the firewall itself and vice versa,
but once logged into the DMZ machine, I can't get to anything past the
firewall.  I have the following rules for that

iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT

Kinda confused here...

the LAN stuff works... at least for now... to simply forward the packets
out through the WAN NIC and NAT them...

*shrug*

Re: Forward to DMZ addresses

[Grant Taylor]

Jonathan, are you needing to add a rule to your nat table PREROUTING chain to cause any (ssh) traffic that is destined to your firewall's WAN interface to be redirected over to your DMZ server?  If so you just need to add a rule like this:

iptables -t nat -A PREROUTING -i eth1 -d xx.xx.xx.xx -p tcp --dport 22 -j DNAT --to-destination yy.yy.yy.yy

Where xx.xx.xx.xx is your globally routable WAN IP and yy.yy.yy.yy is the IP of your DMZ server.



Grant. . . .

jonathan@innovativesource.net wrote:
> I have a machine that I using as a firewall, separting WAN / LAN / DMZ
> 
> Rules thus far are to NAT all outgoing packets that come in from the LAN
> interface.
> 
>>From the machine itself, I can ping machines on my DMZ interface (eth2)
> and my LAN interface (eth0)
> 
> I'm having trouble getting through the firewall to my DMZ machines, but I
> can access the NIC that routes to the DMZ machine via SSH...  I've tried
> various forwarding rules, and even changed the default FORWARD policy to
> ACCEPT anything.  Here is a basic rule I'm trying:
> 
> #eth1 = WAN NIC
> #eth2 = DMZ NIC
> iptables -A FORWARD -i eth1 -o eth2 -d xx.xx.xx.xx  -p tcp --dport 22 -j
> ACCEPT
> 
> now, if I do a netstat on the firewall nothing... if I do a netstat on the
> machine I'm attempting to connect from... all I see is SYN_SENT
> 
> **I'm trying from external machines...i.e. machines not on my network.
> 
> physical network is
> 
> router -> vlan -> firewall -> DMZ
> router -> vlan -> firewall -> LAN
> 
> I can also access the DMZ machine via the firewall itself and vice versa,
> but once logged into the DMZ machine, I can't get to anything past the
> firewall.  I have the following rules for that
> 
> iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT
> 
> Kinda confused here...
> 
> the LAN stuff works... at least for now... to simply forward the packets
> out through the WAN NIC and NAT them...
> 
> *shrug*

Re: Forward to DMZ addresses

[jonathan]

Kind of... I'm trying to redirect _any_ traffic destined for my DMZ
address to be forwarded to the machines themselves.  I tried the rule you
suggested, and I also realized that I had already tried that.

Basically, I want to forward any traffic destined for DMZ address pass the
firewall and onto the DMZ machines themselves, well once they gone through
some bad packet checks...

FYI, the rule didn't work as expected.  The following is my script thus far:

#************************************
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe iptable_filter
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_REJECT
/sbin/modprobe ipt_state

#
# Enable IP forwarding
#

echo "1" > /proc/sys/net/ipv4/ip_forward

$ipt -F
$ipt -X
$ipt -Z


$ipt -P INPUT DROP
$ipt -P OUTPUT ACCEPT
$ipt -P FORWARD DROP

###########################################
#
# Rules
#

#
# Accept EST. and REL. packets
#
$ipt -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# Forward all from LAN through WAN
#
$ipt -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -j ACCEPT

#
# NAT all outgoing packets
#
$ipt -t nat -A POSTROUTING -o $WAN_INTERFACE  -j SNAT --to-source $WAN_IP

#
# temp - this does the actual allowing of outgoing packets
# from the dmz server... but it still nat's them... I don't want to nat
# them, I want them to appear as they are
#
$ipt -A FORWARD -i $DMZ_INTERFACE -o $WAN_INTERFACE -j ACCEPT
############################################################
#
# Firewall specific rules
#

#
# Allow access from LAN to firewall
#
$ipt -A INPUT -i $LAN_INTERFACE -j ACCEPT

#
# Save rules
#
/etc/init.d/iptables save

#************************************

this is basic, as I'm trying to take it one step at a time.  I'm currently
dealing with 2 issues.  the one mentioned above...and the other is not
NATing the outgoing DMZ packets...  I would like them to go out with their
IP addresses...


> Jonathan, are you needing to add a rule to your nat table PREROUTING chain
> to cause any (ssh) traffic that is destined to your firewall's WAN
> interface to be redirected over to your DMZ server?  If so you just need
> to add a rule like this:
>
> iptables -t nat -A PREROUTING -i eth1 -d xx.xx.xx.xx -p tcp --dport 22 -j
> DNAT --to-destination yy.yy.yy.yy
>
> Where xx.xx.xx.xx is your globally routable WAN IP and yy.yy.yy.yy is the
> IP of your DMZ server.
>
>
>
> Grant. . . .
>
> jonathan@innovativesource.net wrote:
>> I have a machine that I using as a firewall, separting WAN / LAN / DMZ
>>
>> Rules thus far are to NAT all outgoing packets that come in from the LAN
>> interface.
>>
>>>From the machine itself, I can ping machines on my DMZ interface (eth2)
>> and my LAN interface (eth0)
>>
>> I'm having trouble getting through the firewall to my DMZ machines, but
>> I
>> can access the NIC that routes to the DMZ machine via SSH...  I've tried
>> various forwarding rules, and even changed the default FORWARD policy to
>> ACCEPT anything.  Here is a basic rule I'm trying:
>>
>> #eth1 = WAN NIC
>> #eth2 = DMZ NIC
>> iptables -A FORWARD -i eth1 -o eth2 -d xx.xx.xx.xx  -p tcp --dport 22 -j
>> ACCEPT
>>
>> now, if I do a netstat on the firewall nothing... if I do a netstat on
>> the
>> machine I'm attempting to connect from... all I see is SYN_SENT
>>
>> **I'm trying from external machines...i.e. machines not on my network.
>>
>> physical network is
>>
>> router -> vlan -> firewall -> DMZ
>> router -> vlan -> firewall -> LAN
>>
>> I can also access the DMZ machine via the firewall itself and vice
>> versa,
>> but once logged into the DMZ machine, I can't get to anything past the
>> firewall.  I have the following rules for that
>>
>> iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT
>>
>> Kinda confused here...
>>
>> the LAN stuff works... at least for now... to simply forward the packets
>> out through the WAN NIC and NAT them...
>>
>> *shrug*
>
>

Re: Forward to DMZ addresses

[Grant Taylor]

jonathan@innovativesource.net wrote:
> Kind of... I'm trying to redirect _any_ traffic destined for my DMZ
> address to be forwarded to the machines themselves.  I tried the rule you
> suggested, and I also realized that I had already tried that.
> 
> Basically, I want to forward any traffic destined for DMZ address pass the
> firewall and onto the DMZ machines themselves, well once they gone through
> some bad packet checks...

Ok, if you are wanting all traffic to be destined you will need to statefully inspect packets and return them to your LAN accordingly before you forward the traffic off to your DMZ server.  That is unless you have a different globally routable IP for your DMZ system than you do for your router.

You will probably need to DNAT in the PREROUTING chain for both inbound interfaces, your LAN and WAN connection.

> FYI, the rule didn't work as expected.  The following is my script thus far:
> 
> #************************************
> /sbin/modprobe ip_tables
> /sbin/modprobe ip_conntrack
> /sbin/modprobe ip_conntrack_ftp
> /sbin/modprobe iptable_filter
> /sbin/modprobe ipt_LOG
> /sbin/modprobe ipt_limit
> /sbin/modprobe iptable_nat
> /sbin/modprobe ipt_REJECT
> /sbin/modprobe ipt_state
> 
> #
> # Enable IP forwarding
> #
> 
> echo "1" > /proc/sys/net/ipv4/ip_forward
> 
> $ipt -F
> $ipt -X
> $ipt -Z
> 
> 
> $ipt -P INPUT DROP
> $ipt -P OUTPUT ACCEPT
> $ipt -P FORWARD DROP
> 
> ###########################################
> #
> # Rules
> #
> 
> #
> # Accept EST. and REL. packets
> #
> $ipt -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> $ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> #
> # Forward all from LAN through WAN
> #
> $ipt -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -j ACCEPT
> 
> #
> # NAT all outgoing packets
> #
> $ipt -t nat -A POSTROUTING -o $WAN_INTERFACE  -j SNAT --to-source $WAN_IP

If your LAN is on a different subnet you could add an "-s <LAN subnet>" extension to this to make sure that you are only SNATing your LAN traffic.

> #
> # temp - this does the actual allowing of outgoing packets
> # from the dmz server... but it still nat's them... I don't want to nat
> # them, I want them to appear as they are
> #
> $ipt -A FORWARD -i $DMZ_INTERFACE -o $WAN_INTERFACE -j ACCEPT
> ############################################################
> #
> # Firewall specific rules
> #
> 
> #
> # Allow access from LAN to firewall
> #
> $ipt -A INPUT -i $LAN_INTERFACE -j ACCEPT
> 
> #
> # Save rules
> #
> /etc/init.d/iptables save
> 
> #************************************
> 
> this is basic, as I'm trying to take it one step at a time.  I'm currently
> dealing with 2 issues.  the one mentioned above...and the other is not
> NATing the outgoing DMZ packets...  I would like them to go out with their
> IP addresses...

I take it that your DMZ system is running a globally routable IP?  If this is the case can we get a list of said IPs (scrubbed if need be) for discussion?



Grant. . . .

Re: Forward to DMZ addresses

[Jonathan Villa]

> jonathan@innovativesource.net wrote:
>> Kind of... I'm trying to redirect _any_ traffic destined for my DMZ
>> address to be forwarded to the machines themselves.  I tried the rule
>> you
>> suggested, and I also realized that I had already tried that.
>>
>> Basically, I want to forward any traffic destined for DMZ address pass
>> the
>> firewall and onto the DMZ machines themselves, well once they gone
>> through
>> some bad packet checks...
>
> Ok, if you are wanting all traffic to be destined you will need to
> statefully inspect packets and return them to your LAN accordingly before
> you forward the traffic off to your DMZ server.  That is unless you have a
> different globally routable IP for your DMZ system than you do for your
> router.
>
> You will probably need to DNAT in the PREROUTING chain for both inbound
> interfaces, your LAN and WAN connection.
>

What would I DNAT (--to-source) to.  My understanding is to check for
ESTABLISHED,RELATED state and forward onto either LAN/DMZ interface, but
how do I receive where -to-source should be?

>> FYI, the rule didn't work as expected.  The following is my script thus
>> far:
>>
>> #************************************
>> /sbin/modprobe ip_tables
>> /sbin/modprobe ip_conntrack
>> /sbin/modprobe ip_conntrack_ftp
>> /sbin/modprobe iptable_filter
>> /sbin/modprobe ipt_LOG
>> /sbin/modprobe ipt_limit
>> /sbin/modprobe iptable_nat
>> /sbin/modprobe ipt_REJECT
>> /sbin/modprobe ipt_state
>>
>> #
>> # Enable IP forwarding
>> #
>>
>> echo "1" > /proc/sys/net/ipv4/ip_forward
>>
>> $ipt -F
>> $ipt -X
>> $ipt -Z
>>
>>
>> $ipt -P INPUT DROP
>> $ipt -P OUTPUT ACCEPT
>> $ipt -P FORWARD DROP
>>
>> ###########################################
>> #
>> # Rules
>> #
>>
>> #
>> # Accept EST. and REL. packets
>> #
>> $ipt -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>> $ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> #
>> # Forward all from LAN through WAN
>> #
>> $ipt -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -j ACCEPT
>>
>> #
>> # NAT all outgoing packets
>> #
>> $ipt -t nat -A POSTROUTING -o $WAN_INTERFACE  -j SNAT --to-source
>> $WAN_IP
>
> If your LAN is on a different subnet you could add an "-s <LAN subnet>"
> extension to this to make sure that you are only SNATing your LAN traffic.
>

Ah...thanks.  Didn't think about that

>> #
>> # temp - this does the actual allowing of outgoing packets
>> # from the dmz server... but it still nat's them... I don't want to nat
>> # them, I want them to appear as they are
>> #
>> $ipt -A FORWARD -i $DMZ_INTERFACE -o $WAN_INTERFACE -j ACCEPT
>> ############################################################
>> #
>> # Firewall specific rules
>> #
>>
>> #
>> # Allow access from LAN to firewall
>> #
>> $ipt -A INPUT -i $LAN_INTERFACE -j ACCEPT
>>
>> #
>> # Save rules
>> #
>> /etc/init.d/iptables save
>>
>> #************************************
>>
>> this is basic, as I'm trying to take it one step at a time.  I'm
>> currently
>> dealing with 2 issues.  the one mentioned above...and the other is not
>> NATing the outgoing DMZ packets...  I would like them to go out with
>> their
>> IP addresses...
>
> I take it that your DMZ system is running a globally routable IP?  If this
> is the case can we get a list of said IPs (scrubbed if need be) for
> discussion?
>
>
IP Network = xx.xx.xx.182
Router WAN interface = xx.yyy.y.241
Router LAN interface = xx.xx.xx.183
Firewall eth0 connected to LAN switch = 10.123.x.x
Firewall eth1 connected to router = xx.xx.xx.184
Firewall eth2 connected to DMZ switch = xx.xx.xx.185
DMZ server eth0 connected to DMZ switch = xx.xx.xx.186

LAN stuff works just fine...well, at least from what I can tell and it's
the only section with local IP's.  The others are all using globally
routable IP's from my block.

Currently, and as stated before, I can access everything from the firewall
itself, just can't pass through.

**Once I get a basic setup going, I should be able to figure it out...
it's just this hurdle right now

Re: Forward to DMZ addresses

[Grant Taylor]

> What would I DNAT (--to-source) to.  My understanding is to check for
> ESTABLISHED,RELATED state and forward onto either LAN/DMZ interface, but
> how do I receive where -to-source should be?

If you have a DNATing rule set up for traffic that is destined to your DMZ server coming in to your router on eth1 as such:

iptables -t nat -A PREROUTING -i ${WAN} -d ${ExternalIP} -j DNAT --to-destination ${DMZServerIP}
iptables -t filter -A FORWARD -i ${WAN} -o ${DMZ} -d ${DMZServerIP} -j ACCEPT
iptables -t filter -A FORWARD -i ${DMZ} -o ${WAN} -s ${DMZServerIP} -j ACCEPT

You will need something similar to this as well:

iptables -t nat -A PREROUTING -i ${LAN} -d ${ExternalIP} -j DNAT --to-destination ${DMZServerIP}
iptables -t filter -A FORWARD -i ${LAN} -o ${DMZ} -d ${DMZServerIP} -j ACCEPT
iptables -t filter -A FORWARD -i ${DMZ} -o ${LAN} -s ${DMZServerIP} -j ACCEPT

The idea behind this is that you are DNATing the traffic that is coming in from the world.  When you try to access your ""servers (globally routable) IP from your LAN your traffic will be coming in the interface connected to your LAN (eth0) and thus not match the first rule above.  This is why you need a similar rule to match on traffic that is coming in on your LAN interface.

Note:  I went ahead and explicitly included rules for the FORWARD chain in the filter table that may be covered under a different rule, use your discression on these.

> Ah...thanks.  Didn't think about that

No problem.  Ideas is what this list is for.

> IP Network = xx.xx.xx.182
> Router WAN interface = xx.yyy.y.241
> Router LAN interface = xx.xx.xx.183
> Firewall eth0 connected to LAN switch = 10.123.x.x
> Firewall eth1 connected to router = xx.xx.xx.184
> Firewall eth2 connected to DMZ switch = xx.xx.xx.185
> DMZ server eth0 connected to DMZ switch = xx.xx.xx.186

# Let's handle any outgoing and returning LAN traffic.
iptables -t filter -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -i eth0 -o eth1 -j ACCEPT
# Presumably any traffic returning from outbound requests will be in a state of established (or related) and thus is not destined to the DMZ server.
# I think this situation will be taken care of inherently.

# Let's forward any (NEW or RELATED) traffic coming in to the WAN IP from the world over to the DMZ server.
iptables -t nat -A PREROUTING -i eth1 -d xx.yy.yy.240 -m state --state NEW,RELATED -j DNAT --to-destination xx.xx.xx.186
iptables -t filter -A FORWARD -i eth1 -o eth2 -d xx.xx.xx.186 -j ACCEPT
iptables -t filter -A FORWARD -i eth2 -o eth1 -s xx.xx.xx.186 -j ACCEPT

# Let's forward any traffic coming in to the WAN IP from the LAN over to the DMZ server.
iptables -t nat -A PREROUTING -i eth0 -d xx.yy.yy.240 -j DNAT --to-destination xx.xx.xx.186
iptables -t filter -A FORWARD -i eth0 -o eth2 -d xx.xx.xx.186 -j ACCEPT
iptables -t filter -A FORWARD -i eth2 -o eth0 -s xx.xx.xx.186 -j ACCEPT

# We need to SNAT the traffic out to the world.
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xx.yy.yy.240


> LAN stuff works just fine...well, at least from what I can tell and it's
> the only section with local IP's.  The others are all using globally
> routable IP's from my block.
> 
> Currently, and as stated before, I can access everything from the firewall
> itself, just can't pass through.
> 
> **Once I get a basic setup going, I should be able to figure it out...
> it's just this hurdle right now

*nod*

Re: Forward to DMZ addresses

[Jonathan Villa]

>> What would I DNAT (--to-source) to.  My understanding is to check for
>> ESTABLISHED,RELATED state and forward onto either LAN/DMZ interface, but
>> how do I receive where -to-source should be?
>
> If you have a DNATing rule set up for traffic that is destined to your DMZ
> server coming in to your router on eth1 as such:
>
> iptables -t nat -A PREROUTING -i ${WAN} -d ${ExternalIP} -j DNAT
> --to-destination ${DMZServerIP}
> iptables -t filter -A FORWARD -i ${WAN} -o ${DMZ} -d ${DMZServerIP} -j
> ACCEPT
> iptables -t filter -A FORWARD -i ${DMZ} -o ${WAN} -s ${DMZServerIP} -j
> ACCEPT
>
> You will need something similar to this as well:
>
> iptables -t nat -A PREROUTING -i ${LAN} -d ${ExternalIP} -j DNAT
> --to-destination ${DMZServerIP}
> iptables -t filter -A FORWARD -i ${LAN} -o ${DMZ} -d ${DMZServerIP} -j
> ACCEPT
> iptables -t filter -A FORWARD -i ${DMZ} -o ${LAN} -s ${DMZServerIP} -j
> ACCEPT
>
> The idea behind this is that you are DNATing the traffic that is coming in
> from the world.  When you try to access your ""servers (globally routable)
> IP from your LAN your traffic will be coming in the interface connected to
> your LAN (eth0) and thus not match the first rule above.  This is why you
> need a similar rule to match on traffic that is coming in on your LAN
> interface.
>
> Note:  I went ahead and explicitly included rules for the FORWARD chain in
> the filter table that may be covered under a different rule, use your
> discression on these.
>
>> Ah...thanks.  Didn't think about that
>
> No problem.  Ideas is what this list is for.
>
>> IP Network = xx.xx.xx.182
>> Router WAN interface = xx.yyy.y.241
>> Router LAN interface = xx.xx.xx.183
>> Firewall eth0 connected to LAN switch = 10.123.x.x
>> Firewall eth1 connected to router = xx.xx.xx.184
>> Firewall eth2 connected to DMZ switch = xx.xx.xx.185
>> DMZ server eth0 connected to DMZ switch = xx.xx.xx.186
>
> # Let's handle any outgoing and returning LAN traffic.
> iptables -t filter -A FORWARD -i eth1 -o eth0 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables -t filter -A FORWARD -i eth0 -o eth1 -j ACCEPT
> # Presumably any traffic returning from outbound requests will be in a
> state of established (or related) and thus is not destined to the DMZ
> server.
> # I think this situation will be taken care of inherently.
>
> # Let's forward any (NEW or RELATED) traffic coming in to the WAN IP from
> the world over to the DMZ server.
> iptables -t nat -A PREROUTING -i eth1 -d xx.yy.yy.240 -m state --state
> NEW,RELATED -j DNAT --to-destination xx.xx.xx.186
> iptables -t filter -A FORWARD -i eth1 -o eth2 -d xx.xx.xx.186 -j ACCEPT
> iptables -t filter -A FORWARD -i eth2 -o eth1 -s xx.xx.xx.186 -j ACCEPT
>
> # Let's forward any traffic coming in to the WAN IP from the LAN over to
> the DMZ server.
> iptables -t nat -A PREROUTING -i eth0 -d xx.yy.yy.240 -j DNAT
> --to-destination xx.xx.xx.186
> iptables -t filter -A FORWARD -i eth0 -o eth2 -d xx.xx.xx.186 -j ACCEPT
> iptables -t filter -A FORWARD -i eth2 -o eth0 -s xx.xx.xx.186 -j ACCEPT
>
> # We need to SNAT the traffic out to the world.
> iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xx.yy.yy.240
>
>
>> LAN stuff works just fine...well, at least from what I can tell and it's
>> the only section with local IP's.  The others are all using globally
>> routable IP's from my block.
>>
>> Currently, and as stated before, I can access everything from the
>> firewall
>> itself, just can't pass through.
>>
>> **Once I get a basic setup going, I should be able to figure it out...
>> it's just this hurdle right now
>


Ok, I'm starting to see the logic...I think

I'm not sure about 2 of the examples

iptables -t nat -A PREROUTING -i ${WAN} -d ${ExternalIP} -j DNAT
--to-destination
${DMZServerIP}

Is $ExternalIP the external IP of the firewall or the dmz machine?

and then...

iptables -t filter -A FORWARD -i ${DMZ} -o ${LAN} -s ${DMZServerIP} -j ACCEPT

I'm understanding this as "all any packets from the DMZ to the LAN".  I
would prefer to not allow DMZ->LAN, i.e. using FORWARD, could I not do

iptables -t filter -A FORWARD -i ${DMZ} -o ${LAN} -m state --state
ESTABLISHED,RELATED -s ${DMZServerIP} -j ACCEPT

**normally I would just try it, but I'm not near the server right now...

and then the final SNAT

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xx.yy.yy.240

wouldn't this SNAT everything outgoing, even the DMZ traffic?  I'll have
about 5 servers on the DMZ once this is all working

Re: Forward to DMZ addresses

[Taylor, Grant]

Disclaimer:  I'm at the office and I can not give a proper reply now so more will follow later.

> Ok, I'm starting to see the logic...I think
> 
> I'm not sure about 2 of the examples
> 
> iptables -t nat -A PREROUTING -i ${WAN} -d ${ExternalIP} -j DNAT
> --to-destination
> ${DMZServerIP}
> 
> Is $ExternalIP the external IP of the firewall or the dmz machine?

Umm...  I have, possibly incorrectly, been operating under the assumption that they were one in the same.  I was believing that you were wanting your firewall, with the ExternalIP, to forward any traffic that was not related to your LAN's internet traffic over to your DMZ server.  Thus I was going that route for a solution.  Let me go reread what you have sent. ... (reading) ... Ok, see if you agree with how I'm restating what you said earlier.

     Router WAN interface = xx.yy.yy.241
     Router LAN connected to DMZ switch = xx.xx.xx.183 (IP Network = xx.xx.xx.182)

  Firewall eth1 connected to ?????????? = xx.xx.xx.184 (IP Network = xx.xx.xx.182)
  Firewall eth2 connected to DMZ switch = xx.xx.xx.185 (IP Network = xx.xx.xx.182)
DMZ server eth0 connected to DMZ switch = xx.xx.xx.186 (IP Network = xx.xx.xx.182)

  Firewall eth0 connected to LAN switch = 10.123.x.x

As I'm looking (closer) at what you said earlier I have a question.  You say that eth1 on your firewall is connected to your router.  Is that connection via a cross over cable or via a cable plugged in to the the DMZ switch?  If eth1 is connected to the DMZ switch what is the difference between eth1 and eth2 on your firewall?  I'm sort of believing that eth1 is connected to the router via a cross over cable and yet the router and the DMZ systems are on the same IP subnet, or at least it appears that way from the IPs that each piece of equipment has.

Do you have a subnet of IPs or just a handful of IPs allocated to you by your provider that are accessible via the xx.yy.yy.241 IP?  I have a feeling that part of your problem is that you are trying to break routing by using routing.  If you are wanting to break routing you will need to bridge some things together.  However I don't think you do have a block of IP addresses unless you have a block of 16 that ends with 191 being the broadcast IP (xx.xx.xx.176-191).  Depending on what you have and what you want to achieve decides the way that this problem can be solved.  The more that I look at it the more it looks like you have a circuit from a provider who has provided you with a small group of IPs.  Is this the case?  Are the IPs in question in a subnet or just a scattering of them?

> iptables -t filter -A FORWARD -i ${DMZ} -o ${LAN} -s ${DMZServerIP} -j ACCEPT
> 
> I'm understanding this as "all any packets from the DMZ to the LAN".  I
> would prefer to not allow DMZ->LAN, i.e. using FORWARD, could I not do
> 
> iptables -t filter -A FORWARD -i ${DMZ} -o ${LAN} -m state --state
> ESTABLISHED,RELATED -s ${DMZServerIP} -j ACCEPT

Yes you could do that with out any problem.  Most of my clients want full access to their DMZ systems and they also want them to have full access to their LAN yet they want them on a different subnet.

> **normally I would just try it, but I'm not near the server right now...

*nod*  I understand completely.

> iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xx.yy.yy.240
> 
> wouldn't this SNAT everything outgoing, even the DMZ traffic?  I'll have
> about 5 servers on the DMZ once this is all working

I think this question may become a moot point once you answer my question(s) above.  This had to do with me thinking that your ExternalIP and the IP of the firewall system were one in the same.



Grant. . . .

Re: Forward to DMZ addresses

[Jonathan Villa]

> Disclaimer:  I'm at the office and I can not give a proper reply now so
> more will follow later.

Understand completely and appreciate the time taken.

> Is $ExternalIP the external IP of the firewall or the dmz machine?
>
> Umm...  I have, possibly incorrectly, been operating under the assumption
> that they were one in the same.  I was believing that you were wanting
> your firewall, with the ExternalIP, to forward any traffic that was not
> related to your LAN's internet traffic over to your DMZ server.  Thus I
> was going that route for a solution.  Let me go reread what you have sent.
> ... (reading) ... Ok, see if you agree with how I'm restating what you
> said earlier.
>
>      Router WAN interface = xx.yy.yy.241
>      Router LAN connected to DMZ switch = xx.xx.xx.183 (IP Network =
> xx.xx.xx.182)

This may have been a type on my end, LAN is connected to a LAN Switch

>
>   Firewall eth1 connected to ?????????? = xx.xx.xx.184 (IP Network =
> xx.xx.xx.182)

connected to router

>   Firewall eth2 connected to DMZ switch = xx.xx.xx.185 (IP Network =
> xx.xx.xx.182)
> DMZ server eth0 connected to DMZ switch = xx.xx.xx.186 (IP Network =
> xx.xx.xx.182)
>
>   Firewall eth0 connected to LAN switch = 10.123.x.x
>
> As I'm looking (closer) at what you said earlier I have a question.  You
> say that eth1 on your firewall is connected to your router.  Is that
> connection via a cross over cable or via a cable plugged in to the the DMZ
> switch?


  router
    |
  VLAN Switch
    |
 firewall
  |    |
  |    |
 LAN  DMZ


So, it's a cable plugged into the VLAN switch.


>If eth1 is connected to the DMZ switch what is the difference
> between eth1 and eth2 on your firewall?

eth1 is connected to the router and eth2 is connected to the DMZ switch.

>I'm sort of believing that eth1
> is connected to the router via a cross over cable and yet the router and
> the DMZ systems are on the same IP subnet, or at least it appears that way
> from the IPs that each piece of equipment has.

Yes, they are on the same subnect.  Not sure if it's a cross over cable.

> Do you have a subnet of IPs or just a handful of IPs allocated to you by
> your provider that are accessible via the xx.yy.yy.241 IP?  I have a
> feeling that part of your problem is that you are trying to break routing
> by using routing.  If you are wanting to break routing you will need to
> bridge some things together.  However I don't think you do have a block of
> IP addresses unless you have a block of 16 that ends with 191 being the
> broadcast IP (xx.xx.xx.176-191).

I changed my IP's a little :) ...I do have a block of 16.  The actual
broadcast is 207 and the network is 192. or at least that I have for
ifcfg-eth0 - (NETWORK=xx.xx.xx.192)

>Depending on what you have and what you
> want to achieve decides the way that this problem can be solved.  The more
> that I look at it the more it looks like you have a circuit from a
> provider who has provided you with a small group of IPs.  Is this the
> case?  Are the IPs in question in a subnet or just a scattering of them?
>
subnet...

my firewall has 3 NIC's.  one connected to the router (well the VLAN
switch) which has an IP of 194.  the router is 193.  the dmz nic (eth2) is
195, the LAN is, well the LAN.  On my DMZ, I plan to provide static
address which are globally routable and from my subnet.

Sorry if I'm not making any sense... haven't had much sleep...

I've been trying a few rules here and there trying to get something to
work... but to no avail.

Re: Forward to DMZ addresses

[Grant Taylor]

>   router
>     |
>   VLAN Switch
>     |
>  firewall
>   |    |
>  LAN  DMZ

>>I'm sort of believing that eth1
>>is connected to the router via a cross over cable and yet the router and
>>the DMZ systems are on the same IP subnet, or at least it appears that way
>>from the IPs that each piece of equipment has.

> Yes, they are on the same subnect.  Not sure if it's a cross over cable.

Ok, if I am reading you correctly now, your router's internal interface that is connected to the VLAN switch has an IP that is on the same subnet as the servers that will be in the DMZ.  I.e. the router in question will be the router for the DMZ servers.  I was thinking that your firewall was going to be a firewalling router that would handle your LAN and DMZ networks.  However now I do not think that this is the case.

> I changed my IP's a little :) ...I do have a block of 16.  The actual
> broadcast is 207 and the network is 192. or at least that I have for
> ifcfg-eth0 - (NETWORK=xx.xx.xx.192)

Ok, I have a feeling that when you were typeing xx.xx.xx.182 you were really meaning to type xx.xx.xx.192.  Key shift, that's fine.  But that does go to explain the interesting IPs.  No harm no foul.  :)  I think we are on the same page of the same book now.

>>Are the IPs in question in a subnet or just a scattering of them?
> 
> subnet...

This is becoming more and more apparent all the time.  This is part of the problem which leads to what I think will be the ultimate solution.  (See below)

> my firewall has 3 NIC's.  one connected to the router (well the VLAN
> switch) which has an IP of 194.  the router is 193.  the dmz nic (eth2) is
> 195, the LAN is, well the LAN.  On my DMZ, I plan to provide static
> address which are globally routable and from my subnet.

*nod*  I think I see where you are going with this and I'm going to propose a wild change to accommodate what you are wanting to do.  (See below)  (I know I keep saying that but it is a doosey.)

> Sorry if I'm not making any sense... haven't had much sleep...

Actually you are making more sense now than you have been all along.  No offense intended.  You have just explained that what you are wanting to do can not be done with routing.

> I've been trying a few rules here and there trying to get something to
> work... but to no avail.

*nod*  I think I know why.  Let me try to explain.

(this is below) (yes we finally made it)

I think what you are wanting to do can not be done with traditional OSI Layer 3 routing but rather needs to be done with OSI Layer 2 bridging / switching.  If I understand what you are wanting correctly to be the following:

1)  You want your router to be the router for all your systems behind it (LAN is the exception) no matter where they are physically connected to.
2)  You want the same subnet xx.xx.xx.192/28 to be on both sides of your firewall (eth1 and eth2).
3)  You want your LAN to appear to come from one of the IPs in your DMZ.
4)  You want to prevent any of the other systems in the DMZ from getting to them directly.

If this is indeed the case what I propose you do is create a bridge on your firewall and use EBTables to do most of your firewalling for your DMZ systems except for the LAN.  This would allow your systems in the DMZ to be on the same subnet as the router's internal interface and talk as if they were on the same physical LAN.  However as you will be passing the traffic through a Linux bridge you will be able to do some basic firewalling on them, namely protocol, source / destination IP, as well as source / destination port.  EBTables does not do much beyond that for filtering but I think that is about all that you are wanting your firewall to do.  You ultimately would use IPTables to handle the 2nd level of firewalling (beyond EBTables) for your LAN which will allow you to do more advanced things like connection tracking and Stateful Packet Inspection (SPI).

Below is a (very) rough draft of the config / startup scripts that I would write to make this happen.  You will not really need an IP for eth1 or eth2 in this model of firewalling.  I think you will see why below.

eth0 = LAN
eth1 = Router
eth2 = DMZ

# We have to bring up the ether interfaces before we can set up the bridge.
ifconfig eth1 0.0.0.0 up
ifconfig eth2 0.0.0.0 up

# Let's establish the bridge first and then we will worry about the IPTables firewalling.
brctl addbr bri0
sleep 1 # Prevent race conditions in the kernel.
brctl addif bri0 eth1
sleep 1
brctl addif bri0 eth2

# You will need to pick an IP to assign to your bri0 interface for the LAN to use to communicate with the world.
# Here are the IP assignments that I'm going to use for the sake of the discussion, all of which are in the DMZ.
#   Network = xx.xx.xx.192/28
#    Router = xx.xx.xx.193/28
#  LAN bri0 = xx.xx.xx.194/28
# DMZ boxen = xx.xx.xx.195-206/28
# Broadcast = xx.xx.xx.207/28

# Let's assign an IP to the bri0 interface to be the ""external interface of your pseudo LAN router.
ifconfig bri0 xx.xx.xx.194 netmask 255.255.255.240 broadcast xx.xx.xx.207 up

# You will need to have an IP subnet for your LAN.  I'm going to assume aa.bb.cc.dd/24.
#   Network = aa.bb.cc.0/24
#    Router = aa.bb.cc.1/24
#   Clients = aa.bb.cc.2-254/24
# Broadcast = aa.bb.cc.255/24

# Let's assing an IP to the eth0 interface 
ifconfig eth0 aa.bb.cc.1 netmask 255.255.255.0 broadcast aa.bb.cc.255 up

At this point we have a logical switched (bridged) network that includes the router (xx.xx.xx.193), your pseudo LAN router (xx.xx.xx.194) as well as all your DMZ systems (xx.xx.xx.195-206).  The logical router is going to use the bri0 interface to connect to the DMZ network so it can easily communicate with the world via the router or to the other DMZ servers.

So now we start setting up the various levels of firewalling.  To do this on the OSI Layer 2 we will use EBTables.  We will use IPTables for the OSI Layer 3 firewalling as you would expect.

# First let's do some basic source / destination IP validation.  See RFC 3330 (http://www.rfc-editor.org/rfc/rfc3330.txt) for more information.
# Let's validate inbound source IPs by weeding out known bad source IPs.
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 10.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 127.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 169.254.0.0/12 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 172.16.0.0/16 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 192.0.2.0/24 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 192.168.0.0/16 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 255.255.255.255/32 -j DROP

# Let's make sure that the traffic is acctually to our network.
ebtables -t filter -A FORWARD -i eth1 -p ipvr --ip-dst ! xx.xx.xx.192/28 -j DROP

# Let's validate outbound destination IPs by weeding out known bad destination IPs.
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 10.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 127.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 169.254.0.0/12 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 172.16.0.0/16 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 192.0.2.0/24 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 192.168.0.0/16 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 255.255.255.255/32 -j DROP

# For paranoia sake let's make sure that we are not sending any bad source IPs too.
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 10.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 127.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 169.254.0.0/12 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 172.16.0.0/16 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 192.0.2.0/24 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 192.168.0.0/16 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 255.255.255.255/32 -j DROP

# If the traffic has made it this far we can be fairly confident that the source and or destination IPs are reasonable.

# If you want to do some additional filtering for a particular host you would do it as such:

# Host 195 is a web server only and thus will not answer DNS or SMTP traffic.
ebtables -t filter -N HOST195
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-dst xx.xx.xx.195 -j HOST195
ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto tcp --ip-dport 25 -j DROP
ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto udp --ip-dport 53 -j DROP
ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto tcp --ip-dport 53 -j DROP

# Host 196 could be DNS ONLY and will not have ANY other traffic AT all, well save SSH of course.
ebtables -t filter -N HOST196
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-dst xx.xx.xx.196 -j HOST196
ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto tcp --ip-dport 22 -j ACCEPT
ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto udp --ip-dport 53 -j ACCEPT
ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto tcp --ip-dport 53 -j ACCEPT
ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto icmp -j ACCEPT
ebtables -t filter -A HOST196 -i eth1 -j DROP

# I think you get the idea.

Now we can be fairly confident that the basic OSI Layer 2 firewalling will make sure that nothing blatantly stupid is going on.  Thus we are left with the OSI Layer 3 firewalling for the LAN.

# Let's set up some sensible defaults.
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

# Let's enable basic forwarding.
iptables -t filter -A FORWARD -i bri0 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -i eth0 -o bri0 -j ACCEPT

# Let's set up the SNATing for our outbound LAN traffic.
iptables -t nat -A POSTROUTING -o bri0 -j SNAT --to-source xx.xx.xx.194

# I'd like to be able to RDP to the office 2k3 server (accounting has a Windows only program!)
iptables -t nat -A PREROUTING -i bri0 -p tcp --dport 3389 -j DNAT --to-destination aa.bb.cc.2
iptables -t filter -A FORWARD -i bri0 -o eth0 -p tcp -d aa.bb.cc.2 --dport 3389 -j ACCEPT

I think this will take care of most of the firewalling on both OSI Layers 2 and 3 like I think you are needing.  I know that this is a rather lengthy email, but what you are asking is not a simple thing to solve.  Fortunately Linux should be very capable of providing for you.  Once you realize that what (I think) you are trying to do can not be done on OSI Layer 3 you will see why you could not find a solution with all the various things you / we have tried / proposed to do.

Any way, chew on this and (please) let me know what you think.



Grant. . . .

Re: Forward to DMZ addresses

[Jonathan Villa]

First, grrr.... I just wrote a nice lengthy reply but my webmail session
timed out and I lost it...let's see if I can remember everything I wrote

>>   router
>>     |
>>   VLAN Switch
>>     |
>>  firewall
>>   |    |
>>  LAN  DMZ
>
> Ok, if I am reading you correctly now, your router's internal interface
>that is connected to the VLAN switch has an IP that is on the same subnet
> as the servers that will be in the DMZ.

Yes.  You're correct

>I.e. the router in question will
> be the router for the DMZ servers.  I was thinking that your firewall
>was going to be a firewalling router that would handle your LAN and DMZ
networks.  However now I do not think that this is the case.

Actually, it is the case :(.  I _do_want_ a firewalling router to handle
my LAN and DMZ networks.  I want it to protect both LAN and DMZ so that I
can manage rules from one location rather than several of the boxen.

>
> Ok, I have a feeling that when you were typeing xx.xx.xx.182 you were
>really meaning to type xx.xx.xx.192.  Key shift, that's fine.  But that
does go to explain the interesting IPs.  No harm no foul.  :)  I think we
are on the same page of the same book now.

regarding IP's, yes

>
>>>Are the IPs in question in a subnet or just a scattering of them?
>> subnet...
>
> This is becoming more and more apparent all the time.  This is part of
>the
> problem which leads to what I think will be the ultimate solution.  (See
>below)
>
>> my firewall has 3 NIC's.  one connected to the router (well the VLAN
>>switch) which has an IP of 194.  the router is 193.  the dmz nic
(eth2) is
>> 195, the LAN is, well the LAN.  On my DMZ, I plan to provide static
>>address which are globally routable and from my subnet.
>
> *nod*  I think I see where you are going with this and I'm going to
>propose a wild change to accommodate what you are wanting to do.  (See
below)  (I know I keep saying that but it is a doosey.)
>
>> Sorry if I'm not making any sense... haven't had much sleep...
>
> Actually you are making more sense now than you have been all along.  No
>offense intended.  You have just explained that what you are wanting to
do
> can not be done with routing.

no offense taken, but I hope I continue to make sense.

>
>> I've been trying a few rules here and there trying to get something to
>>work... but to no avail.
>
> *nod*  I think I know why.  Let me try to explain.
>
> (this is below) (yes we finally made it)
>
> I think what you are wanting to do can not be done with traditional OSI
>Layer 3 routing but rather needs to be done with OSI Layer 2 bridging /
switching.  If I understand what you are wanting correctly to be the
following:

Ok, last night, after I slapped myself, I decided to check the logs, and
actually start logging... I should have been logging since the beginning,
perhaps it would have helped me explain my problem better.  I added the
following rules at the very top

iptables -A INPUT -i $WAN_ETH -j LOG
iptables -A OUTPUT -o $WAN_ETH -j LOG
iptables -A FORWARD -i $WAN_ETH -j LOG

Anyway, back to the point, I started to realize that perhaps my issue is
not with how I wrote my tables/rules, but with routing (you're mention of
OSI Layer 2 perhaps).  Last night it made more sense to me when I realized
that nothing was being logged on the interface connected to the
router/VLAN switch when attempting to connect to 196 (which is connected
to a switch "behind" the firewall).  I realized, hey, this seems to be a
routing issue...I now see I need to find a way to have 194 (or the
firewall's $WAN_ETH) route traffic for the rest of the subnet (except for
193 which is the router itself from the inside).

Now this is a wild guess, but I'm starting to think that I need to change
the router's routing rules.  But then again, I don't want to be someone
who remodels a bedroom just to add a new light switch.

>
> 1)  You want your router to be the router for all your systems behind it
(LAN is the exception) no matter where they are physically connected to.

I think I want my firewall to be the one to route for what is protected by
it, namely the LAN and DMZ because I want everything to be checked by the
rules of the firewall (which I see can be done using bridging now, but
still not sure if that's what I want).  I'm starting to think that I have
just opened up a can of gusanos

2)  You want the same subnet xx.xx.xx.192/28 to be on both sides of your
firewall (eth1 and eth2).

With the exception of the firewall's internal address, 193, I would like
to have the xx.xx.xx.192/28 subnet reachable behind my firewall only

> 3)  You want your LAN to appear to come from one of the IPs in your DMZ.

not the DMZ but the address of my firewall.  I have this part working as
noted by http://www.whatismyaddress.com.  I have a rule which does SNATing
on anything coming from my LAN interface and on the 192.168.0/28 network.

4)  You want to prevent any of the other systems in the DMZ from getting
to them directly.

Yes.

> If this is indeed the case what I propose you do is create a bridge on
your firewall and use EBTables to do most of your firewalling for your DMZ
> systems except for the LAN.  This would allow your systems in the DMZ to
be on the same subnet as the router's internal interface and talk as if
they were on the same physical LAN.  However as you will be passing the
traffic through a Linux bridge you will be able to do some basic
firewalling on them, namely protocol, source / destination IP, as well as
> source / destination port.  EBTables does not do much beyond that for
filtering but I think that is about all that you are wanting your
firewall
> to do.  You ultimately would use IPTables to handle the 2nd level of
firewalling (beyond EBTables) for your LAN which will allow you to do more
> advanced things like connection tracking and Stateful Packet Inspection
(SPI).
>
> Below is a (very) rough draft of the config / startup scripts that I
would
> write to make this happen.  You will not really need an IP for eth1 or
eth2 in this model of firewalling.  I think you will see why below.
>
> eth0 = LAN
> eth1 = Router
> eth2 = DMZ
>
> # We have to bring up the ether interfaces before we can set up the
bridge.
> ifconfig eth1 0.0.0.0 up
> ifconfig eth2 0.0.0.0 up
>
> # Let's establish the bridge first and then we will worry about the
IPTables firewalling.
> brctl addbr bri0
> sleep 1 # Prevent race conditions in the kernel.
> brctl addif bri0 eth1
> sleep 1
> brctl addif bri0 eth2
>
> # You will need to pick an IP to assign to your bri0 interface for the
LAN
> to use to communicate with the world.
> # Here are the IP assignments that I'm going to use for the sake of the
discussion, all of which are in the DMZ.
> #   Network = xx.xx.xx.192/28
> #    Router = xx.xx.xx.193/28
> #  LAN bri0 = xx.xx.xx.194/28
> # DMZ boxen = xx.xx.xx.195-206/28
> # Broadcast = xx.xx.xx.207/28
>
> # Let's assign an IP to the bri0 interface to be the ""external
interface
> of your pseudo LAN router.
> ifconfig bri0 xx.xx.xx.194 netmask 255.255.255.240 broadcast
xx.xx.xx.207
> up
>
> # You will need to have an IP subnet for your LAN.  I'm going to assume
aa.bb.cc.dd/24.
> #   Network = aa.bb.cc.0/24
> #    Router = aa.bb.cc.1/24
> #   Clients = aa.bb.cc.2-254/24
> # Broadcast = aa.bb.cc.255/24
>
> # Let's assing an IP to the eth0 interface
> ifconfig eth0 aa.bb.cc.1 netmask 255.255.255.0 broadcast aa.bb.cc.255 up
>
> At this point we have a logical switched (bridged) network that includes
the router (xx.xx.xx.193), your pseudo LAN router (xx.xx.xx.194) as well
as all your DMZ systems (xx.xx.xx.195-206).  The logical router is going
to use the bri0 interface to connect to the DMZ network so it can easily
communicate with the world via the router or to the other DMZ servers.
>
> So now we start setting up the various levels of firewalling.  To do
this
> on the OSI Layer 2 we will use EBTables.  We will use IPTables for the
OSI
> Layer 3 firewalling as you would expect.
>
> # First let's do some basic source / destination IP validation.  See RFC
3330 (http://www.rfc-editor.org/rfc/rfc3330.txt) for more information. #
Let's validate inbound source IPs by weeding out known bad source IPs.
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 10.0.0.0/8 -j DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 127.0.0.0/8 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 169.254.0.0/12 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 172.16.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 192.0.2.0/24 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 192.168.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src
255.255.255.255/32
> -j DROP
>
> # Let's make sure that the traffic is acctually to our network.
> ebtables -t filter -A FORWARD -i eth1 -p ipvr --ip-dst ! xx.xx.xx.192/28
-j DROP
>
> # Let's validate outbound destination IPs by weeding out known bad
destination IPs.
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 10.0.0.0/8 -j DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 127.0.0.0/8 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 169.254.0.0/12 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 172.16.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 192.0.2.0/24 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 192.168.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst
255.255.255.255/32
> -j DROP
>
> # For paranoia sake let's make sure that we are not sending any bad
source
> IPs too.
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 10.0.0.0/8 -j DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 127.0.0.0/8 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 169.254.0.0/12 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 172.16.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 192.0.2.0/24 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 192.168.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src
255.255.255.255/32
> -j DROP
>
> # If the traffic has made it this far we can be fairly confident that
the
> source and or destination IPs are reasonable.

thanks, in my complete script I had something similar, but did not include
127.0.0.0 or 169.0.0.0.  Thanks for the link to the RFC

> # If you want to do some additional filtering for a particular host you
would do it as such:
>
> # Host 195 is a web server only and thus will not answer DNS or SMTP
traffic.
> ebtables -t filter -N HOST195
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-dst xx.xx.xx.195 -j
HOST195
> ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
25
> -j DROP
> ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto udp --ip-dport
53
> -j DROP
> ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
53
> -j DROP
>
> # Host 196 could be DNS ONLY and will not have ANY other traffic AT all,
well save SSH of course.
> ebtables -t filter -N HOST196
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-dst xx.xx.xx.196 -j
HOST196
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
22
> -j ACCEPT
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto udp --ip-dport
53
> -j ACCEPT
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
53
> -j ACCEPT
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto icmp -j ACCEPT
ebtables -t filter -A HOST196 -i eth1 -j DROP
>
> # I think you get the idea.
>
> Now we can be fairly confident that the basic OSI Layer 2 firewalling
will
> make sure that nothing blatantly stupid is going on.  Thus we are left
with the OSI Layer 3 firewalling for the LAN.
>
> # Let's set up some sensible defaults.
> iptables -t filter -P INPUT DROP
> iptables -t filter -P FORWARD DROP
> iptables -t filter -P OUTPUT ACCEPT
>
> # Let's enable basic forwarding.
> iptables -t filter -A FORWARD -i bri0 -o eth0 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables -t filter -A FORWARD -i eth0 -o bri0 -j ACCEPT
>
> # Let's set up the SNATing for our outbound LAN traffic.
> iptables -t nat -A POSTROUTING -o bri0 -j SNAT --to-source xx.xx.xx.194
>
> # I'd like to be able to RDP to the office 2k3 server (accounting has a
Windows only program!)
> iptables -t nat -A PREROUTING -i bri0 -p tcp --dport 3389 -j DNAT
--to-destination aa.bb.cc.2
> iptables -t filter -A FORWARD -i bri0 -o eth0 -p tcp -d aa.bb.cc.2
--dport
> 3389 -j ACCEPT
>
> I think this will take care of most of the firewalling on both OSI
Layers
> 2 and 3 like I think you are needing.  I know that this is a rather
>lengthy email, but what you are asking is not a simple thing to solve. 
>Fortunately Linux should be very capable of providing for you.  Once you
>realize that what (I think) you are trying to do can not be done on OSI
>Layer 3 you will see why you could not find a solution with all the
various >things you / we have tried / proposed to do.
>

Ok, hopefully I'm a little more clear now, i.e. I want a firewalling
router for the subnet xx.xx.xx.192/28.  Initially, my plan was to do this:

1. Connect eth1 to the Router directly
2. eth0 would be the LAN and network 192.168.0/24
3. eth2 would ethe DMZ and network 10.x.x.x or 192.168.1/24
4. DNAT DMZ IP to the DMZ network like so

iptables -t nat -A PREROUTING -i $WAN_ETH -d $EXT_STAGING_HTTP_IP -j DNAT
--to-routing $INT_STAGING_HTTP_IP
iptables -t filter -A FORWARD etc..etc..

(you also mentioned this earlier)

But then I thought to myself, "Why don't I just assign the actual IP to
the DMZ server?" and thus my journey began.

I'm now at the point where I really think it's a routing issue... agree of
disagree?  My other option is to give up and say, also in a loud sinister
voice, "Rat's foiled again", but then realized and said in a loud sinister
voice : Never!!!

Or... do I look into bridging.  I have come across this as a possible
scenario before, but thought that perhaps it's not "exactly" what I'm
looking for.


> Any way, chew on this and (please) let me know what you think.

Impressed and thankful.  Also, I think this will make for good reading
when someone searches the archives.

Re: Forward to DMZ addresses

[Taylor, Grant]

Jonathan Villa wrote:
> First, grrr.... I just wrote a nice lengthy reply but my webmail session
> timed out and I lost it...let's see if I can remember everything I wrote

Been there done that.

> Actually, it is the case :(.  I _do_want_ a firewalling router to handle
> my LAN and DMZ networks.  I want it to protect both LAN and DMZ so that I
> can manage rules from one location rather than several of the boxen.

*nod*  This makes sense.

> no offense taken, but I hope I continue to make sense.

As don't we all?

> Anyway, back to the point, I started to realize that perhaps my issue is
> not with how I wrote my tables/rules, but with routing (you're mention of
> OSI Layer 2 perhaps).  Last night it made more sense to me when I realized
> that nothing was being logged on the interface connected to the
> router/VLAN switch when attempting to connect to 196 (which is connected
> to a switch "behind" the firewall).  I realized, hey, this seems to be a
> routing issue...I now see I need to find a way to have 194 (or the
> firewall's $WAN_ETH) route traffic for the rest of the subnet (except for
> 193 which is the router itself from the inside).

If you try to put the xx.xx.xx.192/28 network behind your firewalling router except for the one of the IPs you are breaking routing and needing to bridging again.

> Now this is a wild guess, but I'm starting to think that I need to change
> the router's routing rules.  But then again, I don't want to be someone
> who remodels a bedroom just to add a new light switch.

I don't think that completely redoing your routing table will gain you much.

> I think I want my firewall to be the one to route for what is protected by
> it, namely the LAN and DMZ because I want everything to be checked by the
> rules of the firewall (which I see can be done using bridging now, but
> still not sure if that's what I want).  I'm starting to think that I have
> just opened up a can of gusanos

*nod*  This makes more sense but poses a different problem.  To have the xx.xx.xx.192/28 network behind your firewalling router you will need an IP network connecting your (edge) router to your firewalling router.  You could use any private class IP for this little network if you wanted to.  But it is considered bad form use any private IPs any where at all on the internet even if it is to connect two routers via a cross over cable.

> With the exception of the firewall's internal address, 193, I would like
> to have the xx.xx.xx.192/28 subnet reachable behind my firewall only

*nod*

> not the DMZ but the address of my firewall.  I have this part working as
> noted by http://www.whatismyaddress.com.  I have a rule which does SNATing
> on anything coming from my LAN interface and on the 192.168.0/28 network.

*nod*  I was meaning to say that your LAN traffic would appear to the world as having been SNATed to an IP address in your xx.xx.xx.192/28 network.

> thanks, in my complete script I had something similar, but did not include
> 127.0.0.0 or 169.0.0.0.  Thanks for the link to the RFC

You are welcome.  No problem.

> Ok, hopefully I'm a little more clear now, i.e. I want a firewalling
> router for the subnet xx.xx.xx.192/28.  Initially, my plan was to do this:
> 
> 1. Connect eth1 to the Router directly
> 2. eth0 would be the LAN and network 192.168.0/24
> 3. eth2 would ethe DMZ and network 10.x.x.x or 192.168.1/24
> 4. DNAT DMZ IP to the DMZ network like so
> 
> iptables -t nat -A PREROUTING -i $WAN_ETH -d $EXT_STAGING_HTTP_IP -j DNAT
> --to-routing $INT_STAGING_HTTP_IP
> iptables -t filter -A FORWARD etc..etc..

IMHO this will work but it is more of a nasty hack.  This also leads to the possibility of things breaking down the road.  Consider running a service on one of the DMZ hosts that is not NAT friendly.  What will you do in that case?  If you can avoid this I think it would be very wise to do so.

> But then I thought to myself, "Why don't I just assign the actual IP to
> the DMZ server?" and thus my journey began.

*nod*  I often have such conversations with my self.  I love it when I win them and HATE it when I loose.

> I'm now at the point where I really think it's a routing issue... agree of
> disagree?  My other option is to give up and say, also in a loud sinister
> voice, "Rat's foiled again", but then realized and said in a loud sinister
> voice : Never!!!

Yes I agree hole heartedly.  Don't give up.

> Or... do I look into bridging.  I have come across this as a possible
> scenario before, but thought that perhaps it's not "exactly" what I'm
> looking for.

What "exactly" are you looking for?  I don't see a solution with out doing some REALLY funky stuff in such as playing with IPs and / or adding a 4th NIC to the box so that the new interface can be connected to the DMZ network and give it an IP to use as the router for your LAN.  Then you will need to do some really funky routing tables such as making the system act like two completely independent routers that know nothing about the other unless your traffic comes in or goes a specific pair of interfaces.

> Impressed and thankful.  Also, I think this will make for good reading
> when someone searches the archives.

Thank you very much.  I have seen some very interesting questions come across this mail list in the past most of which did not really have any good documentation (that I'm aware of) on ways to solve them.  I'm tempted to write some How To type documentation and submit it to someone else to host, possibly / probably the LARTC project (www.lartc.org).



Grant. . . .

Re: Forward to DMZ addresses

[Jonathan Villa]

> Jonathan Villa wrote:
>> First, grrr.... I just wrote a nice lengthy reply but my webmail
session
>> timed out and I lost it...let's see if I can remember everything I
wrote
>
> Been there done that.
>
>> Actually, it is the case :(.  I _do_want_ a firewalling router to
handle
>> my LAN and DMZ networks.  I want it to protect both LAN and DMZ so that I
>> can manage rules from one location rather than several of the boxen.
>
> *nod*  This makes sense.
>
>> no offense taken, but I hope I continue to make sense.
>
> As don't we all?
>
>> Anyway, back to the point, I started to realize that perhaps my issue
is
>> not with how I wrote my tables/rules, but with routing (you're mention of
>> OSI Layer 2 perhaps).  Last night it made more sense to me when I realized
>> that nothing was being logged on the interface connected to the
router/VLAN switch when attempting to connect to 196 (which is
connected
>> to a switch "behind" the firewall).  I realized, hey, this seems to be
a
>> routing issue...I now see I need to find a way to have 194 (or the
firewall's $WAN_ETH) route traffic for the rest of the subnet (except
for
>> 193 which is the router itself from the inside).
>
> If you try to put the xx.xx.xx.192/28 network behind your firewalling
router except for the one of the IPs you are breaking routing and
needing
> to bridging again.

This is what I've started to assume.   hmmm.... (scratching my head)

>> Now this is a wild guess, but I'm starting to think that I need to change
>> the router's routing rules.  But then again, I don't want to be someone
who remodels a bedroom just to add a new light switch.
>
> I don't think that completely redoing your routing table will gain you
much.

Thanks.

>> I think I want my firewall to be the one to route for what is protected by
>> it, namely the LAN and DMZ because I want everything to be checked by the
>> rules of the firewall (which I see can be done using bridging now, but
still not sure if that's what I want).  I'm starting to think that I
have
>> just opened up a can of gusanos
>
> *nod*  This makes more sense but poses a different problem.  To have the
xx.xx.xx.192/28 network behind your firewalling router you will need an
IP
> network connecting your (edge) router to your firewalling router.  You
could use any private class IP for this little network if you wanted to.

> But it is considered bad form use any private IPs any where at all on
the
> internet even if it is to connect two routers via a cross over cable.
>
>> With the exception of the firewall's internal address, 193, I would
like
>> to have the xx.xx.xx.192/28 subnet reachable behind my firewall only
>
> *nod*
>
>> not the DMZ but the address of my firewall.  I have this part working
as
>> noted by http://www.whatismyaddress.com.  I have a rule which does SNATing
>> on anything coming from my LAN interface and on the 192.168.0/28 network.
>
> *nod*  I was meaning to say that your LAN traffic would appear to the
world as having been SNATed to an IP address in your xx.xx.xx.192/28
network.
>
>> thanks, in my complete script I had something similar, but did not include
>> 127.0.0.0 or 169.0.0.0.  Thanks for the link to the RFC
>
> You are welcome.  No problem.
>
>> Ok, hopefully I'm a little more clear now, i.e. I want a firewalling
router for the subnet xx.xx.xx.192/28.  Initially, my plan was to do
this:
>> 1. Connect eth1 to the Router directly
>> 2. eth0 would be the LAN and network 192.168.0/24
>> 3. eth2 would ethe DMZ and network 10.x.x.x or 192.168.1/24
>> 4. DNAT DMZ IP to the DMZ network like so
>> iptables -t nat -A PREROUTING -i $WAN_ETH -d $EXT_STAGING_HTTP_IP -j DNAT
>> --to-routing $INT_STAGING_HTTP_IP
>> iptables -t filter -A FORWARD etc..etc..
>
> IMHO this will work but it is more of a nasty hack.  This also leads to
the possibility of things breaking down the road.  Consider running a
service on one of the DMZ hosts that is not NAT friendly.  What will you
do in that case?  If you can avoid this I think it would be very wise to
do so.

I think I'll avoid. Thanks for the heads up.

>> But then I thought to myself, "Why don't I just assign the actual IP to
the DMZ server?" and thus my journey began.
>
> *nod*  I often have such conversations with my self.  I love it when I
win
> them and HATE it when I loose.
>
>> I'm now at the point where I really think it's a routing issue... agree of
>> disagree?  My other option is to give up and say, also in a loud sinister
>> voice, "Rat's foiled again", but then realized and said in a loud sinister
>> voice : Never!!!
>
> Yes I agree hole heartedly.  Don't give up.
>
>> Or... do I look into bridging.  I have come across this as a possible
scenario before, but thought that perhaps it's not "exactly" what I'm
looking for.
>
> What "exactly" are you looking for?  I don't see a solution with out
doing
> some REALLY funky stuff in such as playing with IPs and / or adding a
4th
> NIC to the box so that the new interface can be connected to the DMZ
network and give it an IP to use as the router for your LAN.  Then you
will need to do some really funky routing tables such as making the
system
> act like two completely independent routers that know nothing about the
other unless your traffic comes in or goes a specific pair of
interfaces.
>
>> Impressed and thankful.  Also, I think this will make for good reading
when someone searches the archives.
>
> Thank you very much.  I have seen some very interesting questions come
across this mail list in the past most of which did not really have any
good documentation (that I'm aware of) on ways to solve them.  I'm
tempted
> to write some How To type documentation and submit it to someone else to
host, possibly / probably the LARTC project (www.lartc.org).
>

I guess "exactly" = a setup similar to what I've seen commercial firewall
products do, e.g. Sonicwall or Watchguard Firefox.  They have 3 NICS on
the back, 1. connected to the T1 router, 2. connected to the LAN switch,
3. connected to the DMZ switch.  and rules are managed from the Sonicwall
box itself... who knows what they're doing in the background... when we
setup DMZ boxen, we connect them to the DMZ switch, assign them static
addresses from our IP pool, create a rule allowing access, and off we go. 
When shopping around for firewall products, I've also noticed that some
specs say 3 NICS for DMZ/WAN/LAN connections sometimes more NICS (don't
know why).  I'm trying to mimic this...  perhaps they have some heavy
routing rules in the back, something that would I need to learn...


It's funny that you've just described exactly what I want to do...

>the new interface can be connected to the DMZ network

I currently have 3 nics, one connected to the DMZ switch, one connected to
the LAN switch, and the third to the T1 router (via the VLAN switch which
I plan to remove in September)

>act like two completely independent routers that
>know nothing about the other unless your traffic comes in or goes a
>specific pair of interfaces.

Yes!

all in all, all the information you've provided to me now makes sense...
and it gives me a very good starting point for more Googling...

Re: Forward to DMZ addresses

[Grant Taylor]

> I guess "exactly" = a setup similar to what I've seen commercial firewall
> products do, e.g. Sonicwall or Watchguard Firefox.  They have 3 NICS on
> the back, 1. connected to the T1 router, 2. connected to the LAN switch,
> 3. connected to the DMZ switch.  and rules are managed from the Sonicwall
> box itself... who knows what they're doing in the background... when we
> setup DMZ boxen, we connect them to the DMZ switch, assign them static
> addresses from our IP pool, create a rule allowing access, and off we go. 
> When shopping around for firewall products, I've also noticed that some
> specs say 3 NICS for DMZ/WAN/LAN connections sometimes more NICS (don't
> know why).  I'm trying to mimic this...  perhaps they have some heavy
> routing rules in the back, something that would I need to learn...

I have never used any of these ""commercial products as I have always been able to get Linux to do what I wanted it to do.  That or I have changed what I want to so that it fits with in what Linux can do, though I don't think this is very likely.

> It's funny that you've just described exactly what I want to do...

Hmm, maybe bridging is exactly what you want to do then and you just are not aware of it.

> I currently have 3 nics, one connected to the DMZ switch, one connected to
> the LAN switch, and the third to the T1 router (via the VLAN switch which
> I plan to remove in September)

If you want these three physical networks to have the same (logical) subnet then you will not be able to connect them via routing with out doing some much more complex routing via DNAT/SNATing on a couple of different routers connected to them.  Sure you could use UML routers and do all of this with one box the this gets EXTREMELY complex for little gain.

>>act like two completely independent routers that
>>know nothing about the other unless your traffic comes in or goes a
>>specific pair of interfaces.
> 
> Yes!

Ok, this seems a bit silly to me but if this is the way that you want to go I'll be glad to help you.  The question that I do ask you is do you want a fourth physical interface or could it be a logical interface on the network?  If it could be a logical interface that is connected to the other interfaces via a bridge then that may be a bit better.  But this is up for discussion.

> all in all, all the information you've provided to me now makes sense...
> and it gives me a very good starting point for more Googling...

*nod*  Information is a good thing.



Grant. . . .

Re: Forward to DMZ addresses

[Jonathan Villa]

>> I guess "exactly" = a setup similar to what I've seen commercial
>> firewall
>> products do, e.g. Sonicwall or Watchguard Firefox.  They have 3 NICS on
>> the back, 1. connected to the T1 router, 2. connected to the LAN switch,
>> 3. connected to the DMZ switch.  and rules are managed from the
>> Sonicwall
>> box itself... who knows what they're doing in the background... when we
>> setup DMZ boxen, we connect them to the DMZ switch, assign them static
>> addresses from our IP pool, create a rule allowing access, and off we
>> go.
>> When shopping around for firewall products, I've also noticed that some
>> specs say 3 NICS for DMZ/WAN/LAN connections sometimes more NICS (don't
>> know why).  I'm trying to mimic this...  perhaps they have some heavy
>> routing rules in the back, something that would I need to learn...
>
> I have never used any of these ""commercial products as I have always been
> able to get Linux to do what I wanted it to do.  That or I have changed
> what I want to so that it fits with in what Linux can do, though I don't
> think this is very likely.
>
>> It's funny that you've just described exactly what I want to do...
>
> Hmm, maybe bridging is exactly what you want to do then and you just are
> not aware of it.

Perhaps. I'm going to start looking into this.

>> I currently have 3 nics, one connected to the DMZ switch, one connected
>> to
>> the LAN switch, and the third to the T1 router (via the VLAN switch
>> which
>> I plan to remove in September)
>
> If you want these three physical networks to have the same (logical)
> subnet then you will not be able to connect them via routing with out
> doing some much more complex routing via DNAT/SNATing on a couple of
> different routers connected to them.  Sure you could use UML routers and
> do all of this with one box the this gets EXTREMELY complex for little
> gain.
>
>>>act like two completely independent routers that
>>>know nothing about the other unless your traffic comes in or goes a
>>>specific pair of interfaces.
>>
>> Yes!
>
> Ok, this seems a bit silly to me but if this is the way that you want to
> go I'll be glad to help you.

That would be great!

>The question that I do ask you is do you
> want a fourth physical interface or could it be a logical interface on the
> network?  If it could be a logical interface that is connected to the
> other interfaces via a bridge then that may be a bit better.  But this is
> up for discussion.

I have one PCI slot left, it's currently being used by a SCSI card which
I'm not using.  I can replace it with a NIC.  I currently have 2 built-in
NICS plus one in the first PCI slot.  I logical interface is fine also. 
It saves me from having to take the machine off of the rack.

>> all in all, all the information you've provided to me now makes sense...
>> and it gives me a very good starting point for more Googling...
>
> *nod*  Information is a good thing.
>
 I know I will definitely need some help, but before I ask for, I'll need
to do some reading up on bridging so at least I understand any examples
given to me (starting with the previous one you gave).

Re: Forward to DMZ addresses

[Taylor, Grant]

> That would be great!

I'll start thinking about the two virtual routers in one box later on this evening.

>>The question that I do ask you is do you
>>want a fourth physical interface or could it be a logical interface on the
>>network?  If it could be a logical interface that is connected to the
>>other interfaces via a bridge then that may be a bit better.  But this is
>>up for discussion.
> 
> I have one PCI slot left, it's currently being used by a SCSI card which
> I'm not using.  I can replace it with a NIC.  I currently have 2 built-in
> NICS plus one in the first PCI slot.  I logical interface is fine also. 
> It saves me from having to take the machine off of the rack.

*nod*  Not having to take a machine out of it's rack is always a good thing.  Can you (do you mind) repurposeing cables that are presently connected to your router?  The reason that I ask is that it just struck me (sunk in) that you are using a VLAN switch.  Before I was not thinking about the fact that you could use a trunk interface to the VLAN switch and thus reduce the number of cables that you would need to connect to it.  With this in mind I would recommend that you connect your router in to your switch and put the port that you connect it to on one VLAN.  (If you have not already) Configure another VLAN to be for your DMZ hosts and one for your LAN hosts.  With this done you could bond the two NICs that are in your server as one interface to the switch and then use 802.1Q VLAN tagged packets to communicate with each VLAN.  The nice thing about the bonding is that either of the cab
 les connecting your system to the switch could fail and the router would not go down b/c o
f a lack / loss of connection.  As far as interfacing with the VLANs on the Linux router you will end up with an interface something like eth0.1 for VLAN ID 1, eth0.2 for VLAN ID 2, and eth0.3 for VLAN ID 3.  If you do it over a bonded interface you should end up with something like bond0.1, bond0.2, and bond0.3.  This will cause your router to have a logical interface on all of your networks, even new ones that you might add to the switch down the road.

If you do go with bonding and 802.1Q tagged VLAN packets you would end up having the following interface / network layout (based on previous discussion).

Router connected to a port on the switch that is configured to be in VLAN "Router" (VID 11)
LAN connected to ports on the switch that are configured to be in VLAN "LAN" (VID 10)
DMZ connected to ports on the switch that are configured to be in VLAN "DMZ" (VID 12)

(Router xx.xx.xx.193/28)

 eth0		0.0.0.0
 eth1		0.0.0.0
 eth2		0.0.0.0
bond0		0.0.0.0
bond0.10	192.168.1.1
bond0.11	0.0.0.0
bond0.12	0.0.0.0
 bri0	xx.xx.xx.194/28

(DMZ    xx.xx.xx.195-207/28)

This would allow you to grow your system (add / remove (logical VLAN) interfaces) as you saw fit down the road with out needing to take the box out of the rack or put it back in when you are done.  You could easily add a 2nd or 3rd DMZ or any other segregated network with out having to worry about the physical connections to your router, just to the VLAN switch.  Supposing that you wanted to add a 2nd DMZ you would just add a bond0.13 interface and add it to the bri0 bridge and then update your EBTables rules to (dis)allow traffic to flow as you liked.  I will have to play with the bonding later on at home to give you exact examples.

These are just some of the ""fun (complex and enterprise level) things that you can do with Linux if you are willing to grow and combine many not normal ideas.

>  I know I will definitely need some help, but before I ask for, I'll need
> to do some reading up on bridging so at least I understand any examples
> given to me (starting with the previous one you gave).

Ok, I'll be glad to help.



Grant. . . .

Re: Forward to DMZ addresses

[Grant Taylor]

> *nod*  Not having to take a machine out of it's rack is always a good thing.  Can you (do you mind) repurposeing cables that are presently connected to your router?  The reason that I ask is that it just struck me (sunk in) that you are using a VLAN switch.  Before I was not thinking about the fact that you could use a trunk interface to the VLAN switch and thus reduce the number of cables that you would need to connect to it.  With this in mind I would recommend that you connect your router in to your switch and put the port that you connect it to on one VLAN.  (If you have not already) Configure another VLAN to be for your DMZ hosts and one for your LAN hosts.  With this done you could bond the two NICs that are in your server as one interface to the switch and then use 802.1Q VLAN tagged packets to communicate with each VLAN.  The nice thing about the bonding is that either of the c
 ables connecting your system to the switch could fail and the router would not go down b/c
 o
> f a lack / loss of connection.  As far as interfacing with the VLANs on the Linux router you will end up with an interface something like eth0.1 for VLAN ID 1, eth0.2 for VLAN ID 2, and eth0.3 for VLAN ID 3.  If you do it over a bonded interface you should end up with something like bond0.1, bond0.2, and bond0.3.  This will cause your router to have a logical interface on all of your networks, even new ones that you might add to the switch down the road.
> 
> If you do go with bonding and 802.1Q tagged VLAN packets you would end up having the following interface / network layout (based on previous discussion).
> 
> Router connected to a port on the switch that is configured to be in VLAN "Router" (VID 11)
> LAN connected to ports on the switch that are configured to be in VLAN "LAN" (VID 10)
> DMZ connected to ports on the switch that are configured to be in VLAN "DMZ" (VID 12)
> 
> (Router xx.xx.xx.193/28)
> 
>  eth0		0.0.0.0
>  eth1		0.0.0.0
>  eth2		0.0.0.0
> bond0		0.0.0.0
> bond0.10	192.168.1.1
> bond0.11	0.0.0.0
> bond0.12	0.0.0.0
>  bri0	xx.xx.xx.194/28
> 
> (DMZ    xx.xx.xx.195-207/28)
> 
> This would allow you to grow your system (add / remove (logical VLAN) interfaces) as you saw fit down the road with out needing to take the box out of the rack or put it back in when you are done.  You could easily add a 2nd or 3rd DMZ or any other segregated network with out having to worry about the physical connections to your router, just to the VLAN switch.  Supposing that you wanted to add a 2nd DMZ you would just add a bond0.13 interface and add it to the bri0 bridge and then update your EBTables rules to (dis)allow traffic to flow as you liked.  I will have to play with the bonding later on at home to give you exact examples.
> 
> These are just some of the ""fun (complex and enterprise level) things that you can do with Linux if you are willing to grow and combine many not normal ideas.

Another advantage of going this route would be if you added a different internet connection you could very easily just connect it to a port on the VLAN switch that was configured for a specific VLAN and then set up a corresponding interface on your router with out having to take any thing down.  This does really lend it's self to some expandability with virtually no limits.  (Really there are limits, the 802.1Q spec allots for 1024 VLANs.  But this is being overcome as well as people are embedding 802.1Q tagged packets in outer 802.1Q tagged packets thus making a pseudo VWAN for metropolitan are networks.)



Grant. . . .