Best practise for limiting inter LAN routing

[pwnell]

I currently have this kind of configuration on all LANs (this one maps to LAN2 in my example):

LAN2

Proto: IPv4+6
Src: LAN2 net
Port: *
Dest: LAN1 net
Port: *
GW: *
Action: Block

Proto: IPv4+6
Src: LAN2 net
Port: *
Dest: LAN3 net
Port: *
GW: *
Action: Block

Proto: IPv4+6
Src: LAN2 net
Port: *
Dest: *
Port: *
GW: *
Action: Allow

I guess this is the wrong way round? By default no LAN can access any other LAN correct? Should I rather add an ALLOW on say LAN2 for src LAN1 and dest * (to allow LAN1 to access LAN2) and so on?

[johnpoz]

Its much easier if you just post a picture..

What are you rules above.. When you create another OPT network (lan2) for example - no rules will be on it.. So it wouldn't even be able to ask pfsense for dns, etc..

Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.

Lan1 would NEVER be a source into Lan2..

[KOM]

Yes, please post actual screenshots of your LAN1, LAN2, LAN3 rules. You can post images here directly via the Upload Image icon in the Edit toolbar.

[pwnell]

I am confused. I understood from @KOM that I did not need outbound rules, hence the proposal of allowing src2 LAN1 on LAN2 and dest * but @johnpoz you say that will not work? What I am not understanding here? If LAN1 sends a packet destined for LAN2, what would be the source on the LAN2 interface if not LAN1?

I had to anonymize it a bit but here you go. In this case my setup is:

• LAN1, LAN2 and LAN3 can access internet
• LAN1 can access LAN2, LAN3
• LAN2 cannot access LAN1 or LAN3
• LAN3 cannot access LAN2 or LAN1
• A specific group if clients (Alias WaldoDevicesLAN3) on LAN3 can access LAN1

How would this be better configured?

[KOM]

You're misunderstanding how to visualize the interfaces. Firewall rules only apply to traffic that enters an interface, which is considered inbound from the perspective of the interface. So when a LAN client sends a packet out of its local network, the pfSense LAN interface receives the packet and applies the rule to it. Once it passes the rule, it can go where its supposed to. Rules work on inbound traffic only (with some exceptions). pfSense LAN interface receives inbound traffic from LAN client. Rules process it. If allowed, the packet goes out the WAN to the Internet. Reply comes back inbound to WAN, stateful firewall automatically allows reply traffic, and the packet is forwarded out the LAN interface to the LAN client.

In your rules, your labels are wrong. All rules on every interface are considered inbound rules so you may as well either get rid of the banners or rename them to something that describes their function.

Also, unless you're actively using IPv6, I would disable it and avoid the extra rules.

Now for particulars...

In your LAN1 rules, that first rule for NTP is useless since the two rules below allow all traffic to pass anyway. Delete it.

For LAN2, again delete that first rule as it's unnecessary. Edit the last rule to change the protocol from TCP/UDP to Any.

For LAN3, again delete that NTP rule.

[pwnell]

Thanks for the response. I do understand the basics that the firewall acts on inbound traffic and understand the orientation of the interfaces - i.e. that the terminology in/out is from the perspective of the firewall.

The NTP rule is indeed unnecessary but it is a relic from other changes I made a while ago - not really important for this discussion.

So what should the label read? I have it "Catch all block LAN3 to LAN1" for instance on LAN3. Is "Block traffic destined for LAN1" better?

Is the basic approach of having a catch all whitelist rule at the bottom (for internet access) and blocking those destined for LANs not allowed before them correct though?

[Derelict]

@pwnell said in Best practise for limiting inter LAN routing:

Is the basic approach of having a catch all whitelist rule at the bottom (for internet access) and blocking those destined for LANs not allowed before them correct though?

Yes.

Do yourself a favor and change them to reject rules though to clients trying to connect get immediate feedback instead of just hanging and timing out.

[pwnell]

One last question on this topic - how best to deal with scaling. If I have say 10 LAN interfaces, LAN1.. LAN10, and say LAN1 can have access to LAN2..LAN10, but LAN2..LAN10 cannot access each other or LAN1, there will be 10 rules per interface (one allow for internet, 9 reject for the other LAN interfaces) meaning there will be 100 rules in total across the 10 interfaces.

Would this better be implemented with floating rules? If so, how would that rule(s) look like?

[KOM]

While you might be able to cobble something together with floating rules, I find that rules on each interface are much easier to read and understand. While it's more work, it's easier to get it right.

[Derelict]

In many cases you can just make an alias for RFC1918 addresses or all local subnets and block all traffic to that.

You'll have to pass traffic to things like local DNS servers.

As long as you pass anything on the firewall that they need to access first there is no harm in having a rule that blocks connections to the interface subnet because the firewall won't see that traffic anyway.

That said, maintaining a firewall with a lot of interfaces is sometimes work to get set up.

[pwnell]

Thanks for all the advice, much appreciated.