Archive for December, 2013

Post

PFSense with transparent bridging (and VMWare)

So I had a hard time setting up PFSense, which is a good, open source firewall, if you put the time into it.  In fact, I’ve used it in critical environments when the ability to get a high end Watchguard or “other” firewall wasn’t an option and have enjoyed its performance, but that’s one guy’s opinion.  Regardless, here’s my project, I hope it helps you out!

– Use PFSense

– Create a public DMZ where I could continue to use my /29 network for servers.  I wanted to host mail, web, and more while running an IPS (Snort) with it.

– All of this is done through virtual switching in VMWare, though would work on a physical switch, too.

 

So, the basic pfsense setup won’t be covered, but here’s what I did after that.  On the VMWare box that was hosting the PFSense, I had a WAN switch, LAN switch, and a DMZ switch, I created one adapter for each switch and bound it to my pfsense box.  The LAN will not be discussed going forward in this article, but nothing special is needed beside rules to allow DMZ –> LAN and LAN –> DMZ.   Also, when creating the DMZ adapter, make sure you choose “None” for the IPv4 configuration.  You need to remember that this is quietly in the middle of the process and that can be confusing for some newer network engineers.  You don’t need an IP address to be a firewall, you just need to be able to stop the packet from continuing. Here’s a really important part for the VMWare users who are using virtual switches, put the VMWare switch in to promiscuous mode on the WAN and DMZ adapters, otherwise the pfsense box will never see all of the traffic it needs or allow traffic in, but not out or vise versa depending on what is promiscuous and what isn’t.

 

 

From there, put your DMZ and WAN into a bridge… This seems a little confusing at first in pfsense, but you need to think about it this way.  Your public devices will be in the DMZ and will be in theory connected to the WAN port, but the pfsense box is sitting in between the DMZ and WAN as a chokepoint between the traffic, think of an hourglass passing sand between the two chambers.

From there, if you create WAN rules pointing from Any –> Public IP, it will control the traffic from passing through due to that hourglass effect.  You do not need to NAT anything because, after all, this is a public IP and you bridged the adapters together.  Just open all the ports you need, but don’t forget to create an outbound rule from the DMZ allowing your traffic out, too.  May I suggest that you just create an allow all from the public ip in the dmz to any for basic t-shooting before you lock everything down for good egress filtering.Once you have it working, you can enable Snort or traffic shaping to get the most out of your bandwidth. Good times!

So, some Q&A that is bound to come up:

 

Q. I read on a ton of sites that a Virtual IP is needed, why not here?

A. Virtual IPs make sense when you are NATing the traffic into the firewall rather than setting up a true DMZ. I think what is lost from training on newer network guys is the difference between NATing and Port Forwarding vs. a public DMZ.  NATing makes sense for a home network where you want to keep that “server” or device on the same network as your LAN, but for the bad guys, putting your public facing servers on your LAN with port forwarding and NATing makes it easier to own the network.  If they can breach the server in the LAN that is part of the port forwarding and NATing setup you would have, then they can attack the LAN.  With the public DMZ, they are stuck there and have to go another hop to get to the LAN.  Back to the original question, if PFSense needs to answer on behalf of the device hiding back in the LAN, the Virtual IP will tell pfsense to field requests to that IP, which isn’t what you want to do, you want your public server to do that.

Q. Is the WAN IP of the pfsense box the gateway for my public device that is in the DMZ or is the upstream router?

A. It’s the upstream router, because remember, the bridge is the chokepoint for traffic and the management will happen there.  If you forward to the WAN IP of the pfsense box, then you are introducing an extra hop because the pfsense box is just going to push it up to the upstream router.  Then when packets come back to your public device, the upstream router will just go the public IP anyway.  The filtering of your traffic will be done quietly and without IPs, so it doesn’t matter where the gateway is because the pfsense is between your public IP host and the default gateway.