pfSense – Learning And Making My Life Harder !
I’ve been using pfSense as the firewall for my home virtual lab for many years and it has increased me knowledge of firewalls by giving me one to play with in my own environment. As a consultant it’s proved invaluable for me in my job as it’s allowed me to quickly test what ports are needed to be opened for various applications, work out routing roulette issues I’ve seen on site, and even simulate setting up Active Directory Domain Trusts over an IPSec VPN.
Up until recently my home lab has been a fairly flat network topology using one main VLAN for my servers and one for PVS traffic. Other VLANs exist like DMZ VLANs where my Citrix ADC lives but aside from that, the server VLAN was the main one being used. I was also guilty of having a default permit any rule in pfSense for the subnet so everything could access the internet and what not which I wanted to lock down.
As part of taking the new LTSR release 1912 of Citrix Virtual Apps and Desktops for a test drive I decided to create a new VLAN for client machine (PVS and MCS VDAs). I also decided to put in a default deny rule on the firewall to control access like in the real world and that’s where things got interesting !
The new VLAN was defined on my Cisco switch and then tagged on the ESXi server virtual traffic ports which was easy enough and then a new interface was also added to my pfSense firewall. A new NIC was also added to my nested Citrix Hypervisor so that machines created on there could also connect to the clients VLAN.
Rules were then added to the firewall for the clients VLAN to allow Active Directory and WSUS traffic which worked fine for the new infrastructure VLAN and allowed me to add a new server to the Domain. Rules were also added to allow RDP, file sharing, and Citrix from the infrastructure VLAN to the new clients VLAN.
I also wanted to use DHCP addressing on the new VLAN without setting up a dedicated DHCP servers so I configured the DHCP Relay service on pfSense to pass DHCP requests to my Domain Controller where I added a new Scope for the subnet.
The guest server was able to obtain a DHCP address fine which was pleasantly surprising but apart from that, nothing else would work like DNS resolution or joining the Domain so it was time to investigate !
Watching the firewall logs didn’t show me anything interesting which could be causing the issue so I decided to troubleshoot from the bottom up by looking at the following:
- The VLAN config on my Cisco switch – Result – OK
- New VLAN number correct
- Assigned to the correct ports on the switch
- The Port groups on my ESXi servers – Result – OK
- Attached to the correct vSwitch
- Promiscuous mode and MAC address changes allowed
- New Port group assignments to VMs – Result – OK
- Assigned to the pfSense VM
- Assigned to the nested Citrix Hypervisor VM
- pfSense configured correctly – Result – FAIL
- New interface added and enabled – OK
- IP details set correctly – FAIL
- The netmask was incorrectly set to /32 when it should be set to /24
So as you can see, the issue was due to the netmask being set incorrectly on the new pfSense interface and once that was changed it all worked as expected !
Some may say that there was an awful lot of things changed and complexities in my environment which probably make life harder but from a professional point of view, it is closer to corporate environments I have worked in. From these environments I have learnt to adopt the bottom up troubleshooting method as well as double checking configurations. I have seen netmask issues cause these issues in the workplace many times and whereas it can be seen as unnecessary to ask network teams to confirm the settings, being methodical and paying attention to details can help to identify root causes a lot quicker !