DMZ with public IPs
-
Ho Folks,
i searched in google, pfsense-docs and monowall-docs but i must admit, i will not succeed without your help
Given a pfSense 2.03 PC with 3 NICs i try to build a network with WAN, LAN and DMZ interface.
Sounds easy but it does not really work. A network diagram is attached to this post.I tried it before with a Zyxel Zywall 35 which seems not to be able to handle the public IPS in the DMZ. It worked before a necessary firmware update. The ISP means, everything is set up right on his side. So i thought it could be easier to do it with pfSense which is also capable of OpenVPN.
WAN: connected to a cable modem which gets the public IP (which is always the same one – xx.xx.xx.11) by DHCP
LAN: 192.168.0.1/24 net
DMZ: my ISP provides me a package of public ip addresses (xx.xx.xx.24/29) which are routed to the head-IP address xx.xx.xx.11
IP: xx.xx.xx.24
Gateway: xx.xx.xx.25
Netmask 255.255.255.248A traceroute from outside to xx.xx.xx.26 reaches the head-ip xx.xx.xx.11 but does not stop there or recognizes xx.xx.xx.26
I've also got a second package of public IP-addresses which I would like to use in the DMZ - but for the moment I would be pleased if the first package would work.
Target:
Configuration of a DMZ with public IP'sProblem: i cannot reach any IP in the DMZ - neither from outside nor from LAN
I followed the following docs:
http://wiki.easycow.de/index.php/PfSense_DMZ_Subnetz_mit_public_IPs
http://www.digitalphotomac.com/PFsense/DMZ/to get at least a 1:1 NAT solution - but I'm not convinced that this ist the best approach.
Possibly a full-NAT solution would me more secure or more flexible.My languages: german, englisch
I live in Vienna, Austria - possibly someone who knows pfSense lives near me to talk about ;-)
I think my requirements are very common and i hope someone could help me further.
Thanks in advance
Karl
-
I think that you do not need NAT or port forwarding at all between WAN and DMZ. You will need rules on WAN to permit traffic (on the ports you want to open up) that is destined for xx.xx.xx.24/29. Once the firewall lets it in, the pfSense routing should find that xx.xx.xx.24/29 is a locally-connected network (DMZ/OPT1) and happily send it on its way to the appropriate machine in the DMZ. The associated traffic in the reverse direction will get back due to the state that is established by the incoming connect.
You can also put whatever pass rules you like on DMZ to let you originate things from machines in the DMZ out to the internet.
Am I missing something? Is it more complicated? -
A DMZ means you are not protecting whatever is connected to that port. I will assume you want this, and are willing to take the risk of your web and mail servers being hacked.
For your web and mail servers, did you set the default gateway xx.xx.xx.25 (the cable modem)? I am fairly sure the pfSense box is supposed to be invisible to the servers.
Why is the WAN side of the pfSense not inside your static block? Does it have a private IP address (10.x.x.11) issued by the modem? Did you try setting a static IP on the WAN interface inside the static block?
If you would prefer a full-NAT solution, you could use one static IP for your entire network (assigned to pfSense WAN port) and forward incoming port 80 (443 too?) and whatever the mail server uses to the appropriate servers. You could also try 1:1 NAT, but I'm not completely sure how that works. I'm not sure if the WAN interface on pfSense would listen and accept traffic destined for multiple IP addresses automatically, or if that is something you have to set up.
-
A DMZ means you are not protecting whatever is connected to that port. I will assume you want this, and are willing to take the risk of your web and mail servers being hacked.
This is a common misconception largely brought about by its usage by home network router vendors' use/misuse of the term "DMZ."
In the setting of pfsense and the other more professional routing/firewall solutions, a DMZ network is one fully isolated from the LAN network(s) by default; the purpose of such isolation being to protect a LAN network's machines from attack in case a DMZ network machine were to become compromised.
-
For your web and mail servers, did you set the default gateway xx.xx.xx.25 (the cable modem)? I am fairly sure the pfSense box is supposed to be invisible to the servers.
IMHO the servers in the DMZ have to have the pfSense DMZ IP as their gateway. That is the only way out for them from their subnet to the rest of the world.
In this kind of situation, the pfSense is being a "normal" internet router. The internet (ISP) is routing packets for the allocated DMZ public IP subnet to the pfSense, and expecting it to route them to the destination. The pfSense role here is to route the packets, and to front-end filter incoming stuff, so the servers in the DMZ only get necessary open ports accessed/attacked. There is no point letting everything through to the DMZ servers - they would appreciate a bit of protection from random scans/attacks on other ports.
The role pfSense does NOT have to perform is NAT/port-forwarding, as the DMZ already has real public IP addresses. -
A DMZ means you are not protecting whatever is connected to that port. I will assume you want this, and are willing to take the risk of your web and mail servers being hacked.
For your web and mail servers, did you set the default gateway xx.xx.xx.25 (the cable modem)? I am fairly sure the pfSense box is supposed to be invisible to the servers.
Why is the WAN side of the pfSense not inside your static block? Does it have a private IP address (10.x.x.11) issued by the modem? Did you try setting a static IP on the WAN interface inside the static block?
If you would prefer a full-NAT solution, you could use one static IP for your entire network (assigned to pfSense WAN port) and forward incoming port 80 (443 too?) and whatever the mail server uses to the appropriate servers. You could also try 1:1 NAT, but I'm not completely sure how that works. I'm not sure if the WAN interface on pfSense would listen and accept traffic destined for multiple IP addresses automatically, or if that is something you have to set up.
Hi - Thanks for answering.
I know what a real DMZ is and i will use it as an isolated unit which provides different services which must be accessible from the internet.
Therefore and to assign different services to public IP adresses i think this layout would be the second best.
I do not prefer a full-NAT solution with one single public IP because I think it ist not flexible enough even for mailservers and VOIP solutions.What i don't know ist what i have to do that the WAN interface recognizes that e.g. xx.xx.xx.26 has to be routed to the DMZ subnet
-
the purpose of such isolation being to protect a LAN network's machines from attack in case a DMZ network machine were to become compromised.
i absolutely agree with this statement :-)
-
For your web and mail servers, did you set the default gateway xx.xx.xx.25 (the cable modem)? I am fairly sure the pfSense box is supposed to be invisible to the servers.
IMHO the servers in the DMZ have to have the pfSense DMZ IP as their gateway. That is the only way out for them from their subnet to the rest of the world.
In this kind of situation, the pfSense is being a "normal" internet router. The internet (ISP) is routing packets for the allocated DMZ public IP subnet to the pfSense, and expecting it to route them to the destination. The pfSense role here is to route the packets, and to front-end filter incoming stuff, so the servers in the DMZ only get necessary open ports accessed/attacked. There is no point letting everything through to the DMZ servers - they would appreciate a bit of protection from random scans/attacks on other ports.ok - but from this point of view (which is also my own one) an fully 1:1 bridging is not apreciated.
The role pfSense does NOT have to perform is NAT/port-forwarding, as the DMZ already has real public IP addresses.
yes, but exactly this is my problem – 1:1 bridging which i have tested as a hopefully working approach does not work and i do not know what to do to tell the WAN interface to accept public DMZ IP's