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

    FW-rules related to an specific "IPV6-device"

    Scheduled Pinned Locked Moved Firewalling
    25 Posts 5 Posters 2.8k Views
    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.
    • L
      louis2
      last edited by louis2

      A few additional remarks

      Devices in my secure/greenzone regularly need to update. So that should be allowed, but suppose there is a malware on that device, that malware will try to reach its boss …… no way the door is blocked 😊

      Filtering based on mac more or less against the FW-concept, but it would be very practical.

      Example:

      • only server having mac-x is allowed to go outside
      • only server having mac-y can be reached from outside

      Related to incoming filtering, assigning a fixed IP via IPV6 is possible via DUID, just not so comfortable, tja and only relevant for incoming (I think). Same for NIC based fixed IP’s even less handy.

      Louis

      JKnottJ 1 Reply Last reply Reply Quote 0
      • JKnottJ
        JKnott @louis2
        last edited by

        @louis2 said in FW-rules related to an specific "IPV6-device":

        only server having mac-y can be reached from outside

        How do you reach a MAC address from outside? The MAC address is completely irrelevant outside the local network.

        Devices in my secure/greenzone regularly need to update. So that should be allowed, but suppose there is a malware on that device, that malware will try to reach its boss …… no way the door is blocked

        How would MAC filtering block malware, but not updates?

        Also, you can disable privacy addresses, which leaves only the consistent address. Some devices don't even use privacy addresses at all.

        Some firewalls do support MAC filtering. I used to use Linux for my firewall and it supported MAC filtering. However, the FreeBSD firewall, which pfSense runs on, doesn't. So, it's a FreeBSD issue, not pfSense.

        BTW, this reminds me of a presentation someone gave at a Linux user group about a Linux firewall. That person thought MAC filtering could be used to filter incoming traffic, not understanding that the only MAC address it would see was that of the ISPs router.

        PfSense running on Qotom mini PC
        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
        UniFi AC-Lite access point

        I haven't lost my mind. It's around here...somewhere...

        1 Reply Last reply Reply Quote 0
        • L
          louis2
          last edited by

          Of course you cannot access a mac from outside

          however I was referring to internal FW-rules example

          • a firewall rule like traffic towards mac-x is allowed or not allowed.
          • Or outgoing traffic form mac-y is allowed or not allowed
            Are options with a firewall supporting mac-filtering

          And of course you cannot reach all goals with that but take following examples:

          • rule one allow to go to windows update
          • rule two block all traffic starting at mac-z
            => result only windows update is accesable

          I do same kind of things now based on IP

          • block in vlan(=interface)-x everything towards my servers
          • allow access to every other address
            => result my own network is protected, the rest is allowed

          Louis

          1 Reply Last reply Reply Quote 0
          • Bob.DigB
            Bob.Dig LAYER 8
            last edited by

            Not possible ATM.

            1 Reply Last reply Reply Quote 0
            • L
              louis2
              last edited by

              Nonsense, you did not understood what I try to archive,

              I am talking about filtering between (v)lan's in my own network. And the mac in my examples do refer to the mac-addresses of my own local devices.

              By the way that, mac filtering is just a hypothetic solution for outgoing filtering as an alternative for the "uncontolable IPV6-address" ☺

              Louis

              Bob.DigB 1 Reply Last reply Reply Quote 0
              • Bob.DigB
                Bob.Dig LAYER 8 @louis2
                last edited by

                @louis2 Have you read this thread?

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

                  Mac addresses are only seen on layer 2, if your taking from 1 vlan to another vlan - the mac client will know about for talking to another IP off its vlan is the mac address of its gateway/router to get to off their vlan..

                  If you don't want vlan X talking to vlan Y, then you would put a rule on vlan X blocking access to vlan Y. macs not involved.

                  Still trying to understand exactly what your trying to accomplish. I too have my vlans isolated - mac address don't come into play at all. The only time they can come into play is if you want to make sure device A always gets IP address A.. If so you can do this with a dhcp reservation so its mac always gets IP A..

                  You can go a bit farther with static mac address where pfsense will only talk to IP X, when its mac is xyz..

                  a firewall rule like traffic towards mac-x is allowed or not allowed.
                  Or outgoing traffic form mac-y is allowed or not allowed

                  Not possible. Other than making sure mac address X always has IP address X. And then filtering on that IP.

                  You can do some stuff that is mac address based using the captive portal.

                  To control of IPv6 yes this brings some added complexity to the mix.. Especially with the use of random IPs a client might use for privacy.. This is why you filter at the network/vlan/prefix so say ALL devices on that vlan blocked or allowed to talk to another network.. Again macs do not come into play. But with IPv6 you can assign specific IPs to a client with dhcpv6 based on their duid.

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                  1 Reply Last reply Reply Quote 0
                  • L
                    louis2
                    last edited by

                    I suggest to locally filtering on mac, because it is opposite to the IPV6-adress it is a stable item.

                    And yep in the present pfSense FW macs are not involved in filter rules. However that does not mean it is not possible.

                    "only issue" is that you are combining level2 and level3 filtering.
                    in the referenced example

                    • a firewall rule like traffic towards mac-x is allowed or not allowed.
                    • Or outgoing traffic form mac-y is allowed or not allowed

                    The FW is doing level2 filtering in opposite to the normal IP-filtering. There are firewalls who are capable of doing that, mainly triggered by the IPV6-drama I think.

                    Problem is that I do not see a proper solution on IP-level !

                    Bob, I scanned the thread refered to, and I think it is dealing with the same kind of issues. I have to read it more carefull, but not sure there is a good solution in that thread (must read it more precise later)

                    Louis

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      I suggest placing your devices into security zones based on interface/VLAN, not by individual addresses. Change what the all the hosts in that zone can do, not what the individual hosts can do.

                      Even in IPv4 using just the address for security purposes is folly.

                      IP addresses can be changed.

                      MAC addresses can be spoofed.

                      Unless you implement something like port security at layer 2. Have fun with your Wi-Fi there.

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 1
                      • L
                        louis2
                        last edited by louis2

                        Derelict,

                        I completely agree that IP addresses can be changed and MAC addresses can be spoofed and that is certainly a risk! But manly against advanced attacks.

                        And I just would like to add to that, that you never should only rely on the setting of elements in your network for security. Or on patch levels etc.

                        However, it also depends on against which kind of threats you want to protect. In my case one of the main concerns are commercial / privacy related "attacks".

                        And yep WIFI is not perfect not for security and not for connection quallity as well. I only use it for mobile devices (and did configurate it as private vlan, and I do have a separate guest wifi lan).

                        Hope that take some of your worries away. And yep nothing is perfect.

                        Louis

                        JKnottJ 1 Reply Last reply Reply Quote 0
                        • JKnottJ
                          JKnott @louis2
                          last edited by

                          @louis2 said in FW-rules related to an specific "IPV6-device":

                          But manly against advanced attacks.

                          From where? Unless those attacks are coming from your LAN, MAC filtering is useless. And if you know that MAC of the offending device, then you know what device must be removed from your network and fixed.

                          PfSense running on Qotom mini PC
                          i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                          UniFi AC-Lite access point

                          I haven't lost my mind. It's around here...somewhere...

                          1 Reply Last reply Reply Quote 0
                          • L
                            louis2
                            last edited by

                            Sorry,

                            I must not have been clearly enough,

                            • that kind of advanced attacks are not my main concern!
                              (I do agree with Derelic, but not so much given my main concern)
                            • however in case some mallware did arrive on one of my servers, blocking traffic to "not allowed destinations" does help a bit, assuming the IP or MAC are not (temporarely) spoofed.
                            • And it will also raise logging messages which hopefully would trigger me

                            Louis

                            1 Reply Last reply Reply Quote 0
                            • DerelictD
                              Derelict LAYER 8 Netgate
                              last edited by

                              @louis2 said in FW-rules related to an specific "IPV6-device":

                              however in case some mallware did arrive on one of my servers

                              Right. A server should be in a DMZ and it should always only be allowed to approved destinations.

                              Exactly the type of network segmentation I was talking about.

                              No matter what you do on the firewall, if all of your hosts are on one segment there is nothing you can do in the firewall to stop them from infecting other nodes on that segment.

                              Chattanooga, Tennessee, USA
                              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                              Do Not Chat For Help! NO_WAN_EGRESS(TM)

                              1 Reply Last reply Reply Quote 0
                              • L
                                louis2
                                last edited by louis2

                                Derelict,

                                That brings me to another item.

                                Suppose you are working in the Netgate development office having sensitive information. And of course there are other Netgate offices in the same building.

                                Now you have to protect your data and there are two options:

                                • you lock the door of your department or
                                • you go to the other offices and tell them that they should not enter your door (and you trust them)

                                Which option would you choose .... I assume the first one, every office should is responsible for its own front door.

                                However, ...... pfSense does not offer that concept ..... it only offers method 2

                                Suppose your office is having subnet/interface-A
                                And another office is having subnet/interface-B

                                Then the rules related to Interface-B can block access to your front door using outgoing rules ...
                                However you can not protect your own front door since there is no incoming filtering.

                                This is not 100% true, because there is something like floating rules, but .... nevertheless ..... I do not like the concept!

                                Louis

                                1 Reply Last reply Reply Quote 0
                                • DerelictD
                                  Derelict LAYER 8 Netgate
                                  last edited by Derelict

                                  I do not understand your analogy.

                                  A firewall has nothing to do with what passes between members of the same network segment.

                                  If you do not like how pfSense (pf) processes traffic, yes, you can use floating rules in the outbound direction.

                                  If that is insufficient, then pfSense is probably not the solution for you because that is how pf works. A common firewall best practice is to block the traffic as it enters the firewall, not as it exits. This is a firewall, not an office building.

                                  You could also do something like a default deny for an inside IP address or network with a floating rule on all interfaces in any direction to a specific inside destination with quick not set. You could subsequently pass any desired traffic to that destination from certain zones. All other traffic to that destination will be denied.

                                  But that will only work if the traffic passes through the firewall in the first place, which will not happen if the traffic is coming from something on the same network segment.

                                  Chattanooga, Tennessee, USA
                                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                  L 1 Reply Last reply Reply Quote 0
                                  • L
                                    louis2
                                    last edited by louis2

                                    Derelict,

                                    I had exactly the same firewall rules in mind you describe! It is not perfect, but it is helps!

                                    something like:

                                    • normal rules per interface, describing what is allowed inside

                                    floating rules

                                    • block IPV4 traffic towards 192.168.0.0/16
                                    • allow IPV4 (the rest)
                                    • block IPV6-myrange
                                    • allow IPV6 (the rest)

                                    Related to the last sentence, the traffic is never comming from the same network segment, since I devided the network in segments like "PC-LAN", "GUEST-LAN", IoT-LAN, RedZone, GreenZone, Mngt.

                                    Each segment is an vlan with its own interface. In case that servers on the same vlan / segment are not allowed to reach each other, you could use level2 private VLAN's. I only do that for my WIFI.

                                    Louis

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

                                      @louis2 said in FW-rules related to an specific "IPV6-device":

                                      block IPV4 traffic towards 192.168.0.0/16

                                      If you have a firewall that prevents access from B from going to A, there is really no point in creating a rule in the outbound direction on interface A (into A).. It will never be triggered.. And just causing you more work for no benefit..

                                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                                      If you get confused: Listen to the Music Play
                                      Please don't Chat/PM me for help, unless mod related
                                      SG-4860 24.11 | Lab VMs 2.8, 24.11

                                      L 1 Reply Last reply Reply Quote 0
                                      • L
                                        louis2
                                        last edited by

                                        John, Derelict,

                                        Yep If you do it the way you desctibe yes, you are right, however ....

                                        As described above,

                                        • at the gateway of "other" VLAN's you should define rules, related to what is allowed to leave the vlan
                                        • at the gateway of the VLAN "to protect" you should describe what is allowed to enter the VLAN

                                        That is more secure and .... it even cost less rules, because if you have to add a rule at the GW of each other VLAN that it is not allowed to go to the protected VLAN:

                                        • it will cost you n-rules
                                        • you can forget to add a rule at one of the vlans
                                        • and perhaps each vlan is managed by/under responsibility its own department manager, which does not match

                                        So what I did is the following

                                        Assume we have only three VLAN's

                                        • PCLAN which should be capable to access the NAS in the GreenZone
                                        • We have the GreenZone which should only be accessable from the PCLAN
                                        • We have the Redzone which should under no circumstances be allowed to reach the NAS / GreenZone

                                        So now what I did

                                        • PCLAN
                                          Rule-1: PASS destination GreenZone

                                        • Floating Rules
                                          Rule-1: BLOCK, Interface "GreenZone", Direction out, Address IPV4+IPV6, TCP+UDP
                                          Rule-2: PASS, QUICK, Interface "GreenZone", Direction out, Address IPV4+IPV6 ,TCP+UDP, Source PCLAN

                                        • RedZone (or any other (V)LAN
                                          Nothing OR
                                          Rule-1: Pass Destination GreenZone OR
                                          Rule-1: BLOCK Destination GreenZone OR

                                        So with the rules given under PCLAN I give permission to go to the NAS
                                        With Floating Rule-1, I block traffic out of any (V)LAN,
                                        With Floating Rule-2 I make an exception for the PCLAN

                                        The rules related to any other interface e.g. Redzone do not matter. What ever is there, systems in that vlan will never have access to my NAS

                                        That is how I do it at the moment. The only point is, that the Floating rules having an InterFace set, should be at the interface tab and not on the Floating tab. (and it would be handy if the rule direction would be presented in the GUI.

                                        Can you support me?

                                        Louis

                                        1 Reply Last reply Reply Quote 0
                                        • L
                                          louis2 @Bob.Dig
                                          last edited by

                                          @Bob-Dig

                                          Inline with my owh perception ant the more after this thread and also the thread you where refering to (How to create IPv6 firewall rules?), I am more that ever convinced that it is simply impossible to create device specific IPV6-rules based on IP-address.

                                          So IMHO no other option than mac-filtering (I know not supported in pfSense).

                                          Louis

                                          1 Reply Last reply Reply Quote 0
                                          • L
                                            louis2 @Derelict
                                            last edited by

                                            @Derelict

                                            In line with my original perception and the more after reading the responses in this thread
                                            and also reading the thread “How to create IPv6 firewall rules?”,

                                            I am more than ever convinced that it is simply impossible to create device specific IPV6-rules based on IPV6-address.

                                            The only option I see is using the device its mac-address. Its level-2 I know.

                                            I also know mac and IP van both be spoofed, but never the less, having the option to “allow” or “block” a specific device is very wroth full having.

                                            Also note that it is not a good idea to force a specific IPV6 address in a / all specific computers, if even possible(!). And apart form that the changing addresses are helping privacy a bit.

                                            So my conclusion can not be different than that we have to push in the direction of mac based rules!!

                                            Louis

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.