Messages

106

24.1 Legacy Series / Re: Help with routing from the opnsense firewall itself?

« on: March 18, 2024, 08:35:31 pm »

...
I've changed so many things and done so many experiments that I'm a bit lost, and am looking for some guidance of what the gateways, static routes, and rules SHOULD be configured like in a configuration like mine.
...

From your topology description shouldn't be more that a simple static route. Because you changed so many things start over with a clean install, otherwise this relative simple issue will be a ping-pong of "it's not working".

So, clean install, create your topology and after that you don't need more than:

A gateway:

System -> Gateways -> Configuration -> Plus Sign to add -> Name [VLAN_ROUTER], Interface [LACP_TRUNK], Address Family [IPv4], Disable Gateway Monitoring [CHECK]

Leave ALL others DEFAULT (definitely not checking Far and/or Upstream gateway)

Save


A static route:

System -> Routes -> Configuration -> Plus sign to add -> Network Address [10.0.0.0/8] ->Gateway [VLAN_ROUTER] (or whatever you choose to name it in previous step)

Save


That should really be all...

107

24.1 Legacy Series / Re: ConnectX-3 stopped connecting after upgrade to 24.1

« on: March 05, 2024, 12:25:09 am »

Any suggestions for things to check?  I didn't have any problems on 23.7 with the card nor the ConnectX-2 that it replaced.  Once I get a chance I'm going to try rebooting to see if it comes up correctly or starts flapping again.

While it's a rather old(er) NIC, did you upgrade to latest firmware ?

https://downloaders.azurewebsites.net/downloaders/connectx3en_downloader/downloader2.html

I can remember there are some firmware / mode switches with Mellanox cards which might bug you, but it's too long ago to give you a direct pointer. You might find something here or do the firmware upgrade anyway (even if you're at latest version already) to reset the card to default.

https://network.nvidia.com/pdf/firmware/ConnectX3-FW-2_42_5000-release_notes.pdf

108

Tutorials and FAQs / Re: [HowTo] - PPPoE, VLAN & RFC4638

« on: March 02, 2024, 12:13:34 am »

@netnut Any reason that you have the WAN interface disabled?

The WAN interface isn't disabled (as seen at screenshot 1), I just renamed my physical WAN interfaces to WAN_1 and WAN_2 because I use multiple WAN uplinks. Be aware that interface naming is arbitrary with OPNsense, so you could name them anyway you want, of course it makes sense to select reasonable names.
In this example I used the physical WAN_1 interface for the PPPoE config with the two vlans.

Also can you please elaborate your assignments on picture 5? Currently my assignments are these https://i.ibb.co/fHF7cVY/Assignments.png.

The screenshots slightly differs from yours because these were made with an older version of OPNsense. I believe somewhere in 22.07 OPNsense switched from a one-to-one VLAN Interface <-> VLAN ID naming to a much more flexible naming where the VLAN interfaces are named incremental and don't have a fixed relation with the VLAN ID.

Will update the screenshots to avoid confusion, thanks for the reminder 

109

Virtual private networks / Re: OpenSSL: error:0308010C:digital envelope routines::unsupported:Global default li

« on: February 28, 2024, 11:58:35 pm »

OpenVPN with DDNS return error when client trying to connect:

2024-02-28 23:28:31 OpenSSL: error:0308010C:digital envelope routines::unsupported:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()
2024-02-28 23:28:31 OpenSSL: error:11800071:PKCS12 routines::mac verify failure:
2024-02-28 23:28:31 Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption

I located those comment. Still what is the correct way to resolve the problem?

Without details about your certificate setup, recreate all your client and/or server certificates and use some modern ciphers. OpenSSL is complaining about _very_ old ciphers used (RC2-40-CBC), if you use OpenVPN to keep your connection private using this cipher in 2024 is equivalent at using ROT13.

Don't use the "solution" you posted, this just instruct OpenSSL to support this old / insecure cipher, which is _very_ bad practice. The OpenVPN documentation contains enough instructions about creating client & server certificates.

 

110

General Discussion / Re: PPPoE with Modem before opnSense not working

« on: February 20, 2024, 12:06:03 am »

I got a Fritz!Box 7530ax from my ISP that was my modem, router, access point and switch. Now I only want it to be my modem. OPNSense is working fine with my Fritzbox plugged to my WAN port of course. But I have double NAT, from the fritzbox and the opnsense. And also the firewall on both. Thats not good - I dont want that.

