I have a PFSense with 2 other VLANs working no issue and I am trying to setup a third VLAN for a VOIP network. The systems using this VLAN will all be either VM’s on an ESXI server or physical desktop phones (Grandstream). I have the ESXI servers configured with the additional VLAN (same as the other VLANs alreday in use). On the PFSense I added a VLAN and an Interface using the VLAN (also, just like the other 2 already in place) and configured a DHCP server on PFSense for the VLAN (just like one of the other VLANS already in place). I added a default any:any rule to the firewall in the new VLAN tab. 2 VM’s are setup on the ESXI server and attached to the new VLAN port group and they can talk to each other fine. One of the VM’s gets its IP via DHCP and that is working as it should so I dont think this is an issue between ESXi and PFSense, nor do I think the Cisco switch in between has any bearing on it (all involved ports are set as trunk with all the vlans allowed).
But…neither VM is able to access the Internet through PFSense. After some troubleshooting and packet tracing I see the traffic from the new VLAN is being blocked by the “Default deny rule IPv4 (1000000103)”.
I thought once there is a firewall rule to allow any:any then that overrides the default deny rule?
I have double and triple-checked this configuration against the other known and working VLANs on PFSense and with the exception of IP addresses and VLAN Tags they are identical…even down to the any:any rule.
What did i miss?
Check the order of your firewall rules. They are applied in order from top to bottom. If you have them in an incorrect order that may be an issue
There is just the one firewall rule on the VOIP tab and that is the any:any rule I setup.
I am not an expert by any means of this so I am essentially copying what is already there for the new VLAN.
Any other thoughts?
Check the dns settings in the dhcp settings.
Can you post a screenshot of the rule for the affected network
AFAIK, the default rules only come out to play when no other rule is matched. You mentioned that you have a rule in place, maybe this is not being matched (if it was, it’d be logged). Maybe try to make it more specific like for TCP only?
Also, way out of my depth here, but I thought trunk ports untag the VLAN identifier, thus enabling all traffic to pass. It might be worthwhile checking for VLAN tags on the LAN side of pfSense i.e. from your Cisco router. If no VLAN tags, maybe pfSense is dropping them?
Ok I found the problem.
When running a filter reload I kept getting an error:
"There were error(s) loading the rules: /tmp/rules.debug:25: cannot define table bogonsv6: Cannot allocate memory - The line in question reads : table persist file “/etc/bogonsv6"”
When I “Apply Changes” on the Rules section of the Firewall tab there was no indication there was anything wrong.
Some Google Fu on that showed systems with PFBlockerNG on them need the “Maximum Table Entries” field in System->Advanced->Firewall & NAT increased. The number to input differered but after trial and error I found after entering 1000000 in there and reloading the filters again not only was the error gone but now have access to the Internet on the errant VLAN.
I didnt mention PFBlocker in my original post because at one time I tried it on this firewall but since took it off, so never thought it would still play a role somehow. The rules it created were still there and disabled, but I guess PFSense still counts as as a rule regardless?
So now it makes sense why PFSense was invoking the default blocking rule because the filter reload was never completing and the new rule was never being added to the table?
Anyway, thank you for the suggestions…now off to see if I can figure out FreePBX (and I may try PFBlockerNG again:-)…