On Friday 02 July 2004 21:05, you wrote:

...

So let's examine scenario two, with non-reallife IP numbers. Here you have 22.22.22.10 on eth1, 192.168.0.x/24 on eth0 and you choose another net for the DMZ which MUST NOT be the same as on eth0 ! So, let's take 192.168.99.0/24 in this example. So eth2 becomes 192.168.99.1

...

From there on it's simple; you make a series of rules like you had,

FW_FORWARD_MASQ="0/0,192.168.99.4,tcp,80" if you have a webserver in the DMZ with IP 192.168.99.4. Add other statements for other ports and/or other servers to that same line, between those quotes, separated with space. You mustn't forget to set the right gateway on your DMZ boxes; they must have the IP you set to eth2 as their default gateway: 192.168.99.1. You may also have to make special arrangements so that internal hosts can connect to the DMZ IIRC, but I don't remember offhand. Just try it.

Good luck, Maarten

I tried this because it looked like what was needed a coulple of days ago. it didn't seem to work but maybe I had something set up wrong. if this indeed is the setup, it narrows the field of possible remaining issues.

is the eth on the firewall to the DMZ set as FW_DEV_DMZ or because it's technically another masq'd net is it FW_DEV_INT ??

No no, its definitely FW_DEV_DMZ. Be careful how you test it; you will probably NOT be able to test the connection from within, so you'll have to have access to another internet connection to test from (or a remote host). Also, if you know halfway how to interpret it, a sniffer can be an invalueable help if things do not work from the start. Even if you can't interpret it, just seeing where the packet gets sent to (or not) can be enlighting. Tcpdump or Snort are your friends. You can start multiple sessions, each attached to the different eth's. Not very relevant now, but: The caveat I forgot to mention in comparing the first with the second scenario is that when masquerading as you will do now, you can only have 1 machine in your DMZ for each service, i.e. one webserver, one mailserver, etc, maximum. This stems from the fact that you cannot masquerade one port to two systems, whereas in the real-life IP numbers scenario you don't masquerade, just route. And that of course works just fine with multiple IP's. Another thing, if it wasn't already obvious, is that for the outside world, your server(s) appear to have the IP number your firewall has: the ISP address. But seen from the inside LAN this isn't so. From there, you just do plain routing, so you address the DMZ servers by their actual IP. This is only valid in scenario two, the masquerading one. Otherwise everything is just addressed by their actual IP number (22.22.22.18 etc.) Confusing ? Nah. ;-) One last advice: Keep it simple, and take small steps. For example, never test it with a browser / webpage. Test it with ping or ssh first and go on to other, more complex, services from there. Also, never ever use DNS names (unless it's really setup well, and triple-checked), instead always connect to the IP numbers. Don't know it this was too obvious but one never knows... Maarten

Thanks!! I'll give it another try.

Mike

-- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER