Simplied method of preventing inter-VLAN communication
-
@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.
- 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)
- 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
- REJECT from Crypto_Net to "RFC1918" any any --> like before reject all requests to other private IPs, VLANs, VPNs etc.
- 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
-
@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.
-
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.
-
@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.
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.
-
-
@appleguy if that is where your pointing for dns - but that rule shows zero evaluations - see the 0/0 nothing has matched that rule.
-
@johnpoz
so should I say this firewall everywhere you said test address? -
@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.
-
@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
does that look right?
-
@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..
-
@appleguy yeah this better.. But not sure why your using "this firewall" for dns - while that can work.. Are you devices going to use every possible pfsense IP, or just the IP on that interface?
Normally you would only allow this network to talk to the IP of pfsense on that network for dns and ntp, ping, etc.
-
@johnpoz oh no, so change this firewall back to 10.0.100.1 on the first 3 rules? I think I need to allow for DHCP on the router too?
-
@appleguy depends on what you want.. But your first rules should allow for dns and anything else you want to be allowed to the IP of pfsense on this interface. If you don't care about pinging pfsense, or ntp or even dns then that is not needed.
But normally clients only "need" to talk to 1 IP of pfsense, normally the IP of pfsense on that interface - "this firewall" is all IPs of pfsense, other vlans/networks - the wan IP, etc.
Its odd your not showing any hits on those rules 0/0 if you were actually using a Pfsense IP for dns - those should show some hits. Mine are all 0/0 on my test interface. Because I only use that interface for showing rules, etc. I don't really have a test network ;)
-
@johnpoz here is an actual network of mine with devices on it.
Notice my rule for dns is any for destination - I don't care where they talk for dns, which could be pfsense IP on this guest network or it might be 8.8.8.8 for example..
But see the order, I allow stuff I want that could be rfc1918 before I block rfc1918. In this case the "this firewall" rule is preventing access to say pfsense wan IP for the gui port or ssh, etc.
Just remember top down, first rule to trigger wins. Walk down your rules on what you want to allow, what you want to block, walking through the rules to see which rule would trigger..
In the case of these rules - I could prob just use wan address vs "this firewall" since what worried about is guest accessing say the public IP of pfsense for gui or ssh, all other IPs of pfsense are rfc1918.
-
@johnpoz ok, loosened some back up a little. don't see any default rules for DHCP in protocols so DHCP should still work? I do DNS and DHCP from pfsense.
-
@appleguy dhcp is a hidden rule when you enable dhcp on an interface.
-
@appleguy said in Simplied method of preventing inter-VLAN communication:
@johnpoz ok, loosened some back up a little. don't see any default rules for DHCP in protocols so DHCP should still work? I do DNS and DHCP from pfsense.
@appleguy First three rules just need "CRYPTO addr" not "*" - no need for any in that case, as you'd normally only want them to reach pfSense for DNS and NTP or PING and leave anything other closed.
-
@jegr thanks again for all your help! finally got it right! wait, not *? does not mean inverted?
-
@johnpoz Is there a way to see the hidden rules? I've never really considered that there would be Firewall rules set up on an interface that we didn't know about. I've wondered from time to time how DHCP works even though traffic is denied.
-
@appleguy This is how I have all my ports/VLANs set up by default. Similar to yours but I specify the destination and use external NTP.
It's interesting to go back and see. Nothing's pinging the firewall or using DNS on this VLAN. That's OK. Nothing trying to get into the firewall. Also good. But something is trying to access other local IPs outside of the subnet? What're those cameras up to, I wonder? Glad I've got that block!
