Best topology for my network
-
@tknospdr It would not match traffic coming from the interface and destined to the firewall or other networks.
-
Okay, here's where I get confused then, because to me saying:
If source is ETH3, but destination is NOT ETH3, drop the packets
Like the bottom rule hereSeems like the most efficient way to express a rule where you want all outbound (from the subnet) packets dropped unless they match an incoming state.
What's the flaw in my thinking?
And seriously, I'm not being argumentative, this is just the best way for me to learn. -
@tknospdr It is a subtle difference but it's possible to have a network behind ETH3 that is routed through ETH3 but is a different subnet. It's not a common setup though so if you're not routing internal traffic then there's not really a difference.
Your example is only blocking "ETH3 Net" but the default block rule would block it.
Your example is also invalid btw...which interface is this ruleset on? If it is on ETH3, the destination can never be ETH3. If it is not on ETH3, then the source for the last rule can never be ETH3 Net.
-
@tknospdr said in Best topology for my network:
What's the flaw in my thinking?
And seriously, I'm not being argumentative, this is just the best way for me to learn.
If you say that, then you're. As SteveTS said, you cannot have source and the destination the same...that's not how network works.
Would you go to the airport, say JFK (source or origination) to catch a flight going to JFK destination? You won't find any airline. Or, if you say I want to drop flights going to destination JFK, if the source or origination is JFK...you wouldn't find any flights to drop because no airline flies that route either.Makes sense?
-
@SteveITS said in Best topology for my network:
@tknospdr It is a subtle difference but it's possible to have a network behind ETH3 that is routed through ETH3 but is a different subnet. It's not a common setup though so if you're not routing internal traffic then there's not really a difference.
Are you talking about a VLAN, or something else. Because I do have 2 VLANs traversing ETH3. If those don't count I don't want to learn any other stuff I don't have to deal with right now.
My ears are already smoking with this learning module.Your example is only blocking "ETH3 Net" but the default block rule would block it.
The default block rules that I keep seeing mentioned are implied right? I don't actually see anything in any of the FW rule lists so it's just "zero rules = block everything" right?
Your example is also invalid btw...which interface is this ruleset on?
The ruleset is on ETH3
If it is on ETH3, the destination can never be ETH3.
I don't understand this. You can't make a rule on a subnet regarding traffic on itself?
If it is not on ETH3, then the source for the last rule can never be ETH3 Net.
Similar question... You can't make a rule saying for incoming packets on adapter ETH2, if the source is ETH3 do X?
-
@NollipfSense said in Best topology for my network:
Makes sense?
What you're saying makes sense, but I didn't think that's what I was saying.
I thought the rule I created said:
If I go to JFK, show me a list of flights that !JFK (are not destined for JFK), then ground them so they can't leave the airport. Effectively grounding ALL flights out of JFK.
It seems like I'm misunderstanding the usage of 'Invert match', so what would I use that for?
I thought it meant "everything that is not X", but clearly that's faulty thinking. -
@tknospdr said in Best topology for my network:
If I go to JFK, show me a list of flights that !JFK (are not destined for JFK), then ground them so they can't leave the airport. Effectively grounding ALL flights out of JFK.
But, the thing is there is no such list and will never be such list; so, there will be no flights to ground ever. These two threads should help you understand "invert match:" https://forum.netgate.com/topic/100836/firewall-invert-match-question - https://www.reddit.com/r/PFSENSE/comments/lyxkoj/invert_match/
-
The list IS the rule.
Sorry for being so dense, but those threads basically say the same thing I'm saying.
If the source of the packet is ETH3 net, and it's destination is NOT ETH3 net, block it.
I'm sure there's an "Ah ha!" moment ahead, I just haven't reached that nirvana yet.
There's some crazy subtle difference I'm not picking up on. -
@tknospdr said in Best topology for my network:
You can't make a rule on a subnet regarding traffic on itself?
Packets from ETH3-PC1 to ETH-PC2 should not go to the router, they go across the switch, from one port to another.
Though is is interesting your top two rules show matching traffic which makes me wonder what's going on...
typically a packet arriving from ETH3 at the router would be going anywhere else except ETH3.
-
My pfS box has 4 un-switched 2.5GbE ports on it.
ETH0 is WAN, ETH1 is LAN, I'm not currently using ETH2, and ETH3 goes to my WAP which hosts 3 different subnets.
10.100.10.0 is my IOT/HomeKit stuff
10.100.20.0 is on VLAN20 for wifi computers
10.100.30.0 is on VLAN30 for Nintendo Switches and other older wifi stuff that can't do RADIUS authIf you click the link in the 4th post you can see a crude drawing of my network (I added the 3rd wifi network since my masterpiece)
-
@tknospdr said in Best topology for my network:
I don't understand this. You can't make a rule on a subnet regarding traffic on itself?
You can make the rule - but what would trigger it? As stated, traffic that is to something else on the same network never would go to pfsense.
Traffic is only sent to the router/gateway (pfsense) when the destination is not the local network.
The use of ! rules, while might be useful in some special use case. Are not normally needed, and are harder for humans to read. If you want a rule that allows something on eth3 to go anywhere it wants, then the clearer destination is ANY.. not ! Eth3 Net..
Also your more likely to run into some weirdness when doing such a rule - there have been issues in the past when VIPs are involved for example. Its best to be very explicit in your rules, allow/deny/reject with very specific and easy for human to understand at a glance.
If you want to do allow source eth3 net, destination !Eth3 Net. sure go ahead.. But since no traffic would be sent to pfsense anyway if the destination was eth3 net what is the point. You would also by that rule be blocking access to pfsense IPs on eth3 net.. Which you prob using for dns, ntp, or wanting to ping for connectivity check, etc.
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.7.2, 24.11 -
Okay, so there is an unwritten but implied 'deny all' rule on every subnet by default, right?
If all I want to do is contain all packets generated on the network connected to ETH3 to that network, I would start with ZERO rules in place?
VLANs traveling over ETH3 are distinct and their traffic should not affect or be affected by ETH3s FW entries, right? Seems self evident by them having their own entries on the FW page, but I'm not assuming anything at this point.
Now, if I want devices on other networks to be able to talk with the devices on ETH3 I'd just create explicit ALLOW rules on ETH3 to let them in?
I need to learn more about the traffic that HomeKit uses to communicate with it's home hubs so that I can create the correct rules to allow only that traffic.
Are there any HomeKit recipes out there already? No, I have not googled it yet. I wanted to get this straight in my head first. -
@johnpoz said in Best topology for my network:
If you want to do allow source eth3 net, destination !Eth3 Net. sure go ahead.. But since no traffic would be sent to pfsense anyway if the destination was eth3 net what is the point. You would also by that rule be blocking access to pfsense IPs on eth3 net.. Which you prob using for dns, ntp, or wanting to ping for connectivity check, etc.
Would the firewall address not be in the same eth3 subnet? Now I am confused too lol.
-
Yeah that was my point.. He would be blocking them if used a ! eth3 net rule, unless he had rules above at to allow what he wanted to allow first.
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.7.2, 24.11 -
@tknospdr said in Best topology for my network:
Now, if I want devices on other networks to be able to talk with the devices on ETH3 I'd just create explicit ALLOW rules on ETH3 to let them in?
No.. Those rules would be put on the source interfaces.
Rules are evaluated top down, first rule to trigger wins no other rules are evaluated. On the interface where it would first enter pfsense,.
If you have something on LAN wanting to go to eth3 network - that traffic would enter pfsense on the LAN interface, so that is where you would place the rule to either allow or deny it.
-
@tknospdr said in Best topology for my network:
there is an unwritten but implied 'deny all' rule on every subnet by default, right
yes
@tknospdr said in Best topology for my network:
If all I want to do is contain all packets generated on the network connected to ETH3 to that network, I would start with ZERO rules in place
sure
@tknospdr said in Best topology for my network:
VLANs traveling over ETH3 are distinct and their traffic should not affect or be affected by ETH3s FW entries, right
right, VLANs have their own interface in pfSense.
@tknospdr said in Best topology for my network:
if I want devices on other networks to be able to talk with the devices on ETH3 I'd just create explicit ALLOW rules on ETH3 to let them in?
no, you would create a rule on LAN, from source LAN Net to dest ETH3 Net.
@Austin-0 said in Best topology for my network:
Would the firewall address not be in the same eth3 subnet
That one is but the pfSense LAN IP and WAN IP are not. (there is a This Firewall choice when creating a rule, for all of them)
-
@johnpoz Okay I just misunderstood what you were saying. Thought I was going crazy there for a second.
-
Okay, another point or two for my own clarity.
If I want AAA to talk to BBB, the firewall rule would be:
On adapter AAA allow traffic from AAA to destination BBB. Yes?
The firewall is then smart enough to do that, I don't ALSO need a rule on adapter BBB to allow the incoming traffic, right?
Also, so far every rule I've seen written have the adapter and the source be the same. Is that always the case or is there a rule where the adapter is different from the network?
-
@tknospdr said in Best topology for my network:
On adapter AAA allow traffic from AAA to destination BBB. Yes?
If the adapter is an Interface, Yes
@tknospdr said in Best topology for my network:
The firewall is then smart enough to do that, I don't ALSO need a rule on adapter BBB to allow the incoming traffic, right?
Yes, you don't need, no.
@tknospdr said in Best topology for my network:
Also, so far every rule I've seen written have the adapter and the source be the same. Is that always the case or is there a rule where the adapter is different from the network?
Not sure what you're speaking of...
-
@tknospdr said in Best topology for my network:
If I want AAA to talk to BBB, the firewall rule would be:
On adapter AAA allow traffic from AAA to destination BBB. Yes?
Yes
The firewall is then smart enough to do that, I don't ALSO need a rule on adapter BBB to allow the incoming traffic, right?
Correct, rules are applied as the packet enters an interface not when it leaves. (Aside from floating which behave differently, ignore those while you get started)
Also, so far every rule I've seen written have the adapter and the source be the same. Is that always the case or is there a rule where the adapter is different from the network?
Well see my post above https://forum.netgate.com/topic/181507/best-topology-for-my-network/16. It’s rare but possible to route a network behind pfSense LAN, without using NAT. As you get familiar just assume they are the same.
-
S SteveITS referenced this topic on
