Re: netfilter Digest, Vol 13, Issue 41

[Visham Ramsurrun <vishamr2000@gmail.com>]

Hi to all,

Can anyone tell where I can sample firewall scripts that contain
1) about 100 rules
2) about 1000 - 2000 rules1

I am using RH9..i want to use these for testing the amount of
processing required for each of these scripts?

Warm regards,
Visham 

On 8/19/05, netfilter-request@lists.netfilter.org
<netfilter-request@lists.netfilter.org> wrote:
> Send netfilter mailing list submissions to
> 	netfilter@lists.netfilter.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.netfilter.org/mailman/listinfo/netfilter
> or, via email, send a message with subject or body 'help' to
> 	netfilter-request@lists.netfilter.org
> 
> You can reach the person managing the list at
> 	netfilter-owner@lists.netfilter.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of netfilter digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: port 80 out new ISP (/dev/rob0)
>    2. Re: port 80 out new ISP (Brent Clark)
>    3. Re: port 80 out new ISP (Brent Clark)
>    4. Re: Forward to DMZ addresses (Jonathan Villa)
>    5. Re: Forward to DMZ addresses (Taylor, Grant)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 19 Aug 2005 12:05:22 -0500
> From: /dev/rob0 <rob0@gmx.co.uk>
> Subject: Re: port 80 out new ISP
> To: netfilter@lists.netfilter.org
> Message-ID: <200508191205.22196.rob0@gmx.co.uk>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> On Friday 2005-August-19 10:55, Brent Clark wrote:
> > I currently have been reading the following doc.
> >
> > http://linux-ip.net/html/adv-multi-internet.html
> >
> > and have changed my scripts accordingly.
> 
> Not quite.
> 
> > my setup is as so
> >
> > firewall:
> > eth0 196.36.10.114    -> Routes traffic to old ISP
> > eth1 192.168.111.10    -> Private Lan
> > eth2 192.168.10.100    -> for ADSL
> >
> > Adsl modem:
> > ipaddress: 192.168.10.200 (external ip dynamically assigned)
> 
> This "modem" is also functioning as a NAT router? So in effect your 
> 192.168.10.100 IP (eth2) can function as an external interface?
> 
> > ## Create the table
> > ip route flush table TELKOM  >>/dev/null
> > ip route show table main |grep -Ev ^default\
> 
> What does this command, without the "\<newline>" and pipe, return?
> 
> >    | while read ROUTE ; do
> >
> >      ip route add table TELKOM $ROUTE
> >   done
> >
> > ## Add the ADSL as route to route table 4
> >
> > ip route add default via 192.168.10.200 dev eth2 table TELKOM
> > >>/dev/null
> >
> > ## Add the route to table TELKOM
> >
> > ip rule add fwmark 1 table TELKOM >> /dev/null
> 
> And what do your routing rules show at this point?
> 
> > $IPT -t nat -A PREROUTING -i eth1 -t mangle -p tcp --dport 80 -j MARK
> > --set-mark 1
> > $IPT -t nat -A PREROUTING -i eth1 -t mangle -p tcp 
> > --dport 443 -j MARK --set-mark 1
> >
> > # SNAT the Private LAN
> > $IPT -t nat -A POSTROUTING -o eth0 -s 192.168.111.0/24 -j SNAT
> > --to-source 196.36.10.114
> > #$IPT -t nat -A POSTROUTING -o eth2 -s 
> > 192.168.111.0/24 -j SNAT --to-source 192.168.10.200
> 
> Why is that one commented?
> 
> > $IPT -t nat -A POSTROUTING -o eth2 -s 192.168.111.0/24 -j MASQUERADE
> 
> MASQUERADE will not work with dual routing.
> -- 
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 19 Aug 2005 19:22:56 +0200
> From: Brent Clark <bclark@eccotours.dyndns.org>
> Subject: Re: port 80 out new ISP
> To: /dev/rob0 <rob0@gmx.co.uk>
> Cc: netfilter@lists.netfilter.org
> Message-ID: <43061570.9090702@eccotours.dyndns.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi Rob
> 
> A big thanks for replying to my email.
> 
> >>ip route flush table TELKOM  >>/dev/null
> >>ip route show table main |grep -Ev ^default\
> > 
> > 
> > What does this command, without the "\<newline>" and pipe, return?
> > 
> 
> gate:~# ip route show table main | grep -Ev ^default
> 196.36.10.112/29 dev eth0  proto kernel  scope link  src 196.36.10.114
> 192.168.111.0/24 dev eth1  proto kernel  scope link  src 192.168.111.10
> 192.168.10.0/24 dev eth2  proto kernel  scope link  src 192.168.10.100
> gate:~#
> 
> >>ip rule add fwmark 1 table TELKOM >> /dev/null
> > 
> > 
> > And what do your routing rules show at this point?
> 
> gate:~# ip rule show
> 0:      from all lookup local
> 32765:  from all fwmark 0x1 lookup TELKOM
> 32766:  from all lookup main
> 32767:  from all lookup default
> gate:~#
> 
> gate:~# ip route show table main
> 196.36.10.112/29 dev eth0  proto kernel  scope link  src 196.36.10.114
> 192.168.111.0/24 dev eth1  proto kernel  scope link  src 192.168.111.10
> 192.168.10.0/24 dev eth2  proto kernel  scope link  src 192.168.10.100
> default via 196.36.10.113 dev eth0
> gate:~#
> 
> gate:~# ip route show table TELKOM
> 196.36.10.112/29 dev eth0  proto kernel  scope link  src 196.36.10.114
> 192.168.111.0/24 dev eth1  proto kernel  scope link  src 192.168.111.10
> 192.168.10.0/24 dev eth2  proto kernel  scope link  src 192.168.10.100
> default via 192.168.10.200 dev eth2
> gate:~#
> 
> 
> >># SNAT the Private LAN
> >>$IPT -t nat -A POSTROUTING -o eth0 -s 192.168.111.0/24 -j SNAT
> >>--to-source 196.36.10.114
> >>#$IPT -t nat -A POSTROUTING -o eth2 -s 
> >>192.168.111.0/24 -j SNAT --to-source 192.168.10.200
> > 
> > 
> > Why is that one commented?
> 
> Im commented it out, hoping the MASQUERADE would work.
> > 
> > 
> >>$IPT -t nat -A POSTROUTING -o eth2 -s 192.168.111.0/24 -j MASQUERADE
> > 
> > 
> > MASQUERADE will not work with dual routing.
> 
> Thanks
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 19 Aug 2005 20:05:59 +0200
> From: Brent Clark <bclark@eccotours.dyndns.org>
> Subject: Re: port 80 out new ISP
> To: /dev/rob0 <rob0@gmx.co.uk>
> Cc: netfilter@lists.netfilter.org
> Message-ID: <43061F87.1030507@eccotours.dyndns.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi Rob
> 
> Im not sure is this a good way of debugging
> 
> but I tried this:
> 
> iptables -t nat -A PREROUTING --dport 80 -j LOG
> Aug 19 18:40:32 gate kernel: IN=eth1 OUT=
> MAC=00:00:f4:af:80:b8:00:60:67:77:aa:92:08:00 SRC=192.168.111.213
> DST=66.36.247.82 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=2925 DF PROTO=TCP
> SPT=4032 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
> 
> Notice that "OUT=" does not show eth2
> 
> Brent
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 19 Aug 2005 13:57:32 -0500 (CDT)
> From: "Jonathan Villa" <jonathan@innovativesource.net>
> Subject: Re: Forward to DMZ addresses
> To: "netfilter" <netfilter@lists.netfilter.org>
> Message-ID:
> 	<39244.206.166.83.50.1124477852.squirrel@mail.innovativesource.net>
> Content-Type: text/plain;charset=iso-8859-1
> 
> 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.
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 19 Aug 2005 17:33:37 -0500
> From: "Taylor, Grant" <gtaylor@riverviewtech.net>
> Subject: Re: Forward to DMZ addresses
> To: netfilter <netfilter@lists.netfilter.org>
> Message-ID: <43065E41.7080407@riverviewtech.net>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 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. . . .
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> netfilter mailing list
> netfilter@lists.netfilter.org
> https://lists.netfilter.org/mailman/listinfo/netfilter
> 
> 
> End of netfilter Digest, Vol 13, Issue 41
> *****************************************
>