Messages

166

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 24, 2022, 07:02:55 pm »

Ah, yes, of course, you're right

167

22.1 Legacy Series / How to disable unbound scrubbing?

« on: May 24, 2022, 06:59:53 pm »

Hi,

apparently unbound figures it's supposed to prevent answers to queries that ask for about host names which are in local zones of the name server unbound is configured to query.  That makes unbound mostly useless.

Imagine this situation:

The name server ns.example.com (192.168.0.53) is serving the domain example.com and is connected to the LAN interface.  OPNsense has the name gw0.example.com and the LAN interface has the address 192.168.0.1.

The system name server is 192.168.0.53, and unbound is configured to forward all queries to 192.168.0.53.

When a client asks for host.example.com, 192.168.0.53 will answer 192.168.0.100.  When that same client asks for the same host, 192.168.0.1 (i. e. unbound) will answer without an IP address given in the answer.

Obviously, that sucks.  There is something in the log output of unbound like


debug: sanitize: removing public name with private address <host.example.com.> 192.168.0.53#53


So I take it that unbound somehow alters the answers given by the name server.  That seems to be default behaviour.  What kind of bug is that, and how do I make it so that unbound answers the queries correctly?

168

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 24, 2022, 02:09:41 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 ...)

169

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 24, 2022, 01:43:08 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 ...

170

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 24, 2022, 01:41:23 pm »

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.

171

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 24, 2022, 12:33:31 pm »

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?

172

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 24, 2022, 12:24:40 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

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?

173

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 23, 2022, 01:11:39 pm »

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?

174

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 23, 2022, 01:07:49 pm »

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

175

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 23, 2022, 11:47:54 am »

Try something like this.

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

176

General Discussion / Re: Maltrail on Opnsense

« on: May 23, 2022, 01:00:14 am »

Cool, thank you

177

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 23, 2022, 12:26:02 am »

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.

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.

178

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 22, 2022, 11:55:12 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.

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?

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.

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.)

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.

179

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 22, 2022, 11:22:06 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.

180

22.1 Legacy Series / Re: how to deal with IPv6?

« on: May 22, 2022, 11:15:36 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.