header-logo-left

The Lone Geek Blog

One geek in a sea of nerds.

header-logo-left

The Pfsense Box - Part 2

An update in my adventures of being a sysadmin at home.

| Comments

The Pfsense box - Part 2

Time for an update. I think I’ve figured out how statefull firewalls work now. I have 7 networks configured on it, 4 of them leading back to virtual networks on my server, one of them intended for the wireless network, a OpenVPN network, and the main one is of course my LAN.

The Networks

  • Main LAN - Has access to everything and consists of anything that can’t be placed on a VLAN yet.
  • WLAN - For wireless traffic but likely will be devoted to guest use. Maybe I’ll setup two, each taking a /25 segment.
  • OpenVPN - Not explicitly configured but can access the LAN and LAB_NET when a client connects remotely.
  • DMZ - Intended for one machine or VM at a time. Has no access to any other local network but machines on the Main LAN can access it, mainly for RDP access. I may fine tune the level of incoming access later for just RDP.
  • LAB_NET - For any VMs I don’t want on the LAN but still want access to. VMs here can access preapproved nodes on the LAN and nothing else.
  • WINLAB - For VMs within my Windows Server AD network. Has no outgoing access to anything. It is just setup so I can RDP to the windows VMs. I need to lock down the incoming ports.

All networks but the WINLAB can access the internet at varying degrees to later be defined. It took 13 months before I finally learned how to properly configure the firewall to allow all this to work. Learning the order of operations, how rules can influence how next one below it works, how deny rules placed before an allow rule can block all but allow some packets to flow or something like that.

The DMZ can ping and lookup dns on the pfsense box, is denied access to all RFC1918 addresses, and is only permitted outgoing traffic for ports 80 and 443 to the WAN.

The LAB_NET has 3 deny rules to WINLAB, DMZ, and VLAN100, 3 allow rules to 3 nodes on the LAN and one LAB_NET to ANY with the destination inverted for the LAN. Blocking all outgoing access to the LAN but the ones I allow.

The WINLAB has no rules defined so pfsense just blocks traffic originating within the network.

^ That feels redundant but w/e.

Everything is subject to change as I learn more and build on it. I am currently working on a way to grant guest access to the WLAN and looking at getting a Ubiquity Unifi WAP to replace the two routers turned WAPs and sharing the same SSIDs and passwords and hopefully gain some much desired wireless performance to boot. Our laptops will need a upgrades to their wireless cards but that would be an easy swap.

Firewall - WAN Firewall - LAN Firewall - WLAN Firewall - DMZ Firewall - LAB_NET

Err, small update. I originally wrote this on July 20th and not long after, I managed to break the config of my pfsense box and find out that the SSD I had installed had partially failed to a read-only state. Not even formattable. So I have to resort to using a usb flash drive and recover the lost config to get what I had recently setup back up and running. I still don’t have Suricata, Squid, or pfBlocker running atm as I need to rebuild the configs for them and setup so that they don’t write to my flash drive and kill it. In due time.

I had just configured pfBlocker and was testing and playing with it when I get this wild idea to make /tmp and /var into ramdisks. Not realizing that /var had at least a gigabyte of logs from Suricata and roughly 60gb of Squid Cache. Welp, the system did NOT like that and refused to boot and had the SSD been writeable, I could have easily reverted and recovered the system. The purpose of the ramdisk? To save writes to a disk with over 5TB of writes since I deployed it and only 50GB of reads. Seems backwards but yeah, bad config.

Now the plan is to either deploy the OS on flash media and save logs and cache to a spinning hard drive. I’d probably only need to just mount the hard drive to /var and /tmp to ram manually in the /etc/fstab file and be set. Perhaps some work in a lab and/or googling might help with this study. :)

So um, cheers. Keep hacking the things!

Comments