|
||||||||||
Brian, When you tried Scenario A, did you also do as Falcor suggested, and have your ISP route all traffic to your WAN? It is obvious that I need to re-subnet, which is fine (I just inherited this set up, and it's clear that we will need to make some DNS changes). If I understand Falcor right, I would do the following: WAN: x.x.x.251/29 with gateway x.x.x.249 DMZ: x.x.x.240/29 and assign gateway of x.x.x.241 on each machine Do I still need my ISP to route all traffic bound for x.x.x.240/28 to x.x.x.251? And will the DMZ machines be accessible via public IPs? Thanks very much for your help, Jeanne On Wed, 2 Jun 2004 12:25:30 -0600 "Brian Buys" <bbuys at tritel dot com> wrote: > Jeanne, > > I have tried to make a similar setup work on m0n0wall for a few weeks now. > After searching the archives and doing several tests of my own, I determined > that two methods were available, each with a drawback that I could not live > with: > > Scenario A: > > Subnet my /28 network from ISP, giving half to WAN interface and half to DMZ > interface. Declaring the /29 subnets on each interface allowed it to work > as Falcor suggested in his reply, but with one problem: I could not access > the DMZ from WAN. DMZ could get out to WAN, but incoming WAN traffic could > not reach the DMZ machines when they were publicly addressed. LAN to DMZ > (and reverse) worked fine. > > Research into the archives pointed to m0n0wall wanting to perform NAT to the > DMZ, which was fouling things up on the incoming side. One workaround that > I read about was to *enable* advanced NAT rules, effectively stopping > m0n0wall from trying to build a NAT rule for the DMZ. I tried this from a > defaulted configuration but still could not get it to work any differently. > It seemed like that would be the answer, but that is the point at which I > stopped pursuing it (for the time being). Enabling advanced NAT may still > be the answer, I may have just missed some other step. > > Scenario B: > > The alternative to subnetting was to bridge the DMZ interface to the WAN > interface. This worked as well, but the drawback to it was that now my LAN > could not access the DMZ machines! This was unacceptable as well, since my > entire goal was to leave the DMZ machines publicly addressable, yet > reachable from both LAN side and WAN side. > > While I haven't properly answered your original question, I thought I would > add my findings to the discussion to see if it might help you (and me) reach > a solution. One thing I have not done is to request that my ISP direct all > traffic to my WAN interface's IP address. Perhaps if I have them do that > the routing will work properly as suggested. > > Of note, in both of my scenarios I wrote *.* rules for all interfaces and > watched the firewall logs for blocked packets to insure it wasn't the fw > stopping the communication attempts. > > Regards, > > Brian > > ----- Original Message ----- > From: "Falcor" <falcor at netassassin dot com> > To: "Jeanne" <techielists at regionalhelpwanted dot com> > Cc: <m0n0wall at lists dot m0n0 dot ch> > Sent: Tuesday, June 01, 2004 8:53 PM > Subject: Re: [m0n0wall] newbie DMZ question > > > > unless you change the subnet you need to instruct the machines on your > > DMZ to use x.x.x.241 as the gateway. > > > > The proper way to do this would be to have the ISP route all traffic for > > x.x.x.240/28 to your WAN interface. Then subnet the /28 and assign the > > subnets to your DMZ setting the proper subnet mask for each interface so > > it reflects your division of the network. If you did this then you > > would end up with a gateway IP for the DMZ interface, and the internal > > route statement on the firewall would understand sending traffic to the > > different networks. Then you would need to add rules allowing traffic > > to/from the DMZ etc. > > > > If you don't do it this way then you will need to setup ARP forwarded IP > > addresses from the firewall's WAN interface to the DMZ hosts. Not so > > good to do for your setup. > > > > Someone may have another trick, but that is the proper way of doing this > > no matter what firewall / router you are using. > > > > The difference is that your 3com probably did the subnet mask for you, > > and although there were probably issues with SAP and RIP and such on > > your DMZ segments the 3com accommodated it. E.g. you specified an IP > > range, and it did the bit math but the servers still had /28 subnet masks. > > > > Jeanne wrote: > > > > >Hi, > > > > > >I am replacing a 3com firewall and need to keep the IP addressing as is. > Nat/Firewall is working fine for the LAN. I cannot configure the DMZ. > Machines on the DMZ cannot ping the Wan or the Gateway. > > > > > >ISP issued block: x.x.x.240/28 > > >WAN x.x.x.251/28 > > >ISP designated gateway for this block: x.x.x.241 > > >Machines in the DMZ have public IPs within this x.x.x.240/28 block. For > example, our web server is x.x.x.252 with a gateway of x.x.x.251, and an ftp > server is x.x.x.246. The 3com allows for 2 DMZ ranges of x.x.x.242-250 and > 252-254. m0n0wall appears to allow only a single DMZ net. > > > > > >For the moment I am allowing all traffic to and from the DMZ: > > >Wan interface -- Proto: * Source: DMZ Net Port: * Destination: * Port: * > > >DMZ Interface -- Proto: * Source: * Port: * Destination: DMZ net Port: * > > > > > >Please know that I have searched the archives, but I'm still stumped. > Thanks for your time. > > > > > >Cheers, > > > > > >Jeanne > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch > > >For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch > > > > > > |