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

Simplied method of preventing inter-VLAN communication

Scheduled Pinned Locked Moved Firewalling
49 Posts 10 Posters 11.0k 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.
  • D
    Derelict LAYER 8 Netgate
    last edited by Nov 18, 2020, 6:58 AM

    For something like passing access from several interfaces to a specific DNS server you can use an interface group.

    Make an interface group containing all of the inside interfaces.

    Create a rule on the interface group that passes TCP/UDP on port 53 to the specific DNS server address or, perhaps, This Firewall (self).

    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
    • S
      Stewart
      last edited by Dec 28, 2020, 3:20 PM

      I wanted to follow up with how I ultimately got my rules working for when someone stumbles on this in the future.

      1. pfBlocker is set to default rule order
      2. Allow IPv4+6 ICMP from VLAN net to VLAN address on any port = Allow Ping on the Interface
      3. Allow IPv4+6 TCP/UDP from VLAN net to VLAN address on port 53 = Allow DNS resolution on interface
      4. Block IPv4+6 * from VLAN net to RC1918 alias on any port = Block Access to other (V)LAN Networks
      5. Allow IPv4+6 * from VLAN net to any on any port = Allow everything else on interface

      This appears to do exactly what I want so I wanted to share what I've got for anyone else to use in the future if it helps.

      D L 2 Replies Last reply Dec 28, 2020, 4:18 PM Reply Quote 1
      • D
        Derelict LAYER 8 Netgate @Stewart
        last edited by Derelict Dec 28, 2020, 4:19 PM Dec 28, 2020, 4:18 PM

        @stewart You might want to change Block to Reject so connections get rejected instead of just hanging until they timeout so users get immediate feedback. That is usually preferable to block for connections originating from the inside.

        You might also consider adding a Reject rule near the RFC1918 rule to destination This firewall (self).

        You are also passing IPv6 but are not blocking anything. You might want to do the same with ULA (fc00::/7) and whatever your local IPv6 addresses are whether GUA or RFC4193 or both or whatever.

        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)

        S 1 Reply Last reply Dec 28, 2020, 4:57 PM Reply Quote 0
        • S
          Stewart @Derelict
          last edited by Dec 28, 2020, 4:57 PM

          @derelict said in Simplied method of preventing inter-VLAN communication:

          @stewart You might want to change Block to Reject so connections get rejected instead of just hanging until they timeout so users get immediate feedback. That is usually preferable to block for connections originating from the inside.

          Yes, I can see how that would be useful. Thanks.

          You might also consider adding a Reject rule near the RFC1918 rule to destination This firewall (self).

          Why do you think I would need that? With the rules as they are they are unable to get to the GUI or establish an SSH connection. Since the IP of the firewall exists inside of the RFC1918 space it gets blocked. Is there something I'm not seeing?

          You are also passing IPv6 but are not blocking anything. You might want to do the same with ULA (fc00::/7) and whatever your local IPv6 addresses are whether GUA or RFC4193 or both or whatever.

          TBH I don't have much experience with IPv6 and normally have it off. I'm just starting to add it in to see how things behave. I'll look into these, thanks.

          D 1 Reply Last reply Dec 28, 2020, 5:03 PM Reply Quote 0
          • D
            Derelict LAYER 8 Netgate @Stewart
            last edited by Dec 28, 2020, 5:03 PM

            @stewart said in Simplied method of preventing inter-VLAN communication:

            Why do you think I would need that? With the rules as they are they are unable to get to the GUI or establish an SSH connection. Since the IP of the firewall exists inside of the RFC1918 space it gets blocked. Is there something I'm not seeing?

            Try connecting to the webgui using your WAN address.

            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)

            S 1 Reply Last reply Dec 28, 2020, 6:54 PM Reply Quote 0
            • S
              Stewart @Derelict
              last edited by Stewart Dec 28, 2020, 6:59 PM Dec 28, 2020, 6:54 PM

              @derelict It just times out.

              Edit: Oh, I see. From inside that VLAN. Yes, it opens up. So that rule stops them from connecting to the WAN from the VLAN. I never thought of that. Thanks for that tip! I've put it in and it's working now. And by working, I mean it doesn't connect. :)

              1 Reply Last reply Reply Quote 0
              • L
                LeeS @Stewart
                last edited by Aug 16, 2022, 8:19 AM

                @stewart said in Simplied method of preventing inter-VLAN communication:

                I wanted to follow up with how I ultimately got my rules working for when someone stumbles on this in the future.

                1. pfBlocker is set to default rule order
                2. Allow IPv4+6 ICMP from VLAN net to VLAN address on any port = Allow Ping on the Interface
                3. Allow IPv4+6 TCP/UDP from VLAN net to VLAN address on port 53 = Allow DNS resolution on interface
                4. Block IPv4+6 * from VLAN net to RC1918 alias on any port = Block Access to other (V)LAN Networks
                5. Allow IPv4+6 * from VLAN net to any on any port = Allow everything else on interface

                This appears to do exactly what I want so I wanted to share what I've got for anyone else to use in the future if it helps.

                Hi @Stewart - I appreciate this post is rather old(ish) now, but I was curious about where you set these rules up. Were they per interface or did you create an Interface group and apply them there?

                S 1 Reply Last reply Aug 17, 2022, 2:11 PM Reply Quote 0
                • S
                  Stewart @LeeS
                  last edited by Aug 17, 2022, 2:11 PM

                  @lees Per interface. I like being able to go to an interface and explicitly see all of the rules that are applied to it so I tend to not use floating rules.

                  1 Reply Last reply Reply Quote 0
                  • C
                    Cloudless Smart Home
                    last edited by Cloudless Smart Home Jan 15, 2023, 11:27 PM Jan 15, 2023, 10:46 PM

                    this post was just what I was looking for, because I was super frustrated with preventing inter-vlan traffic... so just to make sure I understood the thread, my crypto vlan is .100, and when I added the rfc1918 rule, I couldn't get on the internet with my computer on that network, but when I added the allow rule above to 10.0.100.1, I could, so this setup would prevent inter-vlan traffic, but allow internet, correct? if machines on that network never need to communicate with each other, I could also delete the #3 rule of allow all to all too?

                    Screenshot 2023-01-15 at 5.36.13 PM.png

                    is this post correct?

                    https://forum.netgate.com/topic/60549/solved-disable-inter-vlan-traffic

                    if so, does the allow rfc1918 inverted produce the same result as my block rfc1918 and allow all rule after? I'm trying to block inter vlan and allow internet on this vlan.

                    thanks.

                    J S C 3 Replies Last reply Jan 16, 2023, 9:18 AM Reply Quote 0
                    • C
                      Cloudless Smart Home
                      last edited by Jan 15, 2023, 11:25 PM

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • J
                        JeGr LAYER 8 Moderator @Cloudless Smart Home
                        last edited by Jan 16, 2023, 9:18 AM

                        @appleguy said in Simplied method of preventing inter-VLAN communication:

                        if so, does the allow rfc1918 inverted produce the same result as my block rfc1918 and allow all rule after? I'm trying to block inter vlan and allow internet on this vlan.

                        I assume 10.0.100.1 is the IP of pfSense in the crypto subnet? I'd rather not open up the whole IP but only the ports you have to (I further assume, NTP and DNS would be sufficient for that, so UDP 53/123 would be enough as DHCP is automagically opened when used). But if an potential inside attack on the firewall isn't the scope/problem, that's fine.

                        Besides that, blocking RFC1918 (I would recommend REJECT instead of BLOCK as you are coming from inside and most likely want the client to get noticed that he is rejected from doing what it's trying so it can timeout faster) would most likely be enough to separate that VLAN from the rest (if all of them are in the RFC1918 IP space). Allowing "any" afterwards would result in "any IP besides private ones". That could - depending on your general setup and configuration - open up the public IP of pfSense to be accessed from that subnet, so if you want to go for "full isolation" and "complete protection of the firewall box itself", I'd recommend a 4-rule ruleset.

                        1. ALLOW from Crypto_Net to Crypt_Address (avoid IPs in favor of aliases) Protocol IPv4/UDP Ports "Infra" (and create a Port Alias "Infra" for infrastructure ports with 53 and 123 in it for DNS and NTP. If you don't need NTP, you can simply select DNS from the Port dropdown instead)
                        2. REJECT from Crypto_Net to "This Firewall" any any --> reject any requests to the firewall other then DNS/DHCP as it is not to be managed or accessed from this isolated subnet
                        3. REJECT from Crypto_Net to "RFC1918" any any --> like before reject all requests to other private IPs, VLANs, VPNs etc.
                        4. ALLOW from Crypto_Net to any --> allow the rest e.g. the internet in that case.

                        That's it for most use cases.
                        The short form used in the post you linked with "ALLOW not RFC1918" would be sufficient if you aren't going to protect the firewall itself any further. It's a bit more open and if you want to add further blocks it's not very convenient. Most times, people struggle with NOT logic and try to add further rules after that one, what would require AND logic that isn't happening. So not only is the 4-steps above more thorougly secure but also avoids pitfalls due to NOT logic and clearly states what's happening.

                        Also you can further increase security of that VLAN by e.g. adding a few blocklists via pfBlockerNG and add them just before the final 4th rule (insert between 3rd and 4th) to strengthen the security further. That would be hard to do with the 2-rule not-style approach.

                        Cheers

                        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                        1 Reply Last reply Reply Quote 2
                        • S
                          Stewart @Cloudless Smart Home
                          last edited by Jan 17, 2023, 4:33 PM

                          @appleguy So, the RFC1918 rule shouldn't block the internet since all internet IP are route-able and would be outside of the RFC1918 rule. In this instance it looks like the Crypto Subnet is 10.0.100.0/24 and The Crypto Gateway is 10.0.100.1. Your device would presumable have an IP between 10.0.100.2-254. The RFC1918 rule would prevent traffic destined for 10.0.100.1 but should allow any traffic not destined for it to still be route-able.

                          Maybe you are missing some of the other rules? For example, if DHCP gives the router for DNS then you need a rule to allow your subnet to communicate with the gateway on port 53. I don't see that in your list. That's why I explicitly allow ICMP and DNS and then block all RFC1918 and then allow all. That is likely the problem since it was solved by allowing communication to the firewall.

                          You can choose how you want it to work. You can leave it as is and have full access to the firewall from that subnet, that's fine. For our clients, we wouldn't want a subnet like that to have any more access than required so only ICMP (to test that the network is up) and DNS (so devices can resolve to the internet) and allowed. You could circumvent the DNS rule if you use external DNS servers. You could also do away with the ICMP rule if you don't want to be able to ping the router to test connectivity.

                          In addition, as @JeGr and @derelict eluded to, use reject instead of block and also have a rule to reject traffic from the subnet to "This firewall (self)". Those should be added as well.

                          1 Reply Last reply Reply Quote 2
                          • C
                            Cloudless Smart Home
                            last edited by Cloudless Smart Home Jan 19, 2023, 12:57 AM Jan 19, 2023, 12:22 AM

                            still blocking internet access on my home assistant on this IoT vlan. thought I had it sorted out, and haven't made the changes answered above, but am I missing something? my home assistant can download updates or even reboot properly if this rfc1918 block rule is enabled, but it the setup I posted above does seem to work fine for the crypto vlan. it's so weird, because the rfc1918 is the only block rule on the IoT vlan, and I have the allow rule to the appropriate .1 address, same as crypto vlan.

                            Screenshot 2023-01-18 at 7.13.15 PM.png

                            Screenshot 2023-01-18 at 7.15.49 PM.png

                            johnpozJ 1 Reply Last reply Jan 19, 2023, 2:29 AM Reply Quote 0
                            • johnpozJ
                              johnpoz LAYER 8 Global Moderator @Cloudless Smart Home
                              last edited by johnpoz Jan 19, 2023, 2:30 AM Jan 19, 2023, 2:29 AM

                              @appleguy and where are you pointing for dns? If it was say the IP address of pfsense (rfc1918) on your iot network - you blocked it.. So yeah internet stuff not going to work via dns.

                              Here is a what you might use for a typical locked down vlan.

                              rules.jpg

                              This allows talking to pfsense IP on this vlan for dns and ntp, and also allows clients on this network to ping pfsense IP (connectivity testing for example).

                              But blocks all other access to any firewall IP - prevent access to gui on this network, or even say the wan IP (which is commonly public IP)..

                              Blocks access access to any other local network/vlan - and then at the end allows internet.

                              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
                              • C
                                Cloudless Smart Home @Cloudless Smart Home
                                last edited by Cloudless Smart Home Jan 19, 2023, 2:37 AM Jan 19, 2023, 2:36 AM

                                @johnpoz

                                Screenshot 2023-01-15 at 5.36.13 PM.png

                                doesn't my first rule allow dns but just more open than it needs to be?

                                johnpozJ 1 Reply Last reply Jan 19, 2023, 2:48 AM Reply Quote 0
                                • johnpozJ
                                  johnpoz LAYER 8 Global Moderator @Cloudless Smart Home
                                  last edited by Jan 19, 2023, 2:48 AM

                                  @appleguy if that is where your pointing for dns - but that rule shows zero evaluations - see the 0/0 nothing has matched that rule.

                                  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

                                  C 1 Reply Last reply Jan 19, 2023, 2:51 AM Reply Quote 0
                                  • C
                                    Cloudless Smart Home @johnpoz
                                    last edited by Jan 19, 2023, 2:51 AM

                                    @johnpoz
                                    so should I say this firewall everywhere you said test address?

                                    johnpozJ 1 Reply Last reply Jan 19, 2023, 2:55 AM Reply Quote 0
                                    • johnpozJ
                                      johnpoz LAYER 8 Global Moderator @Cloudless Smart Home
                                      last edited by johnpoz Jan 19, 2023, 2:58 AM Jan 19, 2023, 2:55 AM

                                      @appleguy huh.. for your iot vlan you would use your iot network and iot address where my rules have test.

                                      Where exactly is your home assistant pointing to for dns - it doesn't seem to be that 10.0.100.1 address (is this the iot pfsense IP?)

                                      It doesn't seem like anything on iot is trying to talk to that IP - since that rule has never even matched once..

                                      Oh - my bad, I mean your crypto address and network.

                                      home assistant on this IoT vlan

                                      What are the rules on this interface?? If something on your iot vlan is not getting internet - we need to see the rules on that interface.

                                      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

                                      C 1 Reply Last reply Jan 19, 2023, 3:06 AM Reply Quote 0
                                      • C
                                        Cloudless Smart Home @johnpoz
                                        last edited by Cloudless Smart Home Jan 19, 2023, 3:10 AM Jan 19, 2023, 3:06 AM

                                        @johnpoz I think because I took the screen shot before testing it. I am just updating everything like your example and see if that is better, (similar to previous answers) but I do better with pictures for sure 😉

                                        edit: order keeps changing on me because I didn't save the order
                                        Screenshot 2023-01-18 at 10.09.19 PM.png

                                        does that look right?

                                        johnpozJ 2 Replies Last reply Jan 19, 2023, 3:08 AM Reply Quote 0
                                        • johnpozJ
                                          johnpoz LAYER 8 Global Moderator @Cloudless Smart Home
                                          last edited by Jan 19, 2023, 3:08 AM

                                          @appleguy no - rules are evaluated top down, first rule to trigger wins and no other rules are evaluated.

                                          If your dns is say 10.0.100.1 which is rfc1918 your first rule would prevent that access. So no dns.

                                          edit - now that is wrong as well, since your block rules are below where you allow everything. Order matters..

                                          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
                                          • First post
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                            This community forum collects and processes your personal information.
                                            consent.not_received