You're using a Fritz!Box, one of the most open CPE's out there. Just create a static route for your local network on this box via the OPNsense WAN interface downstream, there shouldn't be any reason for "Double NAT".

Just to be sure to _un_check the "Block Private Networks" on this OPNsense WAN interface.

111

Hardware and Performance / Re: Upgrade path from quad port 1G Intel NIC

« on: February 13, 2024, 05:54:58 pm »

Obviously if money was no object I could just go with the third option and call it done, but I don't want to spend that much right now.  Which means I can either do nothing and deal with 1G for the time being or I try one of the under $100 options.  Not sure if they're worth the risk.

Any suggestions, predictions, or experience with any of the above?

I understand the 2.5Gb FoMo, but you will be disappointed...

That 1G AP ethernet port will be sufficient for many years to come in an average (power) home network. Not that much AX (6) or BE (7) WiFi client chipsets yet and most are max 2x2 MIMO. I'm using an (old) MacBook from 2015 which actually does 3x3 MIMO AC (5) and so connects with full 1300Mb on a AX (6) AP. Well, it's wireless so it max out at around 700Mb, more than enough for 1Gb.

Your 10Gb plans makes much more sense, even if you need some more time to deal with the costs. It will make you happier in the long run... 

112

General Discussion / Re: Question about LACP between OPNsense with Cisco 2960

« on: February 07, 2024, 06:54:35 pm »

Here is the output from "ifconfig -v lagg0"

Code: [Select]

root@gw:~ # ifconfig -v lagg0
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: OPT4 (opt4)
        options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NOMAP>
        ether 80:61:5f:15:a4:67
        laggproto lacp lagghash l2,l3,l4
        lagg options:
                flags=14<USE_NUMA,LACP_STRICT>
                flowid_shift: 16
        lagg statistics:
                active ports: 2
                flapping: 0
        lag id: [(8000,80-61-5F-15-A4-67,016B,0000,0000),
                 (8000,DC-CE-C1-CB-59-80,0001,0000,0000)]
        laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
                [(8000,80-61-5F-15-A4-67,016B,8000,0001),
                 (8000,DC-CE-C1-CB-59-80,0001,8000,0102)]
        laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
                [(8000,80-61-5F-15-A4-67,016B,8000,0002),
                 (8000,DC-CE-C1-CB-59-80,0001,8000,0103)]
        groups: lagg
        media: Ethernet autoselect
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@gw:~ #


Did you set the LACP Fast option at the OPNsense side ? Edit:  INTERFACES: OTHER TYPES: LAGG

So the output (ifconfig -v lagg0) shows something like this:

Code: [Select]

lagg options:
flags=80<LACP_FAST_TIMO>
flowid_shift: 16

Because your Cisco Switch is configured with it:

Code: [Select]

SW2960# show lacp neighbor
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode

Channel group 1 neighbors

Partner's information:

  LACP port                        Admin  Oper   Port    Port
Port      Flags   Priority  Dev ID          Age    key    Key    Number  State
Gi1/0/1   FA      32768     1111.5f15.2222  29s    0x0    0x16B  0x1     0x3F
Gi1/0/2   FA      32768     1111.5f15.2222  29s    0x0    0x16B  0x2     0x3F
SW2960#


113

23.7 Legacy Series / Re: Using own CA for certificates within OPNSense . How?

« on: February 07, 2024, 03:55:37 am »

Than simply explain to me, why apple mac os will not trust the keychain when the root CA certificate has a longer lifetime than 825? And when I do the exact same certificate with 825 days or less it works?

Multiple people in this thread confirmed the correct working of private Root CA's with a validity >10 year on Apple devices. Links are posted to "official" Apple docs. A personal anecdote doesn't define X509 standards.

I can't explain why your certificate setup isn't working without having access to the full certificate chain itself. Only in this thread I offered at least twice to paste your certificates for some "four eyes" analytics if you have trouble making certificates work.

Second:
Perhaps I‘m not clear enough on IOS:
You can import a root CA certificate to IOS as you (and myself) explained. But when you have an Intermediate Certificate derived from that root certificate and than have an end entity certificate derived from the intermediate certificate this end entitiy certificate is not trusted. Root CA Cert and Intermediate CA Certificate are imported as profile. (And the Intermediate ca certificate is also not shown in general info so you could trust it manually as you can do with the root certificate). All three certificates are created with OPNsense following the OPNsense documentation.

