how to deal with IPv6?

[bimbar]

I did configure something like that using interface groups. It's not great but it works.

[defaultuserfoo]

Try something like this.

Like when you put together a steering wheel, the wheels go underneath?

[Patrick M. Hausen]

Try something like this.

Like when you put together a steering wheel, the wheels go underneath?

That's why I think outbound rules could simplify that a lot. Which remains to be proven, of course. I'll update this thread when I have something actually working.

[Patrick M. Hausen]

I did configure something like that using interface groups. It's not great but it works.

Could you post an example, please? Is there something like an "<interface group> net" object, which would sum up all the directly connected networks?

[defaultuserfoo]

Not excatly ... For simplicity, let's assume that I have a LAN and a guest VLAN.  With IPv4, the common way to set it up is to block everything to all private networks and then allow everyhing to anywhere so that devices on the guest VLAN have internet access.  That nicely protects your LAN because all devices on the LAN have IP addresses within the private networks which can not be reached from the devices on the guest VLAN.

This is a gross oversimplification, IMHO, because e.g. I run several setups where the "internal" networks do not use private but globally routable addresses. Yes, for IPv4 ...

Ok, well, I can be glad when I can get one global IPv4 address.  So things are simple for me, I guess.

With IPv6, that doesn't work because suddenly, all the devices on the LAN have not only addresses within private networks but also have public IP addresses; and your LAN is unprotected because the rule on the guest VLAN that allows everything to everywhere also allows access to the devices on your LAN and you can't reasonably block that, especially not when the IP addresses of the devices on the LAN keep chaning all the time.

But I do understand your problem. If you allow "everything" that implies the guest network can reach all other directly connected networks as well as "the Internet".

I am not arguing that your requirement is not justified -

The argument of being justified or not is an interesting point.  You can always argue that my server (i. e. particularly mine, to keep things simple) has a global IPv6 address and is "reachable" from the internet, so it doesn't or shouldn't matter whether it can be reached from the guest VLAN or not.  The justification I have comes in (at least) where my server is also a file server (and other things) on the LAN.  Same as I do not want my server to be reached from the internet for incoming connections (other than what I explicitly allow), I do not want want it reachable from the guest VLAN (other than what I explicitly allow).  And I certainly don't want to leave things to chance, like the chance that someone on the guest VLAN somehow figures out what IP addresses my server has and starts attacking it, as unlikely as it may be.  Now I have a firewall that prevents my server from being reached from the internet for incoming connections.  I don't like the idea of creating rules in that firewall that allow my server to be reached for incoming connections from other networks, like the guest VLAN, not any more than I like the idea of my server being reachable from the internet.

So how is my argument not justified?  What's your argument on this?  Maybe I don't need to do what I'm trying to do.

there simply is no way in PF to specify "from this interface in only to that interface (WAN) out".

Ok, so what I might want isn't possible.  Wouldn't it be a nice feature to have?

So let's turn back to your simplified example: I was suggesting that you create an outbound rule on the LAN interface that reads "block everything from guest network".

You can create group of all directly connected networks and place a "block everything from <group> outbound" on all of the networks, because there will never be traffic coming out of interface X with source address of net X. Unless it's generated by the firewall itself, but that is taken care of by the default "permit everything from the firewall itself" rule.

So the additional burden for blocking is reduced to 1 rule per interface and maintaining a group of all networks attached to all the interfaces. Not optimal but the best I could think of. I am going to test this in the coming weeks and if successful put it in production. Currently I have block rules with various destination networks spread "everywhere" and I am just as annoyed by that as you are, that's why I am also looking for a solution.

At least I'm not the only one having this problem.  Somehow this was never an issue with the firewalls I'm about to replace with OPNsense (most of which are zone-based).  I think it's because they have no IPv6 yet and I simply blocked the private networks before allowing internet and I didn't need to think about it.

There will probably be things to consider with respect to rule order and the application of "quick", that's why I don't have an example ready for you.

HTH,
Patrick

No problem ... I still don't understand how a rule on the LAN interface that blocks outbound traffic from the guest network could accomplish anything.  Why and how would there be traffic from the guest netwok outbound on the LAN interface?  Let me see if I can still find the picture someone made ...  There ... It's for Ubiquity EdgeRouters, but that doesn't matter.  It makes more clear what "inbound" and "outbound" means and when the rules apply (when you look at the interfaces in the picture in the upper part).

This picture is priceless for EdgeRouters because those have interface properties (for a lack of a better word) that can contain a specification of which set of firewall rules are to apply to which direction of traffic.  Thus you can name a set of frewall rules like "LAN_IN", and in the interface properties you say like "firewall in LAN_IN'.  That's why it says 'firewall local', 'firewall in' and 'firewall out' in the picture; 'local' means the router itself, 'in' means coming into the interface and 'out' means before stuff goes out of the interface.  (For the record, I got that picture in 2016 from the forum Ubiquity has.  I don't know if it's still there after they changed their forum.)

If OPNsense works basically the same (is there a picture like this for OPNsense?), maybe I can now understand what you're saying:  An outbound rule on the LAN interface that blocks everything from <group> /would block traffic coming out of the firewall before the traffic could enter the LAN interface and go out of the LAN interface/.

So does OPNsense work like this?  Do I need to look at the weird "floating rules" for this?  I haven't looked into those yet ...  This will be interesting :)

[defaultuserfoo]

Try something like this.

Like when you put together a steering wheel, the wheels go underneath?

That's why I think outbound rules could simplify that a lot. Which remains to be proven, of course. I'll update this thread when I have something actually working.

Oh.  I thought your screenshot was a joke.  Why do you need so many of the same blocking rules?  Aren't these rules blocking stuff?  Are those outbound or floating rules?

[Patrick M. Hausen]

So how is my argument not justified?  What's your argument on this?  Maybe I don't need to do what I'm trying to do.

I said that your argument is justified - read the sentence again.  ;)

Ok, so what I might want isn't possible.  Wouldn't it be a nice feature to have?

Ironically ipfw, the "native" FreeBSD firewall has got a "via <interface>" clause for ingress and egress. But as far as I know nobody has written a polished firewall appliance product on top of it.

No problem ... I still don't understand how a rule on the LAN interface that blocks outbound traffic from the guest network could accomplish anything.  Why and how would there be traffic from the guest netwok outbound on the LAN interface?

Well, a machine on the guest network sends a packet to a machine on the LAN network. That packet goes in to the firewall on the guest interface and out of the firewall on the LAN interface ...

The "inbound/outbound" distinction is strictly from the firewall's point of view.

An outbound rule on the LAN interface that blocks everything from <group> /would block traffic coming out of the firewall before the traffic could enter the LAN interface and go out of the LAN interface/.

Exactly.


HTH,
Patrick

[5SpeedFun]

Op>
Have you tried making rules based on "Nets" ? Under the Source/dest in the rule you create, there should be some built in aliases  named "<interface name> net".  That should at least cover all devices onthat interface, even if the interface subnet changes.

[bimbar]

I did configure something like that using interface groups. It's not great but it works.

Could you post an example, please? Is there something like an "<interface group> net" object, which would sum up all the directly connected networks?

IIRC when you define an interface group, a net object like that is created and you can work with "deny from any to interface group", "allow from interface group to any" or something similar.
I don't have that setup active anymore so I can not look it up.

[defaultuserfoo]

So how is my argument not justified?  What's your argument on this?  Maybe I don't need to do what I'm trying to do.

I said that your argument is justified - read the sentence again.  ;)

It can be read one way or another: that you're not arguing doesn't mean it's justified :)

Ok, so what I might want isn't possible.  Wouldn't it be a nice feature to have?

Ironically ipfw, the "native" FreeBSD firewall has got a "via <interface>" clause for ingress and egress. But as far as I know nobody has written a polished firewall appliance product on top of it.

It would be nice to make use of that in OPNsense.  Actually I really like zone-based firewalls for they bring more clarity through structure.  The rule based ones like OPNsense has kinda remind me of helicopter parents messing up their kids with their way of the rules hovering about the interfaces.  With the "allow anything to anywhere" rules we can't get around, OPNsense kinda blows itself up every time we add another interface and more hovering is required to keep the kids in line.  That doesn't happen with zone-based firewalls since every kid has no other option than to obey the rules because no loopholes are created and the structures can't be overthrown, by adding interfaces or otherwise.

OPNsense is a helicopter firewall ;P

No problem ... I still don't understand how a rule on the LAN interface that blocks outbound traffic from the guest network could accomplish anything.  Why and how would there be traffic from the guest netwok outbound on the LAN interface?

Well, a machine on the guest network sends a packet to a machine on the LAN network. That packet goes in to the firewall on the guest interface and out of the firewall on the LAN interface ...

The "inbound/outbound" distinction is strictly from the firewall's point of view.

An outbound rule on the LAN interface that blocks everything from <group> /would block traffic coming out of the firewall before the traffic could enter the LAN interface and go out of the LAN interface/.

Exactly.

Good to know :)  There's some confirmation in the help text when creating a rule; it says: "[Source] -> IN -> [Firewall] -> OUT -> [Destination]".

I've given it some thought and tidied up my rules and gave it some more thought.  There's a problem with out-rules in that I would need to create outgoing allow-rules and block-rules on every interface which are specific to that interface.  The result would be that the rules concering one interface would be all over the place, and that would go for every interface and then lots of rules would be over all the interfaces and all the interfaces would have a mixture of rules some of which directly concern it and others of which indirectly concern it.  It would be a total mess and become very difficult to figure out what's going on.

With the way it is now, at least I can see all the rules concerning a particular interface by looking at that interface.  Maybe I could invert everything by using only out-rules instead of only in-rules (I haven't needed out-rules yet).  But then, I'd need an out-rule allowing everything from anywhere for internet and then it all becomes much worse ...

Are you sure you still want to make an example? :)

[defaultuserfoo]

Op>
Have you tried making rules based on "Nets" ? Under the Source/dest in the rule you create, there should be some built in aliases  named "<interface name> net".  That should at least cover all devices onthat interface, even if the interface subnet changes.

Yes, thanks, I'm currently using that for blocking-rules.

If I could create an alias containing all the '<interface name> net' aliases, maybe I could make a rule that allows everthing to anywhere that doesn't go to that alias?  But I can't seem to make such an alias.

But there is an alias 'WAN net'.  What does that mean?  Internet?

[Patrick M. Hausen]

But there is an alias 'WAN net'.  What does that mean?  Internet?

Nope. That's a common misunderstanding.

"X net" is the network directly connected to interface X. Regardless of which interface, so also for WAN. Some ISP might give you a routed /29 or /30 istead of a point to point link, so that's what "WAN net" ends up being.

[Patrick M. Hausen]

Are you sure you still want to make an example? :)

Yes - but we do not need outbound rules for that  ;)

@bimbar enlightened me ... I did not consider interface groups. The idea behind my "outbound" approach was to create another layer of rule hierarchy besides "floating" and "interface". Well, there is one, already - interface groups.

And i think we can keep inbound rules for everything.

Look at the processing order:
https://docs.opnsense.org/manual/firewall.html#processing-order

Now - this is all from my mind to keyboard to forum, completely untested, but I think it'll work with some fine tuning - imagine a hosting or similar situation. We have

- WAN
- Net 1
- Net 2
- ...
- Net n

All these networks shall be able to talk to the Internet but not to each other apart from explicit exceptions. And we cannot simply block RFC 1918, because we are dealing with IPv6 or routable IPv4 ...

1. Put all the customer interfaces into an interface group, name it "Customers".
2. An automatic object named "Customers net" is created (this I did check - OPNsense does this).
3. Put a rule on the "Customers" group: from "Customers net" to "Customers net" deny all.

Now the networks are isolated. Any time you add an interface you just place it into the interface group and you are done.

4. On each individual interface place the from "Net-X net" to "any" allow all rule.

All the networks can reach the Internet but are still prevented from talking each other, because the interface group rules take precedence over the interface rules.

Now the only open requirement for outbound traffic is that the machines in the "Net N" networks need to talk to the firewall e.g. on port 53 for DNS. I will have to check in real life what is the most elegant way to achieve this. You could put it in floating rules (highest priority) or in interface group "Customers" before the block rule.

And for inbound, you simply manage everything via floating rules (highest priority). If customer X wants to have their webserver accessible on ports 80 and 443 in most cases that means "the Internet" but all other customers are part of "the Internet", too. So floating, no interface specification, from "any", to "web server X address" ports "80, 443" allow.

You need to manage your ingress somewhere. IMHO floating is just as good as WAN for that.

And that's it, in my opinion. What do you think?

[defaultuserfoo]

I did configure something like that using interface groups. It's not great but it works.

Could you post an example, please? Is there something like an "<interface group> net" object, which would sum up all the directly connected networks?

IIRC when you define an interface group, a net object like that is created and you can work with "deny from any to interface group", "allow from interface group to any" or something similar.
I don't have that setup active anymore so I can not look it up.

Thank you!  I think it could at least replace several blocking rules on the guest interface, and I could use pretty names for the groups like 'ig_protect_from_guest' ... And as a plus, the interface group can have its own set of rules.

That will require some thinking and some testing.  It'll be a couple days before I can get to that.

[defaultuserfoo]

But there is an alias 'WAN net'.  What does that mean?  Internet?

Nope. That's a common misunderstanding.

"X net" is the network directly connected to interface X. Regardless of which interface, so also for WAN. Some ISP might give you a routed /29 or /30 istead of a point to point link, so that's what "WAN net" ends up being.

Thank you for clarifing :)  It's what I thought ...