Making my home network overly complicated.. vBest Practices?
-
Hi. New pfSense user here. A couple months ago I decided I wanted to revamp my home network from the ground up. I'm in IT and just want to learn more in general, so I figured I might as well make my home network ridiculously over complicated. My goal is almost like an enterprise network, only an extremely smaller scale. :)
Overall Goal– Create a secure network with multiple VLANs. Learn how to allow and deny certain networks to talk to each other and setup a reason for it. Create a VMware lab and Active Directory domain with various services running. That's the basic idea. I'm sure I'll think of more as time goes on.
How things are setup now--
Booksize Atom PC with 5 physical network interfaces running 64 bit pfSense.WAN - em0 - Comcast Internet with a DHCP IP.
LAN - em1 - Internal IP of 10.17.1.1, giving out DHCP range of 10.17.1.200 - 10.17.1.254.HP ProCurve 1810G-24P managed switch with a static IP of 10.17.1.2.
LAN physical interface is plugged into port 1 of the ProCurve.
Airport Extreme is in bridge mode and plugged into port 24 on the ProCurve.All is working well, but before I start diving into making it more complex, I want to be sure I have everything setup according to best practices that are widely used today.
1. The main LAN IP is 10.17.1.1 and the managed switch is 10.17.1.2. I know these really don't matter but in the enterprise world, is there a specific IP address that routers and switches are given? For example, I know home routers usually get 192.168.1.1, but do they in the enterprise world? Just curious on the "standard" IP convention for routers and managed switches. Is there usually a VLAN setup only for managing routers/switches/other systems?
I ask because I'm wondering if I should set this up differently. Please read on before replying...
2. I eventually want to setup 1-4 VLANs/subnets just because I can and want to learn. :) 1 for servers, 1 for wireless, 1 for DMZ, and maybe a 4th for whatever I come up with someday. I have 3 physical interfaces free on the pfSense box. I was trying to move my Airport from the managed switch to it's own interface in pfSense. That way wireless clients could be on their own subnet. I setup em2 as the WIFI interface and setup DHCP server for it. Clients were getting the correct IP addresses from DHCP but couldn't get external DNS resolutions, which means no Internet access. I still can't fully get my head around the firewall rules and after reading multiple conflicting how to's, I gave up and put the Airport back on port 24 of the switch.
3. Regarding the DMZ-- I've read a ton of how to's on setting one up and most just didn't sound/seem right. Then I found this...
http://www.digitalphotomac.com/PFsense/DMZ/
All makes perfect since except..
Next, we'll need to create a new rule to allow all traffic from the DMZ to the internet:
Action: select Pass
Disabled: leave unchecked
Interface: select DMZ
Protocol: select any
Source: select DMZ subnet
Destination: click the not box and select LAN Subnet in the Type: field
Gateway: set to default
Description: type a description for your rule. Then save.This rule is to allow traffic from the DMZ to go to the WAN (Internet). Shouldn't the destination be set to the WAN subnet? Setting the destination as NOT LAN would allow any DMZ traffic to go to the WAN subnet but also any other subnets you might have and only restrict traffic to the LAN subnet. Setting the destination as the WAN subnet would only allow DMZ traffic to go to the Internet and block it from any internal networks. Is there something I'm missing?
This post turned out way longer than I originally planned. I figured I had to share some details of what I'd like to accomplish at some point.
Main point of this topic, I'm wondering if I should reconfigure pfSense and the switch before setting up everything else. I want to get pfSense setup right the first time, not realize later that I missed something.
1. What are the best practices of setting up a router/firewall and managed switch on a new network? Are there specific IPs that are usually used for them?
2. The way I have things right now, the LAN interface is pretty much only for management since I use the 10.17.1.x range for pfSense and the ProCurve. I want a VLAN for my VMware ESXi server(s), Windows Active Directory servers, and NAS; another subnet/VLAN for wireless; and another subnet/VLAN for DMZ. I won't have any wired clients that aren't servers other than possibly some Windows 7 virtuals in ESXi.
Should I make the interface I call LAN right now be a management subnet only? It would only be used for pfSense, the ProCurve, vSphere management network, and whatever other hardware that comes along that has a built in management console.
3. Can anyone point me to an article that explains firewall rules like I'm five years old? I get the concept, but planning them out and testing with trial and error gets frustrating. And again, I'm clueless about basic best practices. One example– rules for blocking the DMZ from the internal subnet(s) and passing DMZ traffic to the WAN. Should all rules for that be made on the DMZ interface only or would the WAN rule be made on the WAN interface?
Any details on best practices for this and any other suggestions are GREATLY appreciated. I know I'm extremely overcomplicating this, but I just want to learn and get a good grasp of how it all works in the corporate world. Keeping it simple and setting it up the easy way can only teach so much. shrug
My brain is kinda fried from reading so much on pfSense in the past three weeks trying to learn proper interface/VLAN/rule setup and trying to workout the best way to set everything up. I know my OCD and tendency to over think isn't helping me at all. 8)
-
The best "best practice" I can offer is this: Don't make anything more complex than it has to be in order to be functional.
If you build it, you have to manage it. If it's complex, trying to troubleshoot and remediate it becomes a much larger task that it could have been.
I think it's commendable that you want to learn more, and this is a good way to do it. However, another best practice I can offer is: Change one thing at a time.
If you're initial setup works fine and is a simple pfSense wizard setup, great. Go through all of the configurations and settings to understand how the wizard set it up. Start learning about some of the built-in pfSense utilities and the logging features. Something to try is port scanning yourself from a known external IP address. See what happens to the logs so you understand how to interpret them. 80% of the battle is understanding the wealth of information pfSense will give you, the other 20% is knowing what to do with that information. As you add layers of complexity to the system, people here are going to ask you what your logs say when you ask for help. It's where most troubleshooting begins. Learn how to use every tool in the Diagnostics menu. Learn how to interpret the messages in the Status menu. That's the third best practice: Learn how to interpret log files.
You've got some good questions in your post, but the above best practices are where you should start. As you layer on more and more complexity, things will go completely wrong. It's natural and part of the learning process. Your ability to identify the root cause and remediate it makes all the difference between a good and great network engineer.
Best of luck with your project!
-
Thanks for the encouraging words Tim! While I somewhat agree with your "Don't make anything more complex than it has to be in order to be functional" comment, if I was going by that rationale then my Airport Extreme would still be in place and I would've never signed up for this forum. :)
I completely understand why the wizard set it up how it did. I'd just really like to know the usual router/firewall/managed switch setup practices before I start making more changes to pfSense. I'd rather start from scratch now than learn something I wish I knew from the beginning.
Reading the logs is one of top three things that I wish I knew right now. I figured I'd learn them more as I use pfSense more. I was looking at some of the logs last night and I understand most of it but some things like why a certain external IP is trying to communicate with certain internal IPs. I installed Snort last week and it's been throwing some alerts that aren't real alerts. I know research comes into play with all of this, but I really want to get to the point of being able to read the logs/alerts and understand why they're happening, what they mean, and if they need to be taken seriously.
I understand a syslog server is just a central location for any logs created by systems on the network, but does having one make log reading and troubleshooting any different besides logs just being in a central location?
Again, my OCD and tendency to over think everything until I have a solid explanation for it does get in the way most of the time. I just like knowing every little detail and want to set everything up according to the best real world practices, if possible.
-
Here are some insights for your questions above. You have two sets of three:
Set 1:
1 - No. Every network is different and every network engineer is different. The key here is creating the same set of standards for each site (or for all sites). You could for example designate 10.0.1.1-10.0.1.10 for all networking devices, 11-20 for printers, 21-30 for server, and then 100-200 for DHCP or some combination thereof. I've seen all flavors of ranges for different reasons. You'd have a different template for a data center versus a campus environment versus VPNs, etc.
2 - Firewalls rules are conceptually pretty easy. Think of it as a traffic cop that lets "what go where". You'll see that pfSense creates an Anti-Lockout Rule that is the first rule in the list. Ports 80 and 22 won't be blocked. Then there is the Default LAN -> Any rule. This allows your default LAN subnet access to any other interface. I have two gateways on my pfSense box and two LANs. I have a legacy server on my 10.0.1.x/24 network that I didn't migrate over to the "server' LAN at 10.0.2.x/24. The server subnet uses a different gateway than the user subnet. In order to ensure incoming and outgoing traffic went to the proper gateway, I created a rule on my LAN that takes all traffic, regardless of the source, out of the server WAN even though it's on the user LAN. So the same can be applied in your case where you want some or all of one network to access so or all of a different network. Or, you could silo every network but allow them all to use the same gateway, so they all have Internet connectivity but cannot talk to one another. Source and destination are where you want to start.
3. The DMZ instructions you posted explicitly deny everything but DNS queries from entering the LAN. They treat the DMZ as an isolated network, which is what it should be.
Set 2:
1. No. Review your entire network and what you want to do with it and then create the ranges you want to manage.
2. That's up to you.
3. You can check the pfSense docs, they are sparse, but give you just enough direction. There is also the pfSense book available at Amazon (book link) that might be a good place to start. Although it focuses mainly on 1.2.3, the same concepts apply in 2.x. I haven't read the book, but there are sections on firewall rules and they have some examples in there. Firewall rules are pretty logical and are executed from top to bottom. So for example if you want to allow DNS to go back into the LAN (like in the DMZ example) the rule allowing port 53 to go back into the LAN must appear above (or before) the rule preventing all traffic from going to the LAN. If they were switched, the deny all rule would be executed first and the allow 53 would never be executed. It's a "first match" system. First rule that matches is applied and anything beyond that is not executed.
Oh, and IMHO VLANs are more of a PITA than firewall rules. If I can I usually physically separate network where it is possible.
-
3. Regarding the DMZ– I've read a ton of how-tos on setting one up and most just didn't sound/seem right. Then I found this...
http://www.digitalphotomac.com/PFsense/DMZ/
All makes perfect since except..
Next, we'll need to create a new rule to allow all traffic from the DMZ to the internet:
Action: select Pass
Disabled: leave unchecked
Interface: select DMZ
Protocol: select any
Source: select DMZ subnet
Destination: click the not box and select LAN Subnet in the Type: field
Gateway: set to default
Description: type a description for your rule. Then save.This rule is to allow traffic from the DMZ to go to the WAN (Internet). Shouldn't the destination be set to the WAN subnet? Setting the destination as NOT LAN would allow any DMZ traffic to go to the WAN subnet but also any other subnets you might have and only restrict traffic to the LAN subnet. Setting the destination as the WAN subnet would only allow DMZ traffic to go to the Internet and block it from any internal networks. Is there something I'm missing?
Tim has explained this but additionally…
In the above example they have put in the destination field 'not LAN subnet'. This means that any packet that has a destination that isn't in the LAN subnet will be allowed. This type of rule would be typical for a 'DMZ' type setup where you don't want machines on that interface to be able to access machines on your private LAN.
The instructions in the link you gave are now very old (2008) so they refer to an early version of pfSense. In 2.0.x things work slightly differently but the principles are the same. All packets will be blocked by default so there is no need to create the 'block' that they do in the example, traffic to LAN will be blocked.
One thing to note is that the set of rules given would allow access to the pfSense box itself, since it is in all subnets, and hence to the webgui and ssh interfaces. These would be possible attack surfaces for a compromised machine in the DMZ so it would be better to block that traffic unless you need it.I am in a similar position to you. My home network is massively and unnecessarily complex (no VLANs currently though ;)) but great for experimenting.
Steve
-
Here are some insights for your questions above. You have two sets of three:
Set 1:
2 - Firewalls rules are conceptually pretty easy. Think of it as a traffic cop that lets "what go where". You'll see that pfSense creates an Anti-Lockout Rule that is the first rule in the list. Ports 80 and 22 won't be blocked. Then there is the Default LAN -> Any rule. This allows your default LAN subnet access to any other interface. I have two gateways on my pfSense box and two LANs. I have a legacy server on my 10.0.1.x/24 network that I didn't migrate over to the "server' LAN at 10.0.2.x/24. The server subnet uses a different gateway than the user subnet. In order to ensure incoming and outgoing traffic went to the proper gateway, I created a rule on my LAN that takes all traffic, regardless of the source, out of the server WAN even though it's on the user LAN. So the same can be applied in your case where you want some or all of one network to access so or all of a different network. Or, you could silo every network but allow them all to use the same gateway, so they all have Internet connectivity but cannot talk to one another. Source and destination are where you want to start.
You have two gateways meaning you have two WAN connections or that you have a different gateway IP setup for each of the two LANs? If it's the latter, then that's what I was trying to confirm. All the tutorials I've read about creating a new LAN subnet on a physical interface or creating a new VLAN said that once you assign a static IP to it, that IP is the gateway for that subnet. And when I create the DHCP server for the new subnet, the interface/VLAN static IP is passed out as the gateway.
And I realize now that the reason I wasn't getting any WAN access from the new subnet was because I didn't setup any firewall rules, so it couldn't get Internet DNS resolution.
3. The DMZ instructions you posted explicitly deny everything but DNS queries from entering the LAN. They treat the DMZ as an isolated network, which is what it should be.
Lets say I have LAN, LAN2, and LAN3 setup for different subnets. I know this rule denies traffic to the LAN from the DMZ, but what about traffic to LAN2 and LAN3? The way I read it, by setting the destination as NOT LAN sounds like it would pass traffic to LAN2 and LAN3 but NOT LAN.
The first rule created in the tutorial specifically blocks DMZ traffic to the LAN subnet. The second rule (the one I'm asking about) passes DMZ traffic with the destination set to NOT LAN subnet. Wouldn't it make more sense to set the pass rule destination to WAN since the first block rule already blocks to the LAN? Then create another block rule for each LAN subnet?
Steve's explanation makes a little more sense to me, but I'm still confused. Which is probably because my mind is all over the place with this stuff. :)
So, if I have 3 LAN subnets, for the DMZ to work properly I would have to create a block and pass rule for each LAN subnet? Would I create all the block rules first then the passes or would it be block, pass, block, pass, etc?
3. You can check the pfSense docs, they are sparse, but give you just enough direction. There is also the pfSense book available at Amazon (book link) that might be a good place to start. Although it focuses mainly on 1.2.3, the same concepts apply in 2.x. I haven't read the book, but there are sections on firewall rules and they have some examples in there. Firewall rules are pretty logical and are executed from top to bottom. So for example if you want to allow DNS to go back into the LAN (like in the DMZ example) the rule allowing port 53 to go back into the LAN must appear above (or before) the rule preventing all traffic from going to the LAN. If they were switched, the deny all rule would be executed first and the allow 53 would never be executed. It's a "first match" system. First rule that matches is applied and anything beyond that is not executed.
Oh, and IMHO VLANs are more of a PITA than firewall rules. If I can I usually physically separate network where it is possible.
The "first match system" explanation makes so much more sense now. Now I understand that the rules aren't working together, they're just being ran through from top to bottom until something fits. Now I'm more overwhelmed because it seems more complicated to write proper rules.
-
3. Regarding the DMZ– I've read a ton of how-tos on setting one up and most just didn't sound/seem right. Then I found this...
http://www.digitalphotomac.com/PFsense/DMZ/
All makes perfect since except..
Next, we'll need to create a new rule to allow all traffic from the DMZ to the internet:
Action: select Pass
Disabled: leave unchecked
Interface: select DMZ
Protocol: select any
Source: select DMZ subnet
Destination: click the not box and select LAN Subnet in the Type: field
Gateway: set to default
Description: type a description for your rule. Then save.This rule is to allow traffic from the DMZ to go to the WAN (Internet). Shouldn't the destination be set to the WAN subnet? Setting the destination as NOT LAN would allow any DMZ traffic to go to the WAN subnet but also any other subnets you might have and only restrict traffic to the LAN subnet. Setting the destination as the WAN subnet would only allow DMZ traffic to go to the Internet and block it from any internal networks. Is there something I'm missing?
Tim has explained this but additionally…
In the above example they have put in the destination field 'not LAN subnet'. This means that any packet that has a destination that isn't in the LAN subnet will be allowed. This type of rule would be typical for a 'DMZ' type setup where you don't want machines on that interface to be able to access machines on your private LAN.
The instructions in the link you gave are now very old (2008) so they refer to an early version of pfSense. In 2.0.x things work slightly differently but the principles are the same. All packets will be blocked by default so there is no need to create the 'block' that they do in the example, traffic to LAN will be blocked.
One thing to note is that the set of rules given would allow access to the pfSense box itself, since it is in all subnets, and hence to the webgui and ssh interfaces. These would be possible attack surfaces for a compromised machine in the DMZ so it would be better to block that traffic unless you need it.I am in a similar position to you. My home network is massively and unnecessarily complex (no VLANs currently though ;)) but great for experimenting.
Steve
As I mentioned above, does that mean that if I have LAN2 and LAN3 as different subnets, do I have to create separate block/pass rules that match for them?
If so, what order? 3 block rules then 3 pass rules? Or block, pass, block, pass, etc?
Thanks for both your replies. Much appreciated!
-
I have two physical WANs (WAN and WAN2). One is a residential ISP setup with DHCP and the other is a business ISP setup with five static IPs. I also have two physical LANs. LAN uses WAN as it's gateway. LAN2 uses WAN2 as it's gateway. However, the legacy server on the LAN has a firewall rule to route all traffic regardless of the source out of WAN2.
Here's the messed up reason for it. First, I'm lazy and didn't feel like moving the server and potentially breaking its services by changing its IP address. So I created a firewall rule to essentially do the same thing. So even if an email is sent from a device on the LAN, it will route out WAN2, and the same goes for incoming emails or requests, they will route out WAN2. The real reason I had to do it was because my ISP, through SpamHAUS, added their entire residential IP list to SpamHAUS's blacklist. This is even though the ISP allows port 25 and 80 to be open and used for email and web servers. After several months of trying to get around it, I had to get the second business WAN connection to avoid being blacklisted. As I type I am already moving legacy services off the older LAN server onto a new CentOS 6 VM on the business LAN2.
A DMZ is a DMZ. It is used in a case where you have the same physical network but want to share a resource to the Internet while keeping the rest of the internal physical network safe. To do this you need to avoid creating any attack vectors. So, for a DMZ you never want to (or significantly minimize) any access to the internal network. Every port you open into your network is a potential attack vector.
As an attacker the only thing in a DMZ I can access are those devices in the DMZ. If you didn't use a DMZ and instead hosted a web server with FTP and SSH open to the Internet on your LAN, an attacker who compromises that server can very easily leapfrog over to every other device on your network. There are enough SIP and printer hacks out there to make anyone worry. A DMZ is designed to significantly reduce that risk. Yes, it's a pain in the ass to access it, but that also goes for any attacker too. Welcome to the first WTF in your overly complex home network.
Don't let firewall rules overwhelm you. Get a piece of paper and a pencil and draw this stuff out. Networking is all about planning and structure. We touched a little on structure when you asked about IP ranges and such. Start there. Then draw out on a piece of paper what you want to do. It'll help you visualize the rules. Draw arrows indicating traffic directions, label them with protocols, and your rules will start appearing in front of you. Start simple and then build the complexity.
-
As I mentioned above, does that mean that if I have LAN2 and LAN3 as different subnets, do I have to create separate block/pass rules that match for them?
If you have many internal subnets and you want to block access to any of them from the DMZ you have a few choices.
As I said by default everything is blocked. If you add a new interface but don't put any firewall rules on it the only that will be allowed is DHCP (assuming you have set a dhcp server on it). The only exception to this is the LAN interface which has some rules added by default as you can see.You could add BLOCK rules that have destination LAN* subnet at the top of the list. Traffic coming into the interface will be matched against one of these if is for a local LAN. Once it has matched it will be blocked, no further action is taken on that packet. Then add a rule below the block rules to allow out any traffic you wish to allow.
I have 11 subnets on my home box and adding 10 block rules on an interface is time consuming and makes the firewall rules table harder to read. Instead I have created an ALIAS that contains all my local subnets in a list, I called it LOCAL.
Then I have a single firewall rule that is ALLOW traffic with destination 'not LOCAL'. Much easier to read but doing just that does not allow traffic to the local DNS forwarder, even on the same interface. So I have an additional rule ALLOW traffic with destination LAN(whichever interface this is) subnet on port 53.
I use this on a guest wifi interface. Doing this does not block traffic to the pfSense webgui listening on the WAN so you must add a block rule or add it to the ALIAS if you don't want this.Steve
