Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

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

    Firewalling
    6
    14
    1775
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      Fetakungen last edited by

      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 ?

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned last edited by

        Need to show the rules.

        1 Reply Last reply Reply Quote 0
        • johnpoz
          johnpoz LAYER 8 Global Moderator last edited by

          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

          1 Reply Last reply Reply Quote 0
          • F
            Fetakungen last edited by

            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…

            1 Reply Last reply Reply Quote 0
            • KOM
              KOM last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • F
                Fetakungen last edited by

                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..

                1 Reply Last reply Reply Quote 0
                • KOM
                  KOM last edited by

                  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?

                  1 Reply Last reply Reply Quote 0
                  • johnpoz
                    johnpoz LAYER 8 Global Moderator last edited by

                    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.


                    1 Reply Last reply Reply Quote 0
                    • H
                      Harvy66 last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • F
                        Fetakungen last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • johnpoz
                          johnpoz LAYER 8 Global Moderator last edited by

                          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 (192.168.3.0/24)..  So pfsense if using that interface as source can still ping stuff in my lan (192.168.1.0/24) 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






                          1 Reply Last reply Reply Quote 0
                          • F
                            Fetakungen last edited by

                            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 193.10.29.36 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?..

                            1 Reply Last reply Reply Quote 0
                            • KOM
                              KOM last edited by

                              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).

                              1 Reply Last reply Reply Quote 0
                              • C
                                cmb last edited by

                                @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.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post

                                Products

                                • Platform Overview
                                • TNSR
                                • pfSense
                                • Appliances

                                Services

                                • Training
                                • Professional Services

                                Support

                                • Subscription Plans
                                • Contact Support
                                • Product Lifecycle
                                • Documentation

                                News

                                • Media Coverage
                                • Press
                                • Events

                                Resources

                                • Blog
                                • FAQ
                                • Find a Partner
                                • Resource Library
                                • Security Information

                                Company

                                • About Us
                                • Careers
                                • Partners
                                • Contact Us
                                • Legal
                                Our Mission

                                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                Subscribe to our Newsletter

                                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                © 2021 Rubicon Communications, LLC | Privacy Policy