It's completly clear what you're doing, but that doesn't make it right.

Except for device/user specific certificates & keypairs, you don't import Intermediates and Client/Server certificates, that's something that things like web browsers do, as "last effort" if the PKI setup in use is invalid.

The only thing that's get imported on an Apple (or any other) device is the private Root CA and marked as one of the Trusted Root's, this is on top of the default CA Trust Store shipped by Apple https://support.apple.com/en-us/105116 (Challenge: Try to find a Root CA with a lifetime _less_ than 5 years.).

Looking at the OP, this is all that's needed to validate a certificate chain with, in this case, the certificate from the OPNsense Web GUI. Having a valid certificate chain results in the OP's goal to get rid of the: "being annoyed by the frequent warnings about self-signedd certificates".
An important thing to notice at this stage is the fact that this all "just works" because the OPNsense Web GUI is (correctly (*)) sending the full certificate chain (Server + Intermediate Certificate) to the (Apple) device. This way the (Apple) device can validate the chain starting at the imported private Root CA and next the, over HTTPS _received_, Intermediate and Client/Server Certificate.

(*)
[off topic]
OPNsense is a little bit too generous, it send it's Server, Intermediate _and_ Root Certificate when accessing the Web GUI. The Root CA is needless to send, Trusted Root's are defined in the Trust Store as explained above. The exception might be IPSec, where it sometimes makes sense to send the _full_ chain (including Root CA), but you configure that explicitly.
You waste some bandwidth sending the Root CA, but it can't harm in anyway...
[/off topic]

Now the next thing you're talking about are Client/Server (DNS) and/or End User (Email/SMIME) certificates (and keypairs) on the (Apple) device itself, a bit off topic and not needed for OP, but these are supported too. While you can import the Root CA by it's raw pem file, for these type of certificates & key pairs the most common deployment method is a bundle in PKCS #12 format; Did you use that ? How did you "craft" this file ?

114

23.7 Legacy Series / Re: Using own CA for certificates within OPNSense . How?

« on: February 05, 2024, 11:14:01 pm »

Limits that work for apple: CA certificate has a naximum of 825. End Entity certificates 397 days.

As stated multiple times in this topic, this is _NOT_ a restriction for Root and/or Intermediate certificates.

You can use Root CA, Intermediate CA, End entity on a mac by manually trust the Root CA (in Keychain management). BUT this will _not_ work on IOS devices. Here you only can trust a Root CA (Settings->geberal->info) and than use directly derived end entity certificates. (Tested with Sonoma and IOS 15)

One can perfectly import a single private Root CA in iOS (and iPad) devices, using Configuration Profiles or just sending the raw pem Root CA certificate and double click it and activate it in "VPN & Device Management". This is fully functional for decades and there are no specials, so stating "BUT this will _not_ work on IOS devices." is simply wrong.

115

General Discussion / Re: Weird issue with VPN-IPSEC-Connections

« on: February 05, 2024, 06:17:16 pm »

IKE v1 or v2 ?

With the new "connection" interface look carefull to the start/trap options and also at the rekey times. You might set the rekey a "little" bit less for the responder to prevent confusion and timeouts.

116

General Discussion / Re: SSL Certificates - Inside and Outside

« on: February 05, 2024, 06:07:40 pm »

It depends what you want to achieve, your OPNsense firewall (server) runs different programs (services). Although your firewall (server) does have a hostname, your certificate is used for these services.

The first _service_ your server _service_ is the Web GUI and SSH. The latter has it own way dealing with certificates (ssh keys) and is not using X509 certificates like the Web GUI. If you like to use your certificate for the Web GUI, yes it makes sense to rename the server (OPNsense firewall) to that particular fqdn. That's just for simplicity and clarity, because certificate validation doesn't care what the local hostname is, it checks 3 things:

1. Is the certificate valid ( Date from/to )
2. Do I trust the Root CA that signed the certificate
3. Is there a valid DNS record for the FQDN of the certificate (CN / SAN).

So if you have a (valid) certificate opnsense.domain.tld, a dns record that points to 1.2.3.4 and your OPNsense is listening to 1.2.3.4 your good to go, even if the local hostname of your box is pfsense.domain.tld. But again, it makes sense to match them, but not technically required.

