Messages

151

General Discussion / Re: Importing Intermediate (Issuing) CA Certificates

« on: November 07, 2021, 02:03:20 pm »

One feature I find notably missing in OPNsense is an indication of all places in the system where the certificates are in use.

Just noticed a basic indication of where certificates are in use on the far RHS of the System: Trust: Certificates view.

If it could provide more info that would be awesome. Is the data available in the model?

152

General Discussion / A one-legged OPNsense dilemma...

« on: November 07, 2021, 01:50:25 pm »

Was wondering if anyone had setup OPNsense with a single leg on LAN only. If so, any gotchas...?

I was thinking it might become necessary to spin up FreeRADIUS as a temporary PoC to get some answers for this topic.

Just wanted to know if it was possible... 

TIA,
Ben

153

21.7 Legacy Series / Re: PPPoE IPv6 Prefix Delegation with Static WAN Assignment

« on: November 07, 2021, 01:31:18 pm »

The root of the question is a way to configure publicly routable IPv6 addresses on the WAN...

That's all I'm trying to address.

Complexity, latency, energy, manageability, security, space, bufferbloat (although the fritz is one of the "better" CPE's). With an OPNSense box orders of magnitude more powerfull than a fritznox there's no benefit.

There is likely some benefit to it operating as a bastion host. There could also be some benefit to it acting as a RG (Residential Gateway), and I am curious as to whether having it act as such would solve your problem (or at least assist with troubleshooting it) as I detail below.

I took the fritzbox example as a "proof of concept" as supported and implemented by my ISP with IPv6 PD, don't understand why you keep refering to it ;-). Besides the fact I don't use a Fritzbox your suggestion is about a dhcp6c client configuration over PPPoE, that is going to my ISP (not to a fritzbox) that _doesn't_ give anything else than a IPv6 prefix. So with or without IA-NA's, that address is not automagicly created by dark matter or forces.
Even more important is that any override scripts breaks the excelent integration of the Track Interface configuration option in the OPNSense GUI, which I use for over 10 interfaces that are getting their /64 from the /48.

Firstly, the Track Interface configuration will not change (provided you are tracking the WAN). You would still need to do this. So you could consider this configuration item completed..

The dhcp6c override script exposes several advanced settings not otherwise in the GUI, including how solicit messages are packaged together. Depending on how the DHCPv6 request is crafted will likely determine how your ISP's BNG will respond.

In your OP, you mention your PoC with the Fritzbox works, i.e. it gets a routable IPv6 address and a PD. It is worth mentioning that your ISP's BNG will most likely treat a PPP request from your CPE - or more correctly, RG - differently depending on what your RG is. It will also treat requests from your subscriber network, i.e. behind the RG, differently too. If you have your Fritzbox setup as your RG doing the PPPoE, and your OPNsense box merely doing a DHCPv6 request via your Fritzbox (or PPPoE if that fails - which is unlikely), your OPNsense box will likely get an IA-NA IPv6 address for your WAN as well as the PD.

Having said all that, on your WAN interface, did you tick Request only an IPv6 prefix (in standard configuration view), or neglect to tick Non-Temporary Address Allocation for Identity Association (which is the IA-NA btw - in Advanced configuration view)...? If so, that would likely be the cause of your problem. I also presume your PPPoE is setup as a "dual-stack" with PPPoE via IPv4 and your IPv6 Configuration Type set as DHCPv6 (and not Static). Lastly, did you make sure that Prefer to use IPv4 even if IPv6 is available at System: Settings: General > Networking > Prefer IPv4 over IPv6 is not ticked (perhaps unrelated).

You could achieve something similar with the override script too. My previous posts were about hacking that up, but I now think that unnecessary. I think you could probably achieve what you want with a standard script setup, specifying your WAN interface in id-assoc na 0 only if necessary. I still think that could possibly work without your Fritzbox, but I think it is worthwhile checking with it in the mix in bridge or pass-through mode before adding the complexity of PPPoE/DHCP <--> RG <--> BNG interactions.

You could give some of this a go and share what you learn. I leave it up to you.

154

General Discussion / Re: FreeRadius EAP Settings Root and Server Certificate

« on: November 07, 2021, 12:07:27 pm »

I presume your client device is your Mac. You will need to recreate a new WiFi profile to use EAP-TLS. IIRC (and it has been some time), I believe you import the client certificate into the profile rather than the store.

It's a bit weird that it prompted for credentials anyway. Maybe restart OPNsense...

I would observe the log at Services: FreeRADIUS: Log File straight after powering on to see if there are any errors on startup, and then again whilst trying to connect to see what is going on. Maybe post your log if you see errors or it doesn't work.

I also think it worthwhile to try a Windows client too. It's possible that Windows will not like the certificates that OPNsense creates, so you should probably check that now.

155

General Discussion / Re: ldaps (636/tcp) won't work on internal lan VM's

« on: November 07, 2021, 11:31:10 am »

So it seems the ldaps port is open and listening.

Your tests confirm that ldap is listening on 636/tcp, but not that it is open.

Both mail and nextcloud VMs are [on] that lan and the ufw firewall on the mail/ldaps VM is set allow ldaps from anywhere the ip of the nextcloud/ldap client.

I think your problem is here. The wording of your ufw rule seems a little off when you mention VM2. Moreover, if both your VM1 and VM2 systems are on the same network, OPNsense has nothing to do with filtering those packets.

I would try connecting from VM2 using netcat:

Code: [Select]

nc -zvn <IP of VM1> 636
If that doesn't work, briefly disable ufw on VM1:

Code: [Select]

sudo ufw disable...and then check again from VM2 using netcat as before.

If that works, you need to correct your ufw rule (and enable ufw again).

I would suggest it should look something like the following:

Code: [Select]

<redacted>:~$ sudo ufw status
[sudo] password for <redacted>:
Status: active

To                         Action      From
--                         ------      ----
636/tcp                    ALLOW       Anywhere         
...
Regarding that rule, if you have WAN clients trying to connect to LDAPS on your OPNsense WAN IP and you are not performing NAT of those connections at OPNsense, your ufw will have to permit any source to connect. You may want to reconsider publishing LDAP on your WAN, it will get hit and harvested for credentials. Perhaps consider using OPNsense's VPN server offerings and connecting your clients via VPN. Then you can configure your ufw to permit just the VPN subnet and VM2. Like this:

Code: [Select]

<redacted>:~$ sudo ufw status
[sudo] password for <redacted>:
Status: active

To                         Action      From
--                         ------      ----
636/tcp                    ALLOW       <VPN Client Network/mask>         
636/tcp                    ALLOW       <IP of VM2>         
...
It's also worth mentioning that it is conceivable that the outbound connections permitted by ufw on VM2 are too restrictive. You may want to disable ufw on that host to perform your checks too.

You can also launch the GUI if you find that more intuitive:

Code: [Select]

sudo gufw

156

21.7 Legacy Series / Re: PPPoE IPv6 Prefix Delegation with Static WAN Assignment

« on: November 07, 2021, 05:53:35 am »

I'm presuming your preference to not make use of your Fritzbox is for the sake of simplicity, and maybe to eliminate a SPoF, but is there any another reason...?

I only ask because it's possible if you do use the overrride script - and leave send ia-na 0 and id-assoc na 0 alone - it's possible your Fritzbox will assign your WAN an IP too (and not just the PD). Is it worth giving it a go?

157

General Discussion / Re: Importing Intermediate (Issuing) CA Certificates

« on: November 06, 2021, 03:19:13 pm »

I have no idea how you can predict at what point developers of third-party applications will decide to change their behavior

Well obviously you can't predict such changes, but you can respond to them, even if the response is to recognise the problem and do nothing. For example, in the case of curl, an issue could be raised to assess curl's use of the partial_chain option. It might be determined that it does present a security issue that needs to be resolved, if say, a critical core or plugin function relies on curl and fully valid trust chains are expected. Or it might be determined that nothing should be done, but at least that decision is then documented.

When doing config, would there be any value to selecting certs from the store in a drop down list, e.g. how it works now when setting the Web GUI SSL Certificate...? Just the same for issuing CA certs when needed. Or is that how it is already implemented..?

sorry, did not quite understand the question. user selects the server certificate for application in GUI. if there are referenced CA's certificates in System: Trust: Authorities, the chain is built automatically and placed in the appropriate application directories

Yes, that was essentially my question. I did assume an interim step: that when required for any particular configuration, the issuing CA would be pre-populated in the relevant GUI field.

I've seen over the last several days that there is quite the mixture of different implementations. Are you aware of any OPNsense standard for plugin development is this space, or is it left up to the plugin dev to make these calls...?

I guess I see some value in trusting what is in the store to populate GUI fields and subsequent configurations. One feature I find notably missing in OPNsense is an indication of all places in the system where the certificates are in use. I think if something like that was implemented, then a system-wide framework for managing certificates would be more feasible. This would allow for the replacement of certificates in plugins before deleting expired or revoked certs from the store. Automated replacement of plugin certificates via, e.g. a wizard at System: Trust, would also be feasible.

Does OPNsense core or HAProxy or nginix even do CRL checking or OSCP verification or stapling? Are any of these verification techniques default behaviour for OpenSSL (presuming that this or LibreSSL are what all of core and the plugins rely on), or would such checks need to be invoked deliberately...?

it's all on the app (nginx, for example, does not work with CRL distibuton points or some. CRLs are checked only if the file is explicitly specified). I do not think that the OPNsense should and in the right to do its work for the app.

I agree in principle.

Provided the GUI exposes the functionality of the plugin to use such features (otherwise the novice may not be aware of the feature or be able to configure it). I note nginx has true OSCP validation and stapling capabilities built in. It is my understanding HAProxy relies on running a cron job to update files in a watch directory. I couldn't tell if OPNsense does external CRL or OSCP validation at all (with a preference for the latter). I would hope that it does.

If a cron job or daemon ran to check CRLs / OSCP validation of certificates in the OPNsense store at some reasonable (and configurable) interval, I see some benefit to a system-wide notification of invalid certificates being in use. Such a notification could be an alert to support personnel or even a watchdog process that can optionally shutdown plugins affected by revoked or invalidated certificates.

I think, if OPNsense should play any role in this space, the above would be it. If all plugins only make use of certificates in the OPNsense store, then this would mean any issues with certificate validity could be captured and acted upon.

An extension of this would be timely notifications for expiring certificates.

How does one make the internal Root CA offline...?

... but. if we are talking about best practices, then IMHO it is better not to use an internal opnsense CA in a production environment at all (for debugging and emergency use only). OPNsense is not a CA and does not try to seem like ..

Yes, clearly this would be the better practice. It is also somewhat dubious operating multiple CAs on the one system. 

158

General Discussion / Re: ldaps (636/tcp) won't work on internal lan VM's

« on: November 06, 2021, 01:36:50 pm »

Presuming all your VMs are on the same subnet, have you probed LDAPS (636/tcp) on VM1 from VM2 or VM3 using netcat, nmap, etc. to see if it responds...? You should probably also check that your service is listening on 636/tcp using lsof, netstat, ss, etc.

If your VMs are not all on the same subnet, and are using discrete or multiple shared interfaces on the OPNsense firewall, please share a little of that setup, including interfaces used, firewall rules and any NAT that you may have configured.

From your description, it seems possible that you are trying to do too much with one interface. I should mention that mixing WAN and LAN IP addresses on a single interface is unlikely to work and exposes an exploitable vulnerability. You might need to configure VLANs within Proxmox to provide some network demarcation. The problem you will encounter is that your Linux Bridge will need to be your WAN.

Practically, this means you will either need to tunnel with a VPN through to your LAN, or expose SSH on your WAN and port forward to your VM3 (as an example) - both of which require you to work from your WAN, i.e. the internet. Alternatively, you could trunk WAN and LAN VLANs through your one interface and break them out on a 802.1Q-capable switch. I note that mixing WAN and LAN VLANs in the one trunk also exposes an exploitable vulnerability.

Having at least two physical network interfaces will really make your solution much more workable. You could then have separate bridges for your WAN and LAN. Place VM3 and your Proxmox box in LAN, plus any physical device you would use to access VM3 (or anything for that matter). You would then create virtualised networks for your servers with corresponding virtual interfaces on your OPNsense firewall. If any of your servers are physical you should add at least one more NIC to trunk those networks to an external switch.

Unless you have reason to, you should not expose your Proxmox server to the internet. Are you publishing anything on it? If not, just bridge it on the LAN side.

Finally, you really should not publish your publicly routable IP addresses on this public forum. If you publish those addresses and potential design vulnerabilities, nefarious personalities might take advantage of that.

159

21.7 Legacy Series / Re: PPPoE IPv6 Prefix Delegation with Static WAN Assignment

« on: November 06, 2021, 01:56:19 am »

Yep, ok...

So, if I'm not mistaken, you're not getting a publicly routable IPv6 address assigned to your WAN, just the assigned prefix.

You might be able to make use of the override script "ported" from pfSense mentioned here. It's based on the one shown on NetGate here.

Normally you would still use your Fritzbox, but perhaps that's not necessary (maybe remove send ia-na 0 and id-assoc na 0 and try). In any case, you would assign your WAN interface to id-assoc pd 0.

I would have thought that there would be a built-in configuration item in OPNsense for this, but maybe not...

160

21.7 Legacy Series / Re: PPPoE IPv6 Prefix Delegation with Static WAN Assignment

« on: November 06, 2021, 12:49:30 am »

Just a stab in the dark:

You would need to operate your CPE in bridge-mode or at least use PPPoE pass-through.

Not all CPEs will do bridge-mode.

161

Zenarmor (Sensei) / Re: Remove Sensei swap

« on: November 06, 2021, 12:30:56 am »

Yep, faster than most disk too... 

162

Zenarmor (Sensei) / Re: Remove Sensei swap

« on: November 05, 2021, 05:18:11 pm »

I'd say the memory disk is most likely a malloc backed device created every time Sensei starts.

If the files on the memory disk hold potentially sensitive information they will not survive system halt and cannot be recovered. Also, if data in files on the memory disk are corrupted or contain an exploit or malware, a process stop or panic will delete them when the device is recreated, and a system panic or restart will likely delete them upon halt.

Best to leave it be methinks. 

@Nikotine, you might want to post a link to this topic in the other thread so people coming across it can benefit from the expertise on this board.

163

21.7 Legacy Series / Re: How to properly configure a rule for RPC?

« on: November 05, 2021, 02:01:58 pm »

I believe that would require a helper capable of inspection and control at OSI Layer 5 (Session Layer) at a minimum and for that information to be maintained in some sort of session state table (or THE session state table).

Usually this would require hardware inspection, i.e. ASICs, to not adversely affect performance. That being said, clearly some software firewalls over the years have been able to do this (think M$). IIRC, with the demise of TMG, I think Barracuda and some others picked up this feature.

I'm not aware of anything in the OPNsense space that would fit the bill.

Maybe some Layer 7 plugin...? Are there any?

164

General Discussion / Re: FreeRadius EAP Settings Root and Server Certificate

« on: November 05, 2021, 01:28:55 pm »

Hi Crissi,

I think you quoted yourself instead of me in your last post. 

The Default EAP Type, is technically a poor heading. I'm unsure what "default" refers to, i.e is there a fallback method? The options are somewhat ambiguous too as PEAP is not an inner method or EAP type. I would suggest that the broadest interoperability will be achieved using EAP-TLS, which I presume is simply TLS in the drop down list. If I get time, I will look at the code to see what each of these are actually doing in the FreeRADIUS config, but I suggest that you not hold your breath for me to do so. 8^d

Upon changing to EAP-TLS, each client - or more correctly - supplicant, whether device or user, will need a fourth certificate: a client certificate. The first three are about trusting the server, the fourth is to authenticate the client.

You should check if FreeRADIUS/OPNsense has auto-magically created Client Certificates for you in System: Trust: Certificates. If not, you will need to create one for each user or device manually by clicking the Add button at System: Trust: Certificates and then choosing "Create an internal Certificate". When doing so, ensure you select the Intermediate CA at the "Certificate Authority", Client Certificate at "Type", and finally that the Common Name is the same as the device or user name so that you can tick the Check TLS Common-Name checkbox at Services: FreeRADIUS: EAP.

Either way, when you have Client Certificates, they should be downloaded to the respective device (if for a device) or devices (if for a user - wherever that user needs access).

After this, you should not be prompted for credentials.

You can use OPNsense as a CA, it just wouldn't typically be recommended as a security best practice, especially if OPNsense is operating as your perimeter firewall. The same would go for your user accounts. You may want to consider migrating the user database to an LDAP database on another server and do the same for your Issuing CA (and keep your Root CA offline).

As for making the Root CA offline on OPNsense, I don't believe this is physically possible. The private key must not be present but the certificate must be imported to ensure the full trust chain is available. On a truly offline Root CA, the CA itself is powered off and is air-gapped from the network, i.e. it has no network port. Updated files, e.g. a CRL or new issuing CA certificate, must be transferred by another mechanism, e.g. a USB flash drive.

Hope that's enough to keep you going... 

165

General Discussion / Re: FreeRadius EAP Settings Root and Server Certificate

« on: November 05, 2021, 08:29:29 am »

Regarding the number of certificates and using this solution for Windows and and Android devices, you would need to provide some more information about your use scenario(s). Also, the inclusion of Windows clients will likely be your limiting factor when making your solution homogeneous or platform-independent.

If this is for an enterprise, and you have Windows devices that are part of an Active Directory domain, you must choose a certificate-based supplicant authentication technique rather than using encrypted usernames and passwords. If you do not, the device will not be able to connect to the network prior to the user logging in and authenticating. In this use case, the device and not the user is the "client" and as the device effectively does not have a password, you must use a certificate assigned to the device instead (for authentication).

What Default EAP Type did you choose at Services: FreeRADIUS: EAP...?

When you connect your Mac, I presume you get asked for username and password, yes?

Regarding changing the GUI to say "Issuing CA Certificate", "someone" can raise it as an issue on Git. However, I would wait until any issues you are having are sorted out first.

To move the Root CA offline, you could try the technique I posted here, but I note it is NOT tested. I note Fright's comments below my post that, in his humble opinion, OPNsense really isn't built to be a CA and should not really be used for production purposes.

Having said that, if you are using FreeRADIUS to manage users and clients internally, i.e. it is your user database (rather than say using a LDAP database), perhaps it has functionality to create client certificates (I don't know) in which case you might need the integrated CA.

If you do decide to move the Root CA offline, perhaps you can post your outcome here, or in the other topic, or maybe even start a new topic.