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

    Possible issue with inter-VLAN firewall rules

    Scheduled Pinned Locked Moved
    2.1 Snapshot Feedback and Problems - RETIRED
    3
    10
    3.2k
    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.
    • T
      timthetortoise
      last edited by

      I'm having an issue with disallowing routing between VLANs in the latest snapshot. Previously, everything between VLANs was locked down if not explicitly allowed, but now traffic is flowing whether or not I tell it not to. Here are my current rules. Production is on VLAN 1, Guest is on VLAN 2.

      I've tried a multitude of different combinations and have had absolutely no luck locking it down. Not sure if this is a bug or a misconfiguration on my part. Here is my output from pfctl -sr.

      scrub on rl0 all fragment reassemble
scrub on em0 all fragment reassemble
scrub on em0_vlan2 all fragment reassemble
anchor "relayd/*" all
anchor "openvpn/*" all
anchor "ipsec/*" all
block drop in inet all label "Default deny rule IPv4"
block drop out inet all label "Default deny rule IPv4"
block drop in inet6 all label "Default deny rule IPv6"
block drop out inet6 all label "Default deny rule IPv6"
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echorep keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echorep keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state
pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state
block drop quick inet proto tcp from any port = 0 to any
block drop quick inet proto tcp from any to any port = 0
block drop quick inet proto udp from any port = 0 to any
block drop quick inet proto udp from any to any port = 0
block drop quick inet6 proto tcp from any port = 0 to any
block drop quick inet6 proto tcp from any to any port = 0
block drop quick inet6 proto udp from any port = 0 to any
block drop quick inet6 proto udp from any to any port = 0
block drop quick from <snort2c> to any label "Block snort2c hosts"
block drop quick from any to <snort2c> label "Block snort2c hosts"
block drop in log quick proto tcp from <sshlockout> to any port = ssh label "sshlockout"
block drop in log quick proto tcp from <webconfiguratorlockout> to any port = http label "webConfiguratorlockout"
block drop in quick from <virusprot> to any label "virusprot overload table"
block drop in quick on rl0 from <bogons> to any label "block bogon IPv4 networks from WAN"
block drop in quick on rl0 from <bogonsv6> to any label "block bogon IPv6 networks from WAN"
block drop in on ! rl0 inet from z.z.z.z/30 to any
block drop in inet from z.z.z.z to any
block drop in on rl0 inet6 from fe80::20a:cdff:fe1a:90a7 to any
block drop in quick on rl0 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8"
block drop in quick on rl0 inet from 127.0.0.0/8 to any label "Block private networks from WAN block 127/8"
block drop in quick on rl0 inet from 100.64.0.0/10 to any label "Block private networks from WAN block 100.64/10"
block drop in quick on rl0 inet from 172.16.0.0/12 to any label "Block private networks from WAN block 172.16/12"
block drop in quick on rl0 inet from 192.168.0.0/16 to any label "Block private networks from WAN block 192.168/16"
block drop in quick on rl0 inet6 from fc00::/7 to any label "Block ULA networks from WAN block fc00::/7"
pass in quick on rl0 inet6 proto udp from fe80::/10 port = dhcpv6-client to fe80::/10 port = dhcpv6-client keep state label "allow dhcpv6 client in WAN"
pass in quick on rl0 proto udp from any port = dhcpv6-server to any port = dhcpv6-client keep state label "allow dhcpv6 client in WAN"
pass out quick on rl0 proto udp from any port = dhcpv6-client to any port = dhcpv6-server keep state label "allow dhcpv6 client out WAN"
block drop in on ! em0 inet from x.x.x.x/21 to any
block drop in inet from x.x.x.x to any
block drop in on ! em0_vlan2 inet from y.y.y.y/23 to any
block drop in inet from y.y.y.y to any
block drop in on em0 inet6 from fe80::1:1 to any
block drop in on em0_vlan2 inet6 from fe80::221:86ff:fe27:e70 to any
pass in quick on em0_vlan2 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on em0_vlan2 inet proto udp from any port = bootpc to y.y.y.y port = bootps keep state label "allow access to DHCP server"
pass out quick on em0_vlan2 inet proto udp from y.y.y.y port = bootps to any port = bootpc keep state label "allow access to DHCP server"
pass in on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass out on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass in on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
pass out on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
pass out route-to (rl0 z.z.z.z) inet from z.z.z.z to ! z.z.z.z/30 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass out route-to (em0 w.x.y.z) inet from x.x.x.x to ! x.x.x.x/21 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
anchor "userrules/*" all
pass in quick on openvpn all flags S/SA keep state label "USER_RULE: OpenVPN IT VPN wizard"
pass in quick on rl0 reply-to (rl0 z.z.z.z) inet from y.y.y.y/23 to any flags S/SA keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
pass in quick on rl0 reply-to (rl0 z.z.z.z) inet proto udp from any to z.z.z.z port = 1194 keep state label "USER_RULE: OpenVPN IT VPN wizard"
pass in quick on rl0 reply-to (rl0 z.z.z.z) inet proto tcp from any to 127.0.0.1 port = ssh flags S/SA keep state label "USER_RULE: NAT SSH Alternate Port"
pass in quick on rl0 reply-to (rl0 z.z.z.z) inet from a.a.a.a to any flags S/SA keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
block drop in log quick on em0 reply-to (em0 w.x.y.z) inet from any to ! x.x.x.x label "USER_RULE: Block Guest to Production"
pass in quick on em0 reply-to (em0 w.x.y.z) inet proto tcp from <productionvlan> to x.x.x.x port = http flags S/SA keep state label "USER_RULE: Web Access"
pass in quick on em0 reply-to (em0 w.x.y.z) inet proto tcp from <productionvlan> to x.x.x.x port = ssh flags S/SA keep state label "USER_RULE: SSH Access"
pass in quick on em0 reply-to (em0 w.x.y.z) inet proto tcp from <productionvlan> to x.x.x.x port = mdqs flags S/SA keep state label "USER_RULE: Darkstats"
block drop in quick on em0_vlan2 inet proto tcp from any to y.y.y.y label "USER_RULE"
pass in quick on em0_vlan2 inet from any to ! <productionvlan> flags S/SA keep state label "USER_RULE"
anchor "tftp-proxy/*" all
pass in quick on em0_vlan2 proto tcp from any to ! (em0_vlan2) port = http flags S/SA keep state
pass in quick on em0_vlan2 proto tcp from any to ! (em0_vlan2) port = 3128 flags S/SA keep state</productionvlan></productionvlan></productionvlan></productionvlan></bogonsv6></bogons></virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c>
      1 Reply Last reply Reply Quote 0
      • M
        mikeisfly
        last edited by

        When you set up the rules they are applied in the outbound direction on your private Interfaces correct and in the inbound direction on the public interfaces? If this is the case then you have your rules reversed. You should :

        LAN Interface
        1. Block (source * destination guest network)
        2. Allow any any

        Guest Interface

        1. Block (source any destination production)
        2. Allow any any

        Please forgive the pseudo cisco syntax but I think my point is made. You probably only need a block rule on the guest network because if production net sends a packet to the guest net, the guest net will not send it back due to the block rule. I always like to use the least amount of acl as possible.
        Hope this helps

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

          What are you trying to accomplish? What do you want it to do and what is it actually doing. The rules you're showing are all correctly reflected in the ruleset.

          1 Reply Last reply Reply Quote 0
          • T
            timthetortoise
            last edited by

            Right now I am testing pfSense as a replacement for Smoothwall, so for that I've got it running my company's guest network. The guest network is configured on VLAN 2, and what is essentially the management interface internally is VLAN 1. em0 untagged traffic is going to, say, 10.100.0.1, and em0 VLAN 2 traffic is going to 192.168.123.1. I am essentially attempting to not let the 10.100.0.0 and 192.168.123.0 networks communicate. I thought that this was the default behavior of the firewall - implicit denial. If I remove all firewall rules, I can ping into 10.100.0.0 from 192.168.123.0 and vice versa. Should this not be blocked?

            @mikeisfly:

            When you set up the rules they are applied in the outbound direction on your private Interfaces correct and in the inbound direction on the public interfaces? If this is the case then you have your rules reversed. You should :

            LAN Interface
            1. Block (source * destination guest network)
            2. Allow any any

            Guest Interface

            1. Block (source any destination production)
            2. Allow any any

            Please forgive the pseudo cisco syntax but I think my point is made. You probably only need a block rule on the guest network because if production net sends a packet to the guest net, the guest net will not send it back due to the block rule. I always like to use the least amount of acl as possible.
            Hope this helps

            I think you may have missed the exclamation point, for some reason it's doing line breaks now. My rule for the LAN set is:
            1. Block (source any destination !10.100.0.1)
            2. Allow (source 10.100.0.0 destination 10.100.0.1 tcp 80)
            Etc…

            For the Guest set:
            1. Block (source any destination 192.168.123.1 tcp) <- successfully blocks HTTP access from guest network
            2. Allow (source any destination !10.100.0.0)

            At that point both should hit an implicit deny, and the packets should be dropped. However, that's not what's happening. I have full access to both networks from both sides.

            In 2.0.2 I was doing something similar (but with no explicit network denies), and it was working as expected - nothing got across unless I explicitly allowed it.

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

              Can you PM or email (cmb at pfsense dot org) me a full, non-anonymized copy of your /tmp/rules.debug file?

              1 Reply Last reply Reply Quote 0
              • T
                timthetortoise
                last edited by

                Sent

                1 Reply Last reply Reply Quote 0
                • T
                  timthetortoise
                  last edited by

                  It appears this has been fixed in the latest, thank you!

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

                    Nothing has changed at all that would impact this. Probably you had established connections from before changing the rules and didn't kill the states.

                    1 Reply Last reply Reply Quote 0
                    • T
                      timthetortoise
                      last edited by

                      The issue was persisting after reboots and manual state resets, both from command line and from the GUI. I'll confirm if it's fixed on Monday when I can test from work, but so far from ping/port tests, it looks like it's behaving correctly now. I haven't made any huge changes to rules.

                      1 Reply Last reply Reply Quote 0
                      • T
                        timthetortoise
                        last edited by

                        Nevermind, still happening.

                        Edit: and with the new latest, maybe not. Time for more testing.

                        Edit2: looks to be completely fixed, I'm now seeing blocks in my logs as they should be, and can't pass data where I shouldn't be able to. I can't seem to find a relevant commit so maybe it's magic, but it seems to be working properly now either way.

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