Firewall rules not working except on WAN . PFSENSE 2.2.2 behind vSphere

  • Hi, i've got a bit of a problem…

    I use PFsense 2.2.2 in an vSphere envoriment with 2xVMX 3 nics

    As i was setting up a new vlan and was finishing by testing the rules i noticed that everything was bypassed.
    I could ping between all nets no matter what rules i made...

    I then tried to trafic other nets previously blocked from each other and all trafic pass...

    I've also checked 3 different pfsense setups of mine and all suffer from this...

    Wan rules work but other net's does not...

    Ideas ?

  • Banned

    Need to show the rules.

  • LAYER 8 Global Moderator

    Lets see how its setup on esxi and your rules.  I run pfsense on esxi and don't have any issues firewalling between segments.  Both physical and vlans

  • This is the setup of the test vSphere enviroment where its running + test rules.

    Even tough it's set to block everything it passes the ping right through…

  • What happens if you use actual clients instead of using pfSense's own interfaces?  Your rules should block all IP4 traffic, but I suspect that pfSense exempts its own interfaces or this would not work.

  • it works aswell…

    All rules except them on wan make no difference what so ever.

    I'll install 2.1.5 later tonight to see if it's the same..

  • Also, you should simplify things by removing the block rule you have on those two interfaces.  Everything not explicitly allowed is already blocked, so those rules are redundant.  I'm wondering if pf is even running.  Anything in your System log?

  • LAYER 8 Global Moderator

    and what physical network do these 4 interfaces connect too..  Is that a lagg to the physical switch?  What is the configuration on the physical switch ports?

    I sure would not do it that way.  I break out my vswitches to specific physical nics, which are on their own vlans and then 1 is a trunk that has vlan that is running on that physical network.

    See the trunk on the wlan port group.

    I would really break out your vmkern and vmotion stuff to its own physical nic - I saw a huge performance increase moving stuff to and from datastore and physical machines when I broke out the vmkern to its own physical nic.

  • Question. Does a ping originating from the firewall actually obey the firewall rules? I was under the impression that the rules are applied on data coming in from the physical interface.

  • The reason for this is that the nics are load balanced by esxi, The nics are connected to trunks. This works great and provides a good failsafe and provides all kind of pros like all switchports may have same config, subnets are handled with software and not nics..

    The Esxi networking is not the problem, Atleast not the switch when pinging from a net to another it never leaves router so it's related to pfsense / it's "hardware".

    Also this problem occurs on my system where internal lan doesnt even have a connected nic.

    Regarding the rules i know KOM but just to show that it doesnt give a shit about my rules…

    Harry, You choose from which interface you ping as you see in the print , from SERVER net to Public net.

  • LAYER 8 Global Moderator

    If you say so..  Doesn't seem like it works great to me.. While mine is working fine your here asking why your firewall rules are not working ;)

    How would your switch ports have the same configs?  The different ports on your switch that have physical machines in the specific vlans would have to be setup.

    Why don't you just put vnics for pfsense in your different vswitches?

    "pinging from a net to another it never leaves router"

    What router?  You have another router on the physical network?

    As to pinging stuff - if your pinging from pfsense, what rule do you think would block.. from firewall to devices on that segment there is no block.. Rules on interfaces are INBOUND rules from that segment too pfsense, not from pfsense to that segment.

    edit:  So I disabled all my rules on the dmz segment (  So pfsense if using that interface as source can still ping stuff in my lan ( since those rules do not apply to pfsense itself.

    But as you see stuff from dmz can not ping stuff in lan, but lan can still ping it because the lan rules do not block it from going to dmz

  • Well i'm sorry tested it now and apperently pfsense is always able to ping itself between interfaces as you stated.

    What i meant with "never leave the router" is that when i ping from interface to interface it never leaves pfsense therefore switching not the issue.

    Regardning the nics. With only 4 nics in the machine i dont want to waste 1 on for example managment which doesnt need much , vmotion is rarley used and when it is it could sure use more than 1, also for storage more then 1 is prefered and also Failsafe for all nets. I dont see why teaming would bother except if it high end gear at full load, Then a separate mgmt and vmotion for example is prefered or even needed.

    The internal traffic was blocked as supposed to except between Public and external hosts..

    I can ping even tho public is blocked meanwhile i cant access anything from Public net as supposed to.. Which was what caught my attention in the first place…

    Edit: i seem to have gotten it all backwards..

    "But as you see stuff from dmz can not ping stuff in lan, but lan can still ping it because the lan rules do not block it from going to dmz"

    But if i setup a block rule in public net any / any it shouldnt be able to respond to a ping since everything going out should be blocked?..

  • Also remember that pf is a stateful firewall.  Existing states will be active regardless of any rule changes.  When doing testing, you may want to reset the states after you make a rule change (Diagnostics - States - Reset States).

  • @Fetakungen:

    But if i setup a block rule in public net any / any it shouldnt be able to respond to a ping since everything going out should be blocked?..

    No, that's not how stateful firewalls work. Replies to permitted traffic aren't evaluated by the ruleset.

Log in to reply