Hi,
how can I deal with IPv6 addresses in firewall rules?
I have a static v4 WAN address and dynamic IPv6 addresses with a prefix length of 56. I have several VLANs, and I am trying to make firewall rules on one of the VLANs which will:
+ allow all devices on the VLAN to access particular devices on the LAN
+ deny all devices on the VLAN all access to other VLANs
+ allow all devices on the VLAN to have internet access
The devices on the LAN and on the VLAN have known IPv4 addresses and automatically assigned global IPv6 addresses. Since I can not know the IPv6 addresses, I'm finding myself unable to create the firewall rules I need.
That must be a common problem? What's the best way to deal with this?
It is only the higher 56 (or whatever prefix length you get) that are dynamic. You can create "Dynamic IPv6 host" firewall aliases that are automatically assigned with the prefix.
The lower part of the final adress (usually 64 bits) can be predicted either by the device's MAC if SLAAC is used or via static DHCPv6 reservations.
Thus, you can create firewall rules for aliases that reference a specific device's full IPv6 address.
Thank you, it's good to know about this feature!
I'm using DHCPv6, and one of the devices has, for example, obtained a global IPv6 address like "<prefix>:8a06:20b1:cf3e:1602/64". If this device would always get the same suffix, I would be having privacy issues. The only static IPv6 addresses I'm using are for internal purposes only and have the "fd" prefix. At least as long as I don't get global static IPv6 addresses (which I can't and which sucks), all global IPv6 addresses are not constant.
I have been trying to work around this by explicitly blocking access where I want it blocked, but that is a very bad approach because it means that sooner or later, I will forget to block something. I want to have everything blocked and allow only what I want to allow, but the problem is that I must have a rule that allows everything to everywhere so that the devices can have internet access.
I don't understand yet how creating "Dynamic IPv6 Host" firewall aliases can help with this problem. Maybe I need to re-phrase the question:
How can I make it so that all traffic going into a particular interface (VLAN) is blocked except the traffic I explicitly allow, given that the IP addresses the traffic originates from are not constant and that the devices conntected to that interface (devices in that VLAN) need to have internet access?
Why not just block all traffic except what you want to allow? I don't see how IPv6 is any different in that respect or should have a different approach.
My general advice with IPv6 is to not overthink it.
The main problem people frequently face is thinking of privilege per IP address. And that does not easily carry over into the IPv6 world.
I am rather old school in my thinking about firewalls and have used products that support and encourage the use of zones or "burbs" (from suburb) as Sidewinder originally called them. So you say machines in this zone may access these services in that zone. And never use IP addresses anywhere, at least not for outbound connections. When doing reverse NAT to servers in a DMZ or similar, of course you often cannot avoid explicit addresses.
So my general recommendation is to put machines of like privileges all together in a separate VLAN and specify rules per interface which OPNsense easily facilitates. And do not worry about particular addresses too much. Rather assume that IP addresses can and will be forged. Always put untrustworthy devices behind a separate interface.
HTH,
Patrick
Quote from: misja@outlook.com on May 22, 2022, 09:25:41 PM
Why not just block all traffic except what you want to allow? I don't see how IPv6 is any different in that respect or should have a different approach.
My general advice with IPv6 is to not overthink it.
It's what I'm trying to do. How do I do that?
I would need a rule like "block everything but allow everything that needs to be allowed and allow internet" --- "internet" meaning everything on the other side of the WAN interface(s). There are devices with global IPv6 addresses on this side of the WAN interface, and these addresses keep changing.
How do I make such a rule?
Don't use the (changing) address in the rule. Just state which applications (protocols, ports) are to be allowed and set the address to "any".
If you have different policies for particular devices, put all devices that share a common policy behind one interface for that group.
If you don't have enough interfaces, use a VLAN capable switch and VLANs.
HTH,
Patrick
Quote from: pmhausen on May 22, 2022, 09:54:29 PM
The main problem people frequently face is thinking of privilege per IP address. And that does not easily carry over into the IPv6 world.
I am rather old school in my thinking about firewalls and have used products that support and encourage the use of zones or "burbs" (from suburb) as Sidewinder originally called them. So you say machines in this zone may access these services in that zone. And never use IP addresses anywhere, at least not for outbound connections. When doing reverse NAT to servers in a DMZ or similar, of course you often cannot avoid explicit addresses.
So my general recommendation is to put machines of like privileges all together in a separate VLAN and specify rules per interface which OPNsense easily facilitates. And do not worry about particular addresses too much. Rather assume that IP addresses can and will be forged. Always put untrustworthy devices behind a separate interface.
HTH,
Patrick
IIUC, you suggest to create some kind of replacement for a zone-based firewall. That works fine with IPv4 --- letting aside how little actual IP addresses are being used in zone-based firewalls --- because the distinction between "internet" and "not internet" remains clear. That is so because what's "not internet" has IP addresses in the private address ranges.
That doesn't work with IPv6 because devices are meant to have global addresses (besides link-local addresses and addresses in private address ranges). So technically, there is no distinction between "internet" and "not internet".
But in practise, I still do have that distinction because the devices on my side of the WAN interface are "not internet" regardless of their addresses, and everything on the other side of the WAN interface is "internet", regardless of the addresses.
The problem is that I don't see a way to deal with the practical distinction in the firewall because there aren't any reasonable means to do that. Or what is the solution and the means?
Using VLANs to create a distinction doesn't work, or does it? My server is already on a different VLAN than the guest-like VLAN. I still need to somehow block access from the guest-like VLAN to my server and allow only what I want to allow while I have to allow everything from the guest-like VLAN to anywhere so devices on that VLAN have internet access. I can create blocking rules on the guest-like VLAN, and I can't very well create them on the VLAN the server is on because OPNsense fancies blocking in ingress and not on egress.
That leaves the problem that I may forget to block something, and that is what I want to overcome. I shouldn't be required to block stuff; I should be able to have everything blocked by default so I can only allow what I want to allow.
Quote from: pmhausen on May 22, 2022, 10:55:56 PM
Don't use the (changing) address in the rule. Just state which applications (protocols, ports) are to be allowed and set the address to "any".
If you have different policies for particular devices, put all devices that share a common policy behind one interface for that group.
If you don't have enough interfaces, use a VLAN capable switch and VLANs.
HTH,
Patrick
But I don't want devices on the guest-like VLAN to be able access ports on all the devices on the LAN VLAN (where my server is). And I still need the anything to anywhere rule for allowing internet access for devices on the guest-like VLAN, and that means I can't just allow only what I want to allow. I first have to allow what I want to allow, then block everything I don't want to allow and then, as the last rule, I have to allow everything for allowing internet access.
It's doable, but it's a bad setup and too much prone to errors because it's too easy to forget to block something.
For outgoing IPv6 access, you can usually allow any -> any, so the only question is incoming IPv6 traffic.
You do not have to allow access from a "limited" VLAN to your LAN, but that is not any different from IPv4.
For incoming access, you block everything and only explicitely allow specific device via firewall aliases like I described. There is no such thing as a privacy issue here, because the key point in allowing access to a specific device is "specific" - you have to "name" it somehow:
First off, that is something completely decoupled of if that same device has another IPv6 address which it uses to access the internet from inside out - you can well use IPv6 privacy extensions for that indepedently of how it is being access from outside. Effectively, you will have to use a dynamic DNS service of one kind or the other (otherwise you cannot know the current IPv6 prefix and thus not the full IPv6 of the device in question).
Having cleared that out of the way, the only question could be if you can guess anything from the lower 64 bits of the IPv6. The answer is yes, if you use SLAAC, because the contained MAC gives away the manufacturer of the device. But as I said, you could as well use DHCPv6 with artifical addresses.
Everything you do not explicitly allow is blocked in OPNsense. But now I better understand your problem. Yes, there is no "destination interface" in pf rules. Which would be necessary to have a true zone based firewall.
But while the general advice is to filter on ingress, I think in any multi-tenant or similar scenario filtering on egress can be helpful.
So you have one or multiple separate server networks (zones) and a LAN for general use and a general "permit all" rule for the LAN. Do I get that correct?
You could use an outbound rule in the "server" interface like "deny from LAN net". That should work even with a changing "LAN net". I do not have a ready-made config yet, but I am actively exploring this route, because I did replace a zone based firewall with OPNsense and in one situation I have multiple hosting tenants that should all be able to reach "the Internet", but only reach other tenants at the same services those want accessable publicly. I think that's very similar to your requirements. And I think outbound rules might be the way to go in that case.
HTH,
Patrick
Quote from: meyergru on May 22, 2022, 11:22:36 PM
For outgoing IPv6 access, you can usually allow any -> any, so the only question is incoming IPv6 traffic.
When I do that, the devices on the guest-like VLAN will be able to reach the devices on the LAN VLAN without restriction. That entirely defeats the idea of allowing only what I want to allow.
Quote
You do not have to allow access from a "limited" VLAN to your LAN, but that is not any different from IPv4.
Then how, for example, are devices on the guest-like VLAN supposed to reach my SIP server or my DNS server?
Quote
For incoming access, you block everything and only explicitely allow specific device via firewall aliases like I described. There is no such thing as a privacy issue here, because the key point in allowing access to a specific device is "specific" - you have to "name" it somehow:
Somehow naming means that I do have a privacy issue. With IPv4 and NAT, it's not visible what's going on on my LAN. I could have 2 devices on it or 200 or 1000 or whatever. With IPv6, I do have a privacy issue once I "name" a particular device somehow beause it suddenly becomes visible how many devices (IPv6 addresses) I have and what they might be doing (like sending DNS requests and/or contacting a VOIP provider ...). I don't know that there would be a solution for that.
Quote
First off, that is something completely decoupled of if that same device has another IPv6 address which it uses to access the internet from inside out - you can well use IPv6 privacy extensions for that indepedently of how it is being access from outside. Effectively, you will have to use a dynamic DNS service of one kind or the other (otherwise you cannot know the current IPv6 prefix and thus not the full IPv6 of the device in question).
Currently, I do not need to reach devices on my network from the outside via IPv6. If I had to, I would need to get a IPv6 network assigned. I have used dynamic DNS in the past and it sucks. (I don't understand why I can't get an IPv6 network assigned. The ISPs keep complaining about not having enough IPv4 addresses but I got a static IPv4 address and at the same time, they deny you the IPv6 addresses which we are supposed to have instead since IPv6 is supposed to succeed IPV4. That doesn't make any sense. And without at least a static IPv4 address or an IPv6 net, internet is pretty much useless to me. Dynamic DNS doesn't cut it.)
Quote
Having cleared that out of the way, the only question could be if you can guess anything from the lower 64 bits of the IPv6. The answer is yes, if you use SLAAC, because the contained MAC gives away the manufacturer of the device. But as I said, you could as well use DHCPv6 with artifical addresses.
It is easier to give permanent IPv6 addresses to the devices that need them which are in the private address range. That's how my name server has fd53::11, for example, and that doesn't create privacy issues.
Quote from: pmhausen on May 22, 2022, 11:27:41 PM
Everything you do not explicitly allow is blocked in OPNsense. But now I better understand your problem. Yes, there is no "destination interface" in pf rules. Which would be necessary to have a true zone based firewall.
But while the general advice is to filter on ingress, I think in any multi-tenant or similar scenario filtering on egress can be helpful.
So you have one or multiple separate server networks (zones) and a LAN for general use and a general "permit all" rule for the LAN. Do I get that correct?
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.
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.
To work around this, everthing that shouldn't be allowed needs to be explicitly blocked, and that sucks because you have to create so many blocking rules and because you can easily forget to block something.
Quote
You could use an outbound rule in the "server" interface like "deny from LAN net". That should work even with a changing "LAN net". I do not have a ready-made config yet, but I am actively exploring this route, because I did replace a zone based firewall with OPNsense and in one situation I have multiple hosting tenants that should all be able to reach "the Internet", but only reach other tenants at the same services those want accessable publicly. I think that's very similar to your requirements. And I think outbound rules might be the way to go in that case.
HTH,
Patrick
I'm not sure what you mean. The firewall on the server itself blocks everything that isn't allowed. That doesn't have anything to do with devices on the guest VLAN being able to reach the server (which is on the LAN) or not. (It doesn't matter where the server is as long as it is not on the guest VLAN. The firewall on the server doesn't block NFS, for example, and devices on the guest VLAN must not be able to reach the NFS ports but need to be blocked before they can.)
As to a rule blocking something outbound (instead of the usual inbound) on the opensense firewall, that rule would have to be on the guest VLAN. It would have to be a rule that blocks everthing outbound to the LAN except what I want to allow to reach the server. Or not?
It would be better because the default would be "block all and allow" instead of "allow and and block". But with a bunch of VLANs, that would still require such rules for all VLANs. And that only because of the "allow everything to anywhere" which is needed for internet access.
Is there really no better way? That "allow everthing to anywhere" rule is what's causing the problems, and it's like putting the cart before the horse. We shouldn't have to go to lengths and have to create a bunch of blocking or allowing rules at other places just because we need a rule like that.
Try something like this.
Quote from: defaultuserfoo on May 23, 2022, 12:26:02 AM
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 ...
Quote from: defaultuserfoo on May 23, 2022, 12:26:02 AM
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 - there simply is no way in PF to specify "from this interface in only to that interface (WAN) out".
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.
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
I did configure something like that using interface groups. It's not great but it works.
Quote from: avanix on May 23, 2022, 07:40:17 AM
Try something like this.
Like when you put together a steering wheel, the wheels go underneath?
Quote from: defaultuserfoo on May 23, 2022, 11:47:54 AM
Quote from: avanix on May 23, 2022, 07:40:17 AM
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.
Quote from: bimbar on May 23, 2022, 11:13:51 AM
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?
Quote from: pmhausen on May 23, 2022, 09:53:23 AM
Quote from: defaultuserfoo on May 23, 2022, 12:26:02 AM
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.
Quote from: defaultuserfoo on May 23, 2022, 12:26:02 AM
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.
Quote
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.
Quote
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?
Quote
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.
Quote
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 :)
Quote from: pmhausen on May 23, 2022, 12:01:22 PM
Quote from: defaultuserfoo on May 23, 2022, 11:47:54 AM
Quote from: avanix on May 23, 2022, 07:40:17 AM
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?
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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. ;)
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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.
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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.
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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
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.
Quote from: pmhausen on May 23, 2022, 12:02:24 PM
Quote from: bimbar on May 23, 2022, 11:13:51 AM
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.
Quote from: pmhausen on May 23, 2022, 01:35:37 PM
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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 :)
Quote
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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
Quote
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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.
Quote from: defaultuserfoo on May 23, 2022, 01:07:49 PM
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? :)
Quote from: 5SpeedFun on May 24, 2022, 01:28:06 AM
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?
Quote from: defaultuserfoo on May 24, 2022, 12:33:31 PM
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.
Quote from: defaultuserfoo on May 24, 2022, 12:24:40 PM
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?
Quote from: bimbar on May 24, 2022, 12:06:12 PM
Quote from: pmhausen on May 23, 2022, 12:02:24 PM
Quote from: bimbar on May 23, 2022, 11:13:51 AM
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.
Quote from: pmhausen on May 24, 2022, 12:41:26 PM
Quote from: defaultuserfoo on May 24, 2022, 12:33:31 PM
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 ...
Quote from: pmhausen on May 24, 2022, 01:33:01 PM
And that's it, in my opinion. What do you think?
I think that's awesome and you're a genious :)
Does it even require the rule to deny everything from Customer net to Customer net? It says everything not explicitly passed is being blocked ...
(I made a test group earlier and then worried I might get locked out, but fortunately, I wasn't ...)
Quote from: defaultuserfoo on May 24, 2022, 02:09:41 PM
Does it even require the rule to deny everything from Customer net to Customer net? It says everything not explicitly passed is being blocked ...
IMHO yes, because we want to keep the allow all to any rules for the individual interfaces. And block only
inter-VLAN-traffic.
So the block rule is supposed to match that first. And then when the traffic is from local net X to anything else ("the Internet"), the interface rule matches.
If we leave the group ruleset empty, the firewall will just fall through to the interface rules and end up with "permit".
Ah, yes, of course, you're right :)
Quote from: defaultuserfoo on May 23, 2022, 01:11:39 PM
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?
My screenshot was not a joke.
The idea was to have several VLANs and put the devices that shoud be seperated in these VLANs. E.g. my office PC and the NAS are in one VLAN, the smartphones, Apple TV and stuff like this in an other VLAN. Each VLAN has the blocking rules to block access to every other VLANs and in the end an allow all rule for Internet Acces. When I need a communication between the VLANs I add a allow rule in front like in the Screenshot for the Remote Desktop Port.
Maybe there are simpler solutions, but this one worked for me and separates devices like me office PC from the smartphones and the NAS...
The idea should also work for IPv6 because for the sole separation between the VLANs no direct IPv6 based rule is needed. And for devices without internet access the allow all rule on the end can be removed for a VLAN without Internet.
Ah, now I see! It's basically what I did, only you have a lot more VLANs, and you always explicitly use VLAN30 as source in all the rules (Where else could the packets come from?).
The solution Patrick (pmhausen) came up with that uses an interface group might save you all these rules. I'll try that in a couple days.
The group interface doesn't seem to work right, see https://forum.opnsense.org/index.php?topic=28543.0