New pfSense setup with DMZ
-
Hi,
I am seeking some assistance with a new setup of pfSense and more specific how to properly configure a basic DMZ.
The WAN has address xx.xx.xx.230/27 and there are 30 public IPs provided by the ISP. I am trying to split the LAN and the DMZ traffic and allow the webservers/mail servers to use the public IP addresses assigned.
I also want to have the LAN interface connected to the office switch and users able to access the internet through NAT.
The request is that the webservers/mail servers have the public IP address assigned and not use 1on1 NAT with VIPs. The LAN users should be able to access the webservers/mail servers.
I know there's an option to bridge the WAN with an OPT interface and use the bridge as an transparent firewall which seems to be exactly what I am looking for, however, I would like a few more opinions from whoever has more experience with this setup (pros/cons).
If there's are any other way to do this, I'd appreciate your reply.
Thanks!
-
and not use 1on1 NAT with VIPs
Is there some reason you couldn't just port-forward the specific port(s) for the services you want to be externally accessible? I can understand no 1:1 NAT, but bridging the interface seems extreme. I have this exact setup. A DMZ with our mail server, web server, FTP server etc. All handled via IP Alias and forwarded out to WAN.
-
We have also two WAN ports, one LAN port and one DMZ port and all Web, SFTP, Mail and Fax server in the DMZ
but we set up the public IPs at the pfSense and then the DMZ servers gets private internal IPs from the DMZ net.
We where founding this much safer then the other method to set up the public IPs at the DMZ servers directly,
so if something occurs, they are directly on your server in the DMZ. I suggest also to set up Squid & SquidGuard
between the WAN and DMZ interface perhaps with HAVP and also snort it the appliance is powerful enough for
all this services. If you are able to do it would be a good choice to set up a DMZ RADIUS Server so you narrow
down the ability that an intruder would be able to play in the DMZ zone, only a certificate for each LAN member
that should reach a server in the DMZ is needed.And at least please note:
"Route if you can and only brigde if you really must do so!" -
One of the reasons I would rather go with the bridge setup is simplicity. The other is that I was told this is the way it should be done. With the use of a transparent firewall we no longer need to manage VIPs in pfSense and a separate new network for the DMZ. We can just set the IP on the actual server and allow the specific ports we need in the pfSense firewall. I also don't want to go down the path where the server is directly connected to the internet and I need to setup individual firewalls. This is why I enabled filtering on the bridge.
So the setup I am playing with right now looks like this: 1 WAN and 1 LAN which is connected to a main switch. On the switch I've set a tagged VLAN, added a new VLAN interface in pfSense and bridged the WAN with this VLAN. The VLAN is tagged for the LAN port and one other port which goes into the DMZ network. On the VLAN interface I am allowing outbound traffic from my public network, inbound everything is blocked and needs to be opened manually.
What I am trying to understand is what are the security implications of this design?
Is it an issue only because of VLAN tagging?
Why is it more secure when using VIPs?
Would it be more secure to connect an OPT interface from pfSense to another physical switch for the DMZ network?Many thanks for your replies!
-
The way it SHOULD be done is the ISP should assign you a /30 for the WAN interface and route the /27 to your address on that. You could then do whatever you want with your addresses (VIP half of them on WAN and create a DMZ with a /28 for example).
Anything else is a hack.
-
Well, it looks like that's the way they did it - however, they added their own router which handles the routing between /30 and /27. A router which I have no access to.
-
The way it SHOULD be done is the ISP should assign you a /30 for the WAN interface and route the /27 to your address on that. You could then do whatever you want with your addresses (VIP half of them on WAN and create a DMZ with a /28 for example).
Anything else is a hack.
Yes Yes Yes!!! This just came up in another thread…
https://forum.pfsense.org/index.php?topic=96500.0"he other is that I was told this is the way it should be done"
Who told you this?? Sorry but no bridge is prob never the right answer! Unless your talking what mode your "modem" should be from your isp ;) Or used to describe how your VM network is connected to your physical nic, etc..
Can tell for sure if someone told you bridge it, without caveats that this is NOT The best or correct solution but just another way to skin the cat then they are giving you incomplete information or just plain don't have a clue in the first place..
-
One of the reasons I would rather go with the bridge setup is simplicity.
Earlier or later this often ends up with
- port flapping
- throughput decreasing
- IP packet losses & lacking
The other is that I was told this is the way it should be done. With the use of a transparent firewall we no longer need to manage VIPs in pfSense and a separate new network for the DMZ.
There fore a port forwarding to the serves through Squid would be a right and common way.
What I am trying to understand is what are the security implications of this design?
If you point this to the "bridge" their would be no security gain!
Is it an issue only because of VLAN tagging?
VLAN hopping could be a point. In shorter words if "something" occurs I am directly inside of your LAN
area near by all your Servers and PCs! And if this occurs inside of the DMZ (a real DMZ) I am only in your DMZ
and if you where wetting up a DMZ Radius server I can´t connect to nothing.Why is it more secure when using VIPs?
If someone is "playing" with your public IPs he is only at the pfSense firewall and this is a
security devices! And all servers are behind it and also of the Squid, not reachable.But if you set up all the public IPs direct on the DMZ servers and someone is "playing"
with your public IPs he is on the servers directly.Would it be more secure to connect an OPT interface from pfSense to another physical switch for the DMZ network?
In my eyes it is the common way to realize a DMZ.
- Layer2 DMZ Switch
- No VLANs inside DMZ
-
Awesome, I really appreciate the detailed replies!
I start to realize the differences and benefits of not running this setup via a bridge. I was not actually asked to setup a bridge, I was asked to set public IPs directly on the servers and the only solution I found for our setup was via a bridge. At least the practical solution. However, I think the price we have to pay by going with a bridge is too big and based on your answers I am no longer trusting this design. Therefore, I'll try my best to avoid it.
In fact, it looks like what I was looking for is what Derelict mentioned, to be able to route our own public addresses via pfSense. That way I could have directly attached public IPs with a transparent firewall in front of them. However, I don't really believe our ISP will change anything in their setup.
For now, my plan is to go with VIPs and create a proper DMZ network, physically separated from the LAN network.
@ BlueKobold if you have any articles you can share about the DMZ radius server, please do.
Once again, thanks for your help!
-
I would complain to your ISP, how many IPs did you get from them? Did you get a specific /? Or did they give you like 2 IPs to use? If you have a specific block say /27 or /28 then this traffic should be routed to you!! So you can do with it what you want.
If your on a /29 or even a /30 then just use a VIP and either port forward or 1:1 is your best option.
-
It's a /27, but as I said it's all routed through their own router (for which we need to pay rent). I will follow your advice and ask them to have us route the /27.
Thanks!
-
I was asked to set public IPs directly on the servers
You need to strongly tell them this is a very bad idea.
-
For now, my plan is to go with VIPs and create a proper DMZ network, physically separated from the LAN network.
Would be the best way as I see it right, but the explaining from @johnpoz was also really impressive
and logical! If you get at one day new public IP addresses based on whatever circumstances
you only have to change this IPs at the pfSnese firewall.As I was learned there three different main DMZ variants and many hundreds as subcategories.
An Exposed host(do not use it, only if you know why and where)- A dirty and true DMZ (like we do here)
- A clean and true DMZ (dual homed DMZ)
BlueKobold if you have any articles you can share about the DMZ radius server, please do.
There are no documents I will be able to provide to you, but setting up a smaller or greater Linux box
with installed FreeRadius is also no hint or secret. If then someone is trying to join your DMZ, he needs
a certificate, otherwise he would not be able to do so.Ok for sure you must then set up a certificate at each LAN PC or Server to let them communicate
with the DMZ devices, but this depends also all on your security needs. -
@KOM:
I was asked to set public IPs directly on the servers
You need to strongly tell them this is a very bad idea.
It's not a bad idea if they're properly firewalled. I have bridged public WAN IP addresses to customers but only with the stern warning that there is no firewalling done by me and it's intended for the WAN port of a firewall, not a server.
OP, tell your ISP you don't need nor want their router. Is your internet handed off ethernet? (meaning is it ethernet to the upstream ISP router's WAN port?) Tell them you want your subnet routed, not bridged.
-
I don't think it's a bad idea as long as there's a proper firewall. In my setup, the bridge had a firewall so no traffic was reaching the public IPs unless I allowed it. Of course, I will not go with the bridge from other reasons but the servers were not wide open. If I get the chance to route our own IP addresses pfSense will still play the role of a firewall in front of them which is exactly what I'd like. With VIPs I need to assign a public IP, a private IP and set firewall rules. With directly attached public IPs I don't need to manage another private subnet. Our servers are mainly Unix, we have enough public IP addresses to assign one to each server and changing IP addresses would be quite easily done with Ansible.
While I would like to have our subnet routed using our HW, I think it will take more time than I have. So VIPs are now my main option, but I will bring this up with our ISP.
