DMZ Setup is killing me!!
Running SuSE 9.0 Pro. O.K. I'm about to give up. I've been messing with the setup for SuSEfirewall2 which is apparently a niced up front end to IPTABLES. I'm trying to get a DMZ up so when I have to fix something on our renderfarm at 3 AM I can do it from home through ssh. currently the firewall works with 2 NICs dividing my local net from the big bad ugly WWW. it is functioning properly and dropping everything that it should. now on to the DMZ. I've read a ton of stuff on how to set up internal DMZ's through FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" which looks like it Masquerades and uses an inside IP on a third NIC that's not a "real world" IP. I can't get that working in any way. Then there's the preferred method of having a second, ISP issued "real world" IP, on the DMZ and It again resides on the third NIC but there is no masquerading and it looks like and it uses FW_FORWARD="127.0.0.1,127.0.0.2,tcp,1". The forelisted FW lines are straight out of the EXAMPLE included with SuSE so they really don't apply to my network directly. let me sum up what I have and maybe somebody can point me in the right direction. Firewall box: FW_DEV_INT="eth0" FW_DEV_EXT="eth1" FW_DEV_DMZ="eth2" the external has my first ISP assigned IP. the internal is the generic 192.168.2.0 network. what I'm not sure of is what IP needs to be on eth2 real or masq'd and any custom routing. I've tried everything I can think of. including a same and different internal IP, another of my real world IP's you name it. routes?? and maybe howto?? DMZ box eth0 tried internal IP, real world IP......all in pairs because AFAIK if the subnet isn't the same and the networks are different they wont ping. the only life out there I get is when I use and internal IP like 192.168.0.1 on eth2 for the firewall and 192.168.0.2 on the DMZ. then I can ping from firewall to DMZ and vice versa. but when I go from there to try and use the FW_FORWARD_MASQ, I still can't get in from home on the outside. the only reason I'm pursuing the masq setup is I can't get anything else to ping. I'd prefer to do it the other way but it's not getting anywhere. so here's the snip from the masq field: # Which services accessed from the internet should be allowed to masqueraded # servers (on the internal network or dmz)? # REQUIRES: FW_ROUTE # # With this option you may allow access to e.g. your mailserver. The # machines must be in a masqueraded segment and may not have public IP addesses! # Hint: if FW_DEV_MASQ is set to the external interface you have to set # FW_FORWARD from internal to DMZ for the service as well to allow access # from internal! # # Please note that this should *not* be used for security reasons! You are # opening a hole to your precious internal network. If e.g. the webserver there # is compromised - your full internal network is compromised!! # # Choice: leave empty (good choice!) or use the following explained syntax # of forward masquerade rules, seperated each by a space. # A forward masquerade rule consists of 1) source IP/net, 2) destination IP # (dmz/intern), 3) a protocol (tcp/udp only!) and 4) destination port, # seperated by a comma (","), e.g. "4.0.0.0/8,1.1.1.1,tcp,80" # Optional is a port after the destination port, to redirect the request to # a different destination port on the destination IP, e.g. # "4.0.0.0/8,1.1.1.1,tcp,80,81" # FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" # Beware to use this! Any help would be appreciated. I'm feeling beat up by what should be so simple... :^( Mike
Quoting Mike Branda <mike@wackyworld.tv>:
O.K. I'm about to give up. I've been messing with the setup for SuSEfirewall2 which is apparently a niced up front end to IPTABLES. I'm trying to get a DMZ up so when I have to fix something on our renderfarm at 3 AM I can do it from home through ssh. [snip]
I don't quite understand why you're setting up a DMZ. There is a much simpler way of accomplishing this: FW_SERVICES_EXT_TCP="ssh" This will allow you to ssh into the firewall box from the internet. From there, you can then ssh into whichever internal IP address that needs fixing. It's far safer than opening up a DMZ to any of your internal machines...
* Mike Branda; <mike@wackyworld.tv> on 02 Jul, 2004 wrote:
Running SuSE 9.0 Pro.
O.K. I'm about to give up. I've been messing with the setup for SuSEfirewall2 which is apparently a niced up front end to IPTABLES. I'm trying to get a DMZ up so when I have to fix something on our renderfarm at 3 AM I can do it from home through ssh. currently the firewall works with 2 NICs dividing my local net from the big bad ugly WWW. it is
Have you looked at the SuSEfirewall2 manual available at http://sourceforge.net/projects/susefaq -- Togan Muftuoglu | Unofficial SuSE FAQ Maintainer | Please reply to the list; http://susefaq.sf.net | Please don't put me in TO/CC. Nisi defectum, haud refiecendum
On Friday 02 July 2004 17:28, Mike Branda wrote:
Running SuSE 9.0 Pro.
O.K. I'm about to give up. I've been messing with the setup for SuSEfirewall2 which is apparently a niced up front end to IPTABLES. I'm trying to get a DMZ up so when I have to fix something on our renderfarm at 3 AM I can do it from home through ssh. currently the firewall works with 2 NICs dividing my local net from the big bad ugly WWW. it is functioning properly and dropping everything that it should. now on to the DMZ. I've read a ton of stuff on how to set up internal DMZ's through FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" which looks like it Masquerades and uses an inside IP on a third NIC that's not a "real world" IP. I can't get that working in any way. Then there's the preferred method of having a second, ISP issued "real world" IP, on the DMZ and It again resides on the third NIC but there is no masquerading and it looks like and it uses FW_FORWARD="127.0.0.1,127.0.0.2,tcp,1".
There are two ways indeed, but you may have things confused. The most difficult way is with reallife IPs from your ISP. Then you either need to subnet or do tricks with proxy-arp or so. The thing with subnetting is, it's very neat but your ISP must cooperate otherwise it's hell. Example: Your ISP gives you two subnets, these are just made-up numbers. 22.22.22.8/29 (8 IP numbers) and 22.22.22.16/29 (again 8 IP numbers) Now you set eth1 to 22.22.22.10 and let's assume that 22.22.22.9 is the ISP's gateway. You set eth2 to 22.22.22.17 thereby becoming the gateway for the DMZ. Now the ISP has to add a route to its own router that says that all traffic to 22.22.22.16/29 must be routed TO 22.22.22.10 ! Then, all is good, i.e. you configure your firewall accordingly of course. 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. Oh and one other tip: never try if it works with FTP as that is the most difficult protocol you can possibly choose. In fact, for getting FTP to work, you may need to do rather more than you've bargained for, depending on whether it's active or passive FTP, whether it's coming from internal, external or comes from the DMZ itself. Consider yourself warned. Ftp is a real bitch, and it should've been shot ages ago... really Good luck, Maarten
The forelisted FW lines are straight out of the EXAMPLE included with SuSE so they really don't apply to my network directly. let me sum up what I have and maybe somebody can point me in the right direction.
Firewall box:
FW_DEV_INT="eth0" FW_DEV_EXT="eth1" FW_DEV_DMZ="eth2"
the external has my first ISP assigned IP. the internal is the generic 192.168.2.0 network. what I'm not sure of is what IP needs to be on eth2 real or masq'd and any custom routing. I've tried everything I can think of. including a same and different internal IP, another of my real world IP's you name it. routes?? and maybe howto??
DMZ box
eth0 tried internal IP, real world IP......all in pairs because AFAIK if the subnet isn't the same and the networks are different they wont ping. the only life out there I get is when I use and internal IP like 192.168.0.1 on eth2 for the firewall and 192.168.0.2 on the DMZ. then I can ping from firewall to DMZ and vice versa. but when I go from there to try and use the FW_FORWARD_MASQ, I still can't get in from home on the outside. the only reason I'm pursuing the masq setup is I can't get anything else to ping. I'd prefer to do it the other way but it's not getting anywhere. so here's the snip from the masq field:
# Which services accessed from the internet should be allowed to masqueraded # servers (on the internal network or dmz)? # REQUIRES: FW_ROUTE # # With this option you may allow access to e.g. your mailserver. The # machines must be in a masqueraded segment and may not have public IP addesses! # Hint: if FW_DEV_MASQ is set to the external interface you have to set # FW_FORWARD from internal to DMZ for the service as well to allow access # from internal! # # Please note that this should *not* be used for security reasons! You are # opening a hole to your precious internal network. If e.g. the webserver there # is compromised - your full internal network is compromised!! # # Choice: leave empty (good choice!) or use the following explained syntax # of forward masquerade rules, seperated each by a space. # A forward masquerade rule consists of 1) source IP/net, 2) destination IP # (dmz/intern), 3) a protocol (tcp/udp only!) and 4) destination port, # seperated by a comma (","), e.g. "4.0.0.0/8,1.1.1.1,tcp,80" # Optional is a port after the destination port, to redirect the request to # a different destination port on the destination IP, e.g. # "4.0.0.0/8,1.1.1.1,tcp,80,81" # FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" # Beware to use this!
Any help would be appreciated. I'm feeling beat up by what should be so simple... :^(
Mike
-- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
participants (4)
-
maarten van den Berg -
Mike Branda -
suse＠rio.vg -
Togan Muftuoglu