So for inside and outside with the SAME certificate, having (split) DNS is probably the most simple one. So a DNS zone serving the internet and the same zone in a private controlled DNS infrastructure to serve the internal requests. The same can be done for X509 certificates, I only use public certificates on services exposed to the internet, for all internal stuff there's a private DNS and private X509 PKI.

 

117

23.7 Legacy Series / Re: Using own CA for certificates within OPNSense . How?

« on: January 31, 2024, 11:04:51 pm »

So you have to either limit the intermediate CA's validity to 398 days or have its "notBefore" date set to something in the past.

As already confirmed the 398 days are _only_ for Server / Client certificates, not for Root or Intermediate Root. Running here with a Root (20y), Intermediate (10y) and Server (398d).

I'm not creating certs with the builtin OPNsense Trust / PKI module but just importing them from outside, I can highly recommend the XCA tool for great flexibility and administration:

https://hohnstaedt.de/xca/

I have under organization: none in...... and use .home as topdomain. Can this also lead to errors?

For the org, yes, that could be problematic: Use _at least_ a O (Organization), C (Country) and of course CN (Common Name), all others are optional.

The domain name just have to match your DNS, so if you have a CN like: hostname.domainname.tld be sure you _ALWAYS_ create the CN _AND_ a corresponding SAN (with the same domainname) and a valid DNS record.

If it doesn't work, post here the full Certificate Chain in text mode (DON'T POST KEY FILES), like:

Code: [Select]

openssl x509 -in /path/to/root-ca.crt.pem -noout -text

openssl x509 -in /path/to/root-int.crt.pem -noout -text

openssl x509 -in /path/to/server.crt.pem -noout -text



118

Tutorials and FAQs / Re: Tutorial 2023/12: HAProxy + Let's Encrypt Wildcard Certificates + 100% A+ Rating

« on: January 31, 2024, 08:48:35 pm »

EDIT:
HAProxy refuses to start if a self-signed certificate is configured as (default) certificate under the SSL offloading section on a (HTTPS) frontend.
So for now it is best to remove the "INVALID_SNI" certificate as default from the HTTPS frontend.

@TheHellSite

I'm _not_ using your plugin, but I do use HAProxy on other systems with a crt-list, default self-signed cert and ocsp updates. So a shot in the dark, not sure if this "solves" your problem: You might want to declare your "default" certificate with "!*" in a crt-list to prevent errors:

https://www.haproxy.com/documentation/haproxy-configuration-manual/latest/#5.1-crt-list

/etc/haproxy/frontend-crt-list.conf

Code: [Select]

/path/to/default.crt.pem !*
/path/to/fqdn.crt.pem [ocsp-update on alpn h2,http/1.1] foo.bar
/path/to/wildcard.crt.pem [ocsp-update on alpn h2,http/1.1] *.foo.bar


119

General Discussion / Re: VLAN untag on specific interface

« on: January 26, 2024, 03:43:30 am »

I don't get what you mean by unnumered.

If you create a bridge device with one or more members, the only device with an IP address (L3) is the bridge device itself (numbered). All member interfaces are being bridged (L2) so just need to be enabled and assigned the parent bridge device without any IP configuration (unnumbered)

Your screenshots shows a bridge device with 192.168.10.1 and a member with 192.168.10.99, that last one should be unnumbered.

If you're patching both the "management" interface (igb1) and your LACP trunk (igb2+igb3) to the same switch and next create a bridge on igb1 with a VLAN assigned to the LACP trunk, yes, a better loop isn't possible .

120

General Discussion / Re: Howto setup rules for linux repository updates

« on: January 26, 2024, 03:35:21 am »

I would recommend that you just set up a local mirror instead.  That mirror can have internet access to sync and then everything else on your network can just pull their packages from it.  That way none of them require any internet access.  It will also reduce your bandwidth needs and provide faster updates.

You're now moving the OP's challenge to, the outbound firewall rule, of this mirror box ;-), it still needs the same "Alias" magic (with resiliency aka connectivity to potential _all_ mirrors).

...

That's way to hackish IMO.

Even better, their complete mirror list is available as JSON: https://github.com/AlmaLinux/mirrors/

Forget the DIY scrapper , create a cron job with a small script that fetches the mirror list, parse the JSON and fill an Alias. Voila