Messages

Just to give an update and share a little piece of interesting info:
I was able to setup the system using the provided docs for static assignment, but improving upon it by not actually doing static IP assignment. Using the EAP ID, it is possible to distinguish users in the connection settings. Then, each user can get a pool depending on his permissions, e.g. i now have one pool for "office-workers" and one pool for admins. Depending on that pool, firewall aliases and rules can be generated to accomodate the permissions. Problem solved. No need for each user having its own pool (as long as there are distinguishable groups regarding the permissions).

Thanks for your reply,

With the pool sharing i was thinking more along the lines of one pool per "security group", e.g. one pool for the normal users and one pool for the admins.
Having only basic understanding of the technical implementation of IPSec, your answer sounds like this could disturb IPSec's ability to properly distinguish the traffic (traffic selector)?
Definitely the 16 addresses for 16 users each sounds like my best bet then.

Hello and thanks for your reply,

If that is so, OpenVPN does sound like the superior solution, but, in our case, it is important that the default Windows VPN client can be used, and AFAIK, OpenVPN does rely on separately installed and maintained client software, which is unfortunate.
Otherwise, i wouldn't hesitate to use that instead, but since we have less than 15 users in the forseeable future, the IPSec way still seems to be less hassle.
Is it indeed correct that users cannot share pools in the IPSec scenario?
Then it would seem sensible to have something like a /28 or a /27 pool for each, splitting one /24 block for up to 16 users.

Hello and thanks for your reply,

I skimmed through the static IP per Roadwarrior section (have used the other sections before to setup what we have now) - so this seems to do the distinction part that i was stuck with, correct?
Multiple different connections with different authentication makes the system able to pick the right connection by user id?
If this is the way, doesn't this make it necessary to create one connection for every user?
So i would need 9 different connections for our 9 different users?
The nice part about the old solution is that with the %any ID, it does deduplicate the configuration effort nicely.

Just trying to make sense of your hint, but i would hope there is a simpler way to accomplish this maybe - even though it is nice that it is possible at all.

Hello,

We have been using a basic IPSec road warrior setup with MS-CHAPv2 authentication for some years successfully.
It is used to make it possible for users to access a few internal networks to e.g. print from home.
Now the need has arisen to have a way for admins to connect in and reach a wider range of internal networks, including sensitive ones.
Obviously, non-admins must not be able to connect into the more sensitive parts of the network.

To accomplish this, I was thinking about creating a separate IPSec connection and limit it to admin users.
But before I can even start, I already see the problem of distinguishing the two connections from the remote end?
Also, I see no way of defining a separate PSK database for the admin users, or restricting/enlarging the set of reachable subnets for any single user.
At the moment, there is just a single MS-CHAPv2 authentication method defined for all users (EAP-ID '%any'), which are all defined in the PSK database (IPSec -> Pre-Shared Keys)

Is it possible to configure this all, ideally using MS-CHAPv2 for users and admins, possibly using separate IPSec connections?
If so, how could this be done?

It could also be something simple like, in my experience, after changing fundamental settings (like WAN interface), sometimes opnsense behaves weird and buggy until rebooted.

So try rebooting after setting the foundational settings as you like, and see if it makes a difference (if you haven't already done so)

First off, you shouldn't need any WAN rules to make outbound connections work, so please remove them to save yourself from a terrible security problem.

Second, I would start off monitoring the firewall live log while pinging to see if things get dropped or pass, etc.

Also you can try pinging stuff like 8.8.8.8 or even the next gateway from your provider directly from opnsense with interface set to WAN, to rule out your LAN as the problem.

Hello there,

so we got a new fiber line from our provider, and a modem to go along with it.
Now since we have multiple sites and many internal networks per site, I am using the 10.0.0.0/8 address range.
This new modem that we got will only show its web interface on VLAN 0 in subnet 192.168.100.0/24 though.
While its not that much of a problem to just set the interface up that way, I figured maybe I could just "hide" that network such that, let's say 10.10.10.0/24 will be natted and routed to 192.168.100.0/24.
So instead of pinging the modem at lets say, 192.168.100.2, I could use 10.10.10.2.
This way it fits in with our addressing scheme better.
Also, if we get a second modem for a second line, this way address conflicts could be avoided.

Am I on the right track when I think that 1:1 NAT can help me here?
I tried to set it up but it didn't work, but before I post configs I want to know if I'm even going into the right direction here.

Everyone who read this far, thanks for your time and have a nice day,
Daniel

As a side note, why are you even running your main firewall on a VM when you could just use a physical machine? It is much more reliable in many ways and you will get better latencies as well.

The machines calculated their addresses correctly, but got the wrong router IP from the RA (from the wrong subnet), leading to no connectivity.

That's unexpected. By 'router IP' you mean the link-local source address of the RAs? I don't see how this could be affected by the RA flags. In other words, if this worked in 'Managed' mode but doesn't in 'Assisted', 'Stateless' or 'Unmanaged', something else must be going on. Anything else you changed during troubleshooting?

SLAAC is working rock solid here (multiple interfaces with a mix of 'Assisted', 'Stateless' and 'Unmanaged' RAs).

Cheers

Maurice

So what happened was actually that they calculated an IP within their respective subnet, and they probably got the correct DNS server, but when they tried to DNS resolve opnsense, it would return an IP from the wrong subnet (which is not really what I wrote, sorry), and also the machines had no outbound connectivity to the internet or to other v6 enabled local subnets (which they should be able to access due to fw rules). So something went wrong with the routing, which is weird. Also weird is that I could even see outbound packets on WAN when for example running "ping -6 google.de" from affected machines. But no answer was returned. As I said, I didn't troubleshoot it deeply, because I didn't want to interfere too much with workers.

The "intermittently unresponsive" issue was introduced for both Router Advertisements (which broke SLAAC) and DHCPv6 when OPNsense switched to FreeBSD 12.1 in 20.7. For Router Advertisements, it was eventually solved by patching radvd. So SLAAC works again in 21.1. But for DHCPv6, no fix is available yet (that includes the 21.7 development version). If you depend on DHCPv6, you'll have to use a separate DHCPv6 server for the time being. Since you have Windows clients and might have a Windows Server: The Microsoft DHCP server works just fine.

Cheers

Maurice

Unfortunately, on the first system I tested, SLAAC also didn't work. The machines calculated their addresses correctly, but got the wrong router IP from the RA (from the wrong subnet), leading to no connectivity.
So now I have decided to turn off v6 on that interface entirely for now and wait it out until fixes appear. Hopefully, connectivity won't be affected too much by disabling v6 but I see no other sensible option for me right now.

I'm curious - if you set RA to "Assisted" instead of "Managed" does it survive any better?  Or perhaps it fails in the same way but typical user client traffic will flow because Windows falls back to SLAAC-obtained addresses?

The problem would be that in this case, connections would still fail because of the "bad" addresses coming and going, and TCP sessions going stale because of that. So I don't think I will experiment with that too much if SLAAC on its own avoids the problem for now.

The "intermittently unresponsive" issue was introduced for both Router Advertisements (which broke SLAAC) and DHCPv6 when OPNsense switched to FreeBSD 12.1 in 20.7. For Router Advertisements, it was eventually solved by patching radvd. So SLAAC works again in 21.1. But for DHCPv6, no fix is available yet (that includes the 21.7 development version). If you depend on DHCPv6, you'll have to use a separate DHCPv6 server for the time being. Since you have Windows clients and might have a Windows Server: The Microsoft DHCP server works just fine.

Cheers

Maurice

Nice to know, thanks. The Windows machines are actually not in a local domain at all, they are cloud managed with azure, so Microsoft DHCP is not an option (and I probably wouldn't even do it with a local domain tbh). But I will simply switch the machines to SLAAC since that should work. We never "depended" on dhcp6 anyway, I just used it since it seems more convenient to be able to somewhat control the addresses, and we were already using it successfully on other subnets.

Anything less than 120GB or so has terrible IOPS and longevity so I would avoid it. Also smaller SSDs are not much cheaper because nobody buys them.
The disk util will go up a little with logs growing and package caches filling up. Also there should always be a few gigabytes of free space for installing of upgrades.
Additionally, some plugins will lead to a much higher disk util, e.g. ntop

Possibly related to this?:

DHCPv6 server intermittently unresponsive, not responding to solicits
https://github.com/opnsense/core/issues/4691

That sounds unnervingly similar to what I encounter, I will try to check using a packet capture like suggested if it is the case.
Though I must say even not having checked it, the intermittent nature of the error leads me to believe it is a software bug and not a misconfiguration.

EDIT: I just made a quick packet capture and it seems to be true. I can see ip6 dhcp6 request that remain unanswered by the server. They just get ignored. I will post on github about my findings, because AFAIK this problem *should* have been 21.7.x only