Topics

Moin,

ich hab in meiner privaten Sense ein Interface, welches auf einen ue0 Adapter gebunden ist.

Dieses ue0 ist ein USB-Adapter, der so gut wie nie an der Sense angeschlossen ist. Ich nutze dieses Interface, wenn meine WAN-Verbindung down ist. Dann steck ich mein Android-Handy mit aktiviertem USB-Thetering an die Sense und kann so mein ganzes Netzwerk über die Mobilfunkverbindung online bringen.

Ich hab schon länger keine Änderungen mehr an den Interfaces im privaten Netz vornehmen müssen, daher weiß ich nicht, wie lang folgendes Problem auftritt:

Früher konnte ich unter Interfaces -> Assignements Änderungen vornehmen, auch wenn der ue0 nicht verbunden war. Jetzt lässt sich aber keine Änderung mehr durchführen, sobald auch nur ein Interface auf Missing steht.

Gibt es einen Workaround um Assignements zu ändern auch wenn ein oder mehrere Interfaces auf missing stehen?

Das Problem betrifft nicht nur ue0, sondern ich hab es auch noch deaktivierte Wireguard-Adapter, die ich nicht immer brauche und nur bei Gelegenheit aktiviere.

Hi,

have the exact same issue with 24.1.2 like described here: https://forum.opnsense.org/index.php?topic=23412.0

Its an APU 1d4 (AMD G-T40E Processorm 4GB Ram and a 32GB SSD)

In my case, I reinstalled with the 24.1 iso because I switched to ZFS based installation some weeks ago. I uploaded the config backup and everything worked fine first, including the console menu.

Today, I noticed that the console menu is not displayed anymore. I have no clue whats the reason for this issue.

How to fix this?

No other issues detected at the moment. Restart does not help.

[Matured OPNsense:]

Hi all,

i see very poor throughput with OPNsense installations running in VMware VM (ESXi8) using vmxnet3 vNICs in fast networks. The following networks are based on a 10G network.

Matured OPNsense:
The reason for this thread is:  I cant get over 2,7Gbit/s with iperf3 between the opnsense and my windows client (both in same vlan with one switch in between) in a single stream connection.  Its not a iperf3 problem, because routed traffic is also not faster than 2,7Gbit/s. The 2,7Gbit limit seems to be a overall limitation.

Other VMs (Linux, Windows)
I can get easily over 9Gbit/s with Linux or Windows based VMs, so its definitly not a hardware, network or hypervisor related limitation.

Fresh plain FreeBSD 13.2
I installed a fresh plain FreeBSD 13.2 with iperf3 with same VM settings like the matured OPNsense  (8 vCPUs, 8GB ram, vmxnet3 adapter), same ESXi-host. The result is:

~5Gbit/s from client to FreeBSD, 6Gbit/s in reverse mode, both with only one iperf3 stream,
~8,5Gbit/s from client to FreeBSD, 7,3Gbit/s in reverse mode, both with two parallel iperf3 streams,
~9,2Gbit/s from client to FreeBSD, 8Gbit/s in reverse mode, both with three parallel iperf3 streams,

With three streams, utilization of the VM is at 42% from client to FreeBSD  and only 18% in reverse mode. Dont know if this unequal utilization is a iperf3 or FreeBSD issue.

Fresh plain OPNsense 23.7.4
After the results with plain FreeBSD 13.2, i installed a fresh plain OPNsense 23.7 (downloaded ISO file today) in a VM with exact same VM settings again. Updated it to  23.7.4 and installed iperf3 plugin (which is based on iperf v3.13). I applied a allow all floating rule to allow incomming connections to the iperf3 daemon.

When i started iperf3 the first time, I have seen this result:
~1Gbit/s from client to OPNsense with only one iperf3 stream

Because iperf3 plugin stops the iperf3 daemon once a test is canceled, I restarted the iperf3 daemon in the opnsense dashboard after every test. The after the first restart was:
~2.7Gbit/s from client to OPNsense with only one iperf3 stream

So, this is the first weird behavoiur in OPNsense. Why was the first test with 1G and the second with 2,7G? I was able to reproduce this after reverting the VM snapshot.

I continued the normal testing after this. Here are all results with firewall and one allow all floating rule enabled:

~2,8Gbit/s from client to OPNsense, ~3,1Gbit/s in reverse mode, both with only one iperf3 stream,
~5.2Gbit/s from client to OPNsense, ~3.9Gbit/s in reverse mode, both with two iperf3 streams,
~7.4Gbit/s from client to OPNsense, ~4.1Gbit/s in reverse mode, both with three iperf3 streams
~9Gbit/s from client to OPNsense, ~5Gbit/s in reverse mode, both with ten iperf3 streams

For comparison reasons, here is the CPU utilization for the test with three streams: 57% / 47%.


To make sure, that this is not an issue with the iperf3 plugin of OPNsense, i also uninstalled the plugin and installed iperf3 over cli using pkg install iperf3 (v3.14, a bit newer like FreeBSD 13.2). I then started iperf3 with: iperf3 -s. The result is:

~7.3Gbit/s from client to OPNsense, ~4,0Gbit/s in reverse mode, both with three iperf3 streams

Because the result is nearly the same like with the iperf3 plugin, I only tested it once with three streams.


I also disabled the firewall function over (Firewall -> Settings -> Advanced -> Disable Firewall. I removed the floating rule to check if FW is disabled. Here are the results:

~3,2Gbit/s from client to OPNsense, ~3,8Gbit/s in reverse mode, both with only one iperf3 stream,
~5.4Gbit/s from client to OPNsense, ~4,5Gbit/s in reverse mode, both with two iperf3 streams,
~7.4Gbit/s from client to OPNsense, ~4,3Gbit/s in reverse mode, both with three iperf3 streams
~9Gbit/s from client to OPNsense, ~5Gbit/s in reverse mode, both with ten iperf3 streams

For comparison reasons, here is the CPU utilization for this test with three streams: 50% / 47%.

With disabled firewall, throughput is a bit higher, but not much. Looks like the answer is not related to pf.


Matured OPNsense 23.7.4

To clarify that its totally different on a matured opnsense, I did a quick test again to show some results here:

~2,7Gbit/s from client to matured OPNsense, ~3,4Gbit/s in reverse mode, both with three iperf3 streams

CPU utilization: 35% / 30%.



Result

After this test series, it really looks like there is a  bottleneck in OPNsense when its installed in VMware with vmxnet3 adapters. I think its not a FreeBSD or driver issue, because throughput with plain FreeBSD is much better than with OPNsense. FreeBSD performance is also far away from perfection compared with Ubuntu and FreeBSD.

OPNsense is using a lot more compute power with less throughput than a plain FreeBSD.

I understand that there is possibly a lot of optimization in network components in a OPNsense, which causes a bigger overhead. But I think a core feature of a good firewall is efficiency and scaleability if the hardware is good enough.

Whats the reason for this issue?

Hallo alle,

ist denn bekannt, ob die Performance-Probleme bei Verwendung von VMXNET3-Adaptern in einer VMware VM mittlerweile behoben sind, behoben werden oder durch irgendwelche Tricks behoben werden können?

Ich hab mein Netz zu Hause jetzt durchweg auf 10G umgestellt und schaffe mit der Sense in einer VMware VM einfach nicht mehr als 2,7Gbit/s. Egal ob iperf3 oder gerouteter Traffic. Es spielt auch keine Rolle ob die Sense 2 oder 10 vCPUs hat. Es geht einfach nicht mehr.

Die Hardware die ich im Einsatz habe (Verlegekabel CAT7, guter 10G-Switch, 10G phys. NICs und moderne Ryzen-Systeme) ist durchweg stark genug. Mit anderen VMs, die im gleichen Netz hängen wie meine Workstation, sind 9-10Gbit/s Durchsatz locker drin. Sobald die Sense dazwischen hängt, geht nicht mehr.

Sehr frustrierend.

Hi all,

are there any plans to implement OpenID or SAML Authentication for NGINX Plugin @ OPNsense?
Or is it available over subscriptions?

For NGINX, a reference implementation is available here:

https://github.com/nginxinc/nginx-openid-connect
And here is how to install it: https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/

Has anybody tried to activate this over CLI?

Thanks

[.1.2-255]

Hi,

we would like to build a setup, where we have our public domain like https://our.domain.com/remoteservice-1/  (1 is a ID of a customer) which leads to our internal upstream servers like https://10.10.1.2-255/guacamole

https://our.domain.com/remotservice-2/ is the public URL for the second customer and so on, which lead to the internal upstream servers like https://10.10.2.2-254/guacamole


In a native NGINX setup, this can be done with

location /remoteservice-1/
        {
      proxy_pass         https://10.10.1.2/guacamole;
      proxy_redirect     default;
   }

Everything is working fine when we define our location with URL Pattern = "/" and URL Path Prefix  = none. In this case, we can open https://our.domain.com/guacamole and access the upstream.

We figured out, that a Upstream + URL Path prefix in the OPNsense location section is the same like
"proxy_pass         https://10.10.1.2/guacamole;" in a nginx config file.


So, we changed our location in the OPNsense to:
URL Pattern = /remoteservice-1/
and
URL Path prefix = /guacamole


But its not working.

When we open https://our.domain/remoteservice-1/ , we get the following error message in the browser:

Not Found

The resource you want to access is not available.

Please contact the webmaster if you think this is an error.

Web Application Protection by OPNsense

Is this a bug? How can we solve this issue?

Hello all,

I am a newbe in loadbalancing.

I would like to use NGINX on OPNsense for the following concept and not sure what to configure and how to write which rule exactly for this scenario.

We have a Domain like remote.domain.com and we would like to make different types of webbased remote services available over this domain for different projects (aka customers). The scheme of the URL to access the services should look like this:

remote.domain.com/selfservice/001
remote.domain.com/remoteaccess/004
remote.domain.com/statistics/43563

selfservice, remoteaccess and statistics are three different types of services.

001 = titan, 004, = bigtech, 43563 = hiddenchamp is the ID of the customers. But it should also be possible to use the project-/customer-name instead of the ID, like: remote.domain.com/selfservice/004 will use the same upstream like remote.domain.com/selfservice/bigtech

For each type of service+customer, we have a separated upstream, which can be a group of one ore more docker containers as upstream servers. Each container is directly connected to the physical network with its own IP.

What we have configured so far:
- We have a http server for remote.domain.com
- We have a location for remoteaccess, which is currently configured with pattern "/"
- We have differend upstreams, one for earch service and customer type, like "project 004 remoteaccess"
- In each Upstream, we have one or more upstream servers. For remoteaccess, these Upstream servers are available over ip or dns, like: http://10.10.4.20/rmtservice

At the moment, we can access remote.domain.com/rmtservice , because we hat the "/" pattern set.

I think, we need a custom location for each URL path, right?

I also think, that we need a URL rewriting rule to access the upstream "project 004 remoteaccess" when we try to open remote.domain.com/remoteaccess/004 in the browser, which will lead to x.x.x.x/rmtservice.

How to write this rule? I already tried to understand the syntax but all I tried did not work.

And is there anything else to configure or am I completely wrong?

Thanks.

Hi all,

we have a network configuration like shown in the attached picture.

Our problem is, that NAT is not working on the WAN Interface on OPNSENSE WAN and we dont know why.

We can ping to 8.8.8.8 from OPNSENSE WAN (because the SRC address of the packet which arrives at the ISP router is 10.90.0.3).
But we cant ping to 8.8.8.8 from OPNSESE CORE (because the SRC address which arrives at the IPS router is 10.90.2.1, but should also be 10.90.0.3).

The picture of the packet capture is from the WAN Interface of OPNSENSE WAN.

As far as we know, NAT is activated on the default [WAN] Interface in a default setup. So the WAN interface should NAT out of the box. If we take a look at the Firewall - NAT - Outbound NAT configuration on the OPNSENSE WAN, everything looks fine.

Any ideas why?


OPNSENSE WAN is a fresh installation.

Hi,

in one of our environments, we have two OPNsense ( 23.1.7_3 ) with activated FRR and OSPF which is just working fine.

Because of some problems with HAproxy and nginx on one of these two senses, we decided to install a fresh and clean OPNsense. When we tried to activate FRR with OSPF on the new installation, we were not able to get OSPF working. OSPF always stucked in Init/DROther.

We tried a lot of troubleshooting and in the packet captures of the OSPF interfaces on both senses we saw HELLO packets from the neighbor with plausible values, but nothing more. And yes, we applied allow all/any roules on the OSPF interfaces.

Then, I found this thread: https://forum.opnsense.org/index.php?topic=12413.0

We followed the workaround and disabled the firewall under Firewall -> Settings -> Advanced -> Disable Firewall  on the new installation and OSPF started to exchange routes immediately.

We enabled the firewall again but OSPF is still working, even if we disabled/enable FRR, OSPF, or if we restart the whole sense.

We cant explain this behavior, but it looks like that there may be some kind of cached data which leads into non initializing/working state.

This topic is just to let you know that there is an issue and whats a possible workaround for it.

Hallo alle,


wir haben auf unserer Sense ein WAN-Interface an dem das Internet hängt. Diesem ist ein ISP-Router vorgeschaltet. Der ISP-Router routet ein paar public IPs auf unsere Sense (Ziel ist die if WAN .2 Addresse).

Die Public IPs die wir auf die Sense geroutet bekommen sind auf der Sense alle als Virtual IP auf lo1 konfirugiert.


--------------
|ISP-Router |
--------------
   | if ISP .1
   |
   |
   | if WAN .2
--------
|Sense |---if lo1 (mit public IPs als Virtual IPs)
--------


Meine Frage bezieht sich auf die Firewallregeln.

Ich bin mir in folgendem Punkt nicht ganz sicher: Wird ein Paket, was einmal über ein physisches Interface in die Sense gelangt ist, dann nochmal am lo1 gefiltert?

Klar ist: Auf dem if WAN muss eine eingehende Regel erstellt werden, die den Traffic für die Public IPs zulässt. 

Aber muss oder kann ich auf dem Loopback-Interface auch nochmal Regeln erstellen, oder wird das nicht mehr gefiltert? Denn: Ein Loopbackinterface kann ja niemals von einem angeschlossenen "Kabel" erreicht werden, ein Loopback-Interface ist ja immer am Betriebssystem angeschlossen.

Es gibt mehrere Gründe, wieso ich die Public IPs gerne auf ein Loopbackinteface konfigurieren will:

1. Ich kann für jeden Kunden ein eigenes lo1 Interface anlegen. Das erleichtert die Konfiguratio und Übersicht von Regeln.

2. Bei Routern und L3-Switches anderer Hersteller ist es ratsam, IPs auf Loopback-Interfaces zu konfigurieren. Der Grund ist: Geht ein physikalisches Interface mal down, z.B. weil das Kabel gezogen wurde, sind dann oft auch alle virtuellen IPs, die auf dieses Interface konfiguriert wurden, nicht mehr erreichbar. In dem Punkt weiß ich aber nicht, wie sicht die Sense verhält. Daher die Frage:

Wie verhält sich die Sense hier? Welchen Unterschied macht es, ob die Virtual IPs auf ein physikalisches Interface oder ein Loopback konfiguriert sind?

Wie macht ihr das? Wo filtert ihr Adressen die auf einem Loopback hängen?

[Interesting fact: From the time on when WAN droped, we were able to ping all assigned virtual IP addresses which are located on lo1. At this time, we had no allow rules on our WAN interface configured.]

Hi,

v23.1.7_3 here.

We have the same issue like discussed here: https://forum.opnsense.org/index.php?topic=25776.0

Our WAN connection drops when we try to renew a certificate.

Yesterday we just added two certifcates to acme on this installation and we were able to get the certificates over LE. This action was the last we did yesterday.

Today, we added some more entries and tried to get the certificates for it which lead into instant WAN drop during the time ACME tries to get certificate.

This is what appeared in the ACME Log and was in a loop for almost 30minutes (normal log level):

[...]
2023-05-12T09:25:17   acme.sh   [Fri May 12 09:25:17 CEST 2023] Sleep 10 and retry.
2023-05-12T09:25:17   acme.sh   [Fri May 12 09:25:17 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:25:17   acme.sh   [Fri May 12 09:25:17 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:25:17   acme.sh   [Fri May 12 09:25:17 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:25:17   acme.sh   [Fri May 12 09:25:17 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:25:06   acme.sh   [Fri May 12 09:25:06 CEST 2023] Sleep 10 and retry.
2023-05-12T09:25:06   acme.sh   [Fri May 12 09:25:06 CEST 2023] Sleep 10 and retry.
2023-05-12T09:25:06   acme.sh   [Fri May 12 09:25:06 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:25:06   acme.sh   [Fri May 12 09:25:06 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:25:06   acme.sh   [Fri May 12 09:25:06 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:25:06   acme.sh   [Fri May 12 09:25:06 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:25:01   acme.sh   [Fri May 12 09:25:01 CEST 2023] Can not init api, for https://acme-v02.api.letsencrypt.org/directory
2023-05-12T09:24:56   acme.sh   [Fri May 12 09:24:56 CEST 2023] Sleep 10 and retry.
2023-05-12T09:24:56   acme.sh   [Fri May 12 09:24:56 CEST 2023] Sleep 10 and retry.
2023-05-12T09:24:56   acme.sh   [Fri May 12 09:24:56 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:24:56   acme.sh   [Fri May 12 09:24:56 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:24:56   acme.sh   [Fri May 12 09:24:56 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:24:56   acme.sh   [Fri May 12 09:24:56 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:24:51   acme.sh   [Fri May 12 09:24:51 CEST 2023] Sleep 10 and retry.
2023-05-12T09:24:51   acme.sh   [Fri May 12 09:24:51 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:24:51   acme.sh   [Fri May 12 09:24:51 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:24:46   acme.sh   [Fri May 12 09:24:46 CEST 2023] Sleep 10 and retry.
2023-05-12T09:24:46   acme.sh   [Fri May 12 09:24:46 CEST 2023] Sleep 10 and retry.
2023-05-12T09:24:46   acme.sh   [Fri May 12 09:24:46 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:24:46   acme.sh   [Fri May 12 09:24:46 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:24:46   acme.sh   [Fri May 12 09:24:46 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T09:24:46   acme.sh   [Fri May 12 09:24:46 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6

We missed to change the log level at this time so this is all we know when we initially investigated the problem.

We restarted the ACME plugin, we stopped it and started manually, but even after this kind of restart the plugin continued to generate this log entries.

And then, half an our late, acme changed this behavior. At this time, we did not changed anything on the sense because we investigated our routings and DNS systems because of the WAN drops:

2023-05-12T09:52:39   acme.sh   [Fri May 12 09:52:39 CEST 2023] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
2023-05-12T09:52:39   acme.sh   [Fri May 12 09:52:39 CEST 2023] Please add '--debug' or '--log' to check more details.
2023-05-12T09:52:39   acme.sh   [Fri May 12 09:52:39 CEST 2023] our.doma.in:Verify error:111.222.333.444: Fetching http://our.doma.in/.well-known/acme-challenge/DzO5vM6mIrp09Jxc5g3YOU4fv8YV-pDO1bI5tkBEpB8: Timeout during connect (likely firewall problem)
2023-05-12T09:52:37   acme.sh   [Fri May 12 09:52:37 CEST 2023] Pending, The CA is processing your order, please just wait. (5/30)
2023-05-12T09:52:34   acme.sh   [Fri May 12 09:52:34 CEST 2023] Pending, The CA is processing your order, please just wait. (4/30)
2023-05-12T09:52:31   acme.sh   [Fri May 12 09:52:31 CEST 2023] Pending, The CA is processing your order, please just wait. (3/30)
2023-05-12T09:52:29   acme.sh   [Fri May 12 09:52:29 CEST 2023] Pending, The CA is processing your order, please just wait. (2/30)
2023-05-12T09:52:26   acme.sh   [Fri May 12 09:52:26 CEST 2023] Pending, The CA is processing your order, please just wait. (1/30)
2023-05-12T09:52:26   acme.sh   [Fri May 12 09:52:26 CEST 2023] Verifying: our.doma.in
2023-05-12T09:52:26   acme.sh   [Fri May 12 09:52:26 CEST 2023] Getting webroot for domain='our.doma.in'
2023-05-12T09:52:24   acme.sh   [Fri May 12 09:52:24 CEST 2023] Getting domain auth token for each domain
2023-05-12T09:52:24   acme.sh   [Fri May 12 09:52:24 CEST 2023] Single domain='our.doma.in'
2023-05-12T09:52:24   acme.sh   [Fri May 12 09:52:24 CEST 2023] The domain key is here: /var/etc/acme-client/home/our.doma.in/our.doma.in.key
2023-05-12T09:52:24   acme.sh   [Fri May 12 09:52:24 CEST 2023] Creating domain key
2023-05-12T09:52:24   acme.sh   [Fri May 12 09:52:24 CEST 2023] Using CA: https://acme-v02.api.letsencrypt.org/directory
2023-05-12T09:52:13   acme.sh   [Fri May 12 09:52:13 CEST 2023] Sleep 10 and retry.
2023-05-12T09:52:13   acme.sh   [Fri May 12 09:52:13 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:52:13   acme.sh   [Fri May 12 09:52:13 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 7
2023-05-12T09:51:57   acme.sh   [Fri May 12 09:51:57 CEST 2023] Can not init api, for https://acme-v02.api.letsencrypt.org/directory
2023-05-12T09:51:48   acme.sh   [Fri May 12 09:51:48 CEST 2023] Sleep 10 and retry.
2023-05-12T09:51:48   acme.sh   [Fri May 12 09:51:48 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T09:51:48   acme.sh   [Fri May 12 09:51:48 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6

Then we googled and found the topic which is linked above.

Interesting fact: From the time on when WAN droped, we were able to ping all assigned virtual IP addresses which are located on lo1. At this time, we had no allow rules on our WAN interface configured.



We then checked our ACME and network configuration again for possible errors and changed log level to debug 3.

This is how we configured the challange type:
HTTP-01
OPNsense Web Service (automatic port forward)
IP Auto-Discovery disabled
Selectected Interface lo1
Entered public IP Adress from lo1 like 12.13.14.8

We have several virtual IPs configured on the lo1 interface, like 12.13.14.1 , .2, .3 , ... ,  .8. 

We also added a [WAN] interface rule like: pass if destionation is 12.13.14.0/24.



We retried to get a certificate again which resulted in instant WAN drop while ACME processed the certifcate request. This is the debug level 3 log:

2023-05-12T10:39:59   opnsense   AcmeClient: validation for certificate failed: our.doma.in
2023-05-12T10:39:59   opnsense   AcmeClient: domain validation failed (http01)
2023-05-12T10:33:34   opnsense   AcmeClient: running acme.sh command: /usr/local/sbin/acme.sh --issue --syslog 7 --debug 3 --server 'letsencrypt' --webroot /var/etc/acme-client/challenges --home '/var/etc/acme-client/home' --certpath '/var/etc/acme-client/certs/645de8720875b0.48773709/cert.pem' --keypath '/var/etc/acme-client/keys/645de8720875b0.48773709/private.key' --capath '/var/etc/acme-client/certs/645de8720875b0.48773709/chain.pem' --fullchainpath '/var/etc/acme-client/certs/645de8720875b0.48773709/fullchain.pem' --domain 'our.doma.in' --days '1' --force --keylength '4096' --accountconf '/var/etc/acme-client/accounts/63e3bf5e907b14.68160882_prod/account.conf'
2023-05-12T10:33:34   opnsense   AcmeClient: using challenge type: HTTP-01 über HAProxy HTTP Frontend Integration
2023-05-12T10:33:34   opnsense   AcmeClient: using IPv4 address: 12.13.14.1
2023-05-12T10:33:34   opnsense   AcmeClient: using IPv4 address: 12.13.14.8
2023-05-12T10:33:19   opnsense   AcmeClient: account is registered: LE Default Certificates
2023-05-12T10:33:19   opnsense   AcmeClient: using CA: letsencrypt
2023-05-12T10:33:19   opnsense   AcmeClient: issue certificate: our.doma.in
2023-05-12T10:33:19   opnsense   AcmeClient: certificate must be issued/renewed: our.doma.in

Interesting fact: Two IPs are listed here, but we configured only the .8 address in the challange and Auto discovery was disabled.

2023-05-12T10:39:59   acme.sh   [Fri May 12 10:39:59 CEST 2023] Can not init api, for https://acme-v02.api.letsencrypt.org/directory
2023-05-12T10:39:49   acme.sh   [Fri May 12 10:39:49 CEST 2023] Sleep 10 and retry.
2023-05-12T10:39:49   acme.sh   [Fri May 12 10:39:49 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:39:49   acme.sh   [Fri May 12 10:39:49 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:39:49   acme.sh   [Fri May 12 10:39:49 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:39:49   acme.sh   [Fri May 12 10:39:49 CEST 2023] Here is the curl dump log:
2023-05-12T10:39:49   acme.sh   [Fri May 12 10:39:49 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:39:19   acme.sh   [Fri May 12 10:39:19 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.ZOe0pd0E '
2023-05-12T10:39:19   acme.sh   [Fri May 12 10:39:19 CEST 2023] timeout=
2023-05-12T10:39:19   acme.sh   [Fri May 12 10:39:19 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:39:19   acme.sh   [Fri May 12 10:39:19 CEST 2023] GET
2023-05-12T10:39:09   acme.sh   [Fri May 12 10:39:09 CEST 2023] Sleep 10 and retry.
2023-05-12T10:39:09   acme.sh   [Fri May 12 10:39:09 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:39:09   acme.sh   [Fri May 12 10:39:09 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:39:09   acme.sh   [Fri May 12 10:39:09 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:39:09   acme.sh   [Fri May 12 10:39:09 CEST 2023] Here is the curl dump log:
2023-05-12T10:39:09   acme.sh   [Fri May 12 10:39:09 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:38:39   acme.sh   [Fri May 12 10:38:39 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.sebWVlBB '
2023-05-12T10:38:39   acme.sh   [Fri May 12 10:38:39 CEST 2023] timeout=
2023-05-12T10:38:39   acme.sh   [Fri May 12 10:38:39 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:38:39   acme.sh   [Fri May 12 10:38:39 CEST 2023] GET
2023-05-12T10:38:29   acme.sh   [Fri May 12 10:38:29 CEST 2023] Sleep 10 and retry.
2023-05-12T10:38:29   acme.sh   [Fri May 12 10:38:29 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:38:29   acme.sh   [Fri May 12 10:38:29 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:38:29   acme.sh   [Fri May 12 10:38:29 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:38:29   acme.sh   [Fri May 12 10:38:29 CEST 2023] Here is the curl dump log:
2023-05-12T10:38:29   acme.sh   [Fri May 12 10:38:29 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:37:59   acme.sh   [Fri May 12 10:37:59 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.W8SLTSIf '
2023-05-12T10:37:59   acme.sh   [Fri May 12 10:37:59 CEST 2023] timeout=
2023-05-12T10:37:59   acme.sh   [Fri May 12 10:37:59 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:37:59   acme.sh   [Fri May 12 10:37:59 CEST 2023] GET
2023-05-12T10:37:49   acme.sh   [Fri May 12 10:37:49 CEST 2023] Sleep 10 and retry.
2023-05-12T10:37:49   acme.sh   [Fri May 12 10:37:49 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:37:49   acme.sh   [Fri May 12 10:37:49 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:37:49   acme.sh   [Fri May 12 10:37:49 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:37:49   acme.sh   [Fri May 12 10:37:49 CEST 2023] Here is the curl dump log:
2023-05-12T10:37:49   acme.sh   [Fri May 12 10:37:49 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:37:19   acme.sh   [Fri May 12 10:37:19 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.zsdGEiVz '
2023-05-12T10:37:19   acme.sh   [Fri May 12 10:37:19 CEST 2023] timeout=
2023-05-12T10:37:19   acme.sh   [Fri May 12 10:37:19 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:37:19   acme.sh   [Fri May 12 10:37:19 CEST 2023] GET
2023-05-12T10:37:09   acme.sh   [Fri May 12 10:37:09 CEST 2023] Sleep 10 and retry.
2023-05-12T10:37:09   acme.sh   [Fri May 12 10:37:09 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:37:09   acme.sh   [Fri May 12 10:37:09 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:37:09   acme.sh   [Fri May 12 10:37:09 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:37:09   acme.sh   [Fri May 12 10:37:09 CEST 2023] Here is the curl dump log:
2023-05-12T10:37:09   acme.sh   [Fri May 12 10:37:09 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:36:39   acme.sh   [Fri May 12 10:36:39 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.plaKhpv3 '
2023-05-12T10:36:38   acme.sh   [Fri May 12 10:36:38 CEST 2023] timeout=
2023-05-12T10:36:38   acme.sh   [Fri May 12 10:36:38 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:36:38   acme.sh   [Fri May 12 10:36:38 CEST 2023] GET
2023-05-12T10:36:28   acme.sh   [Fri May 12 10:36:28 CEST 2023] Sleep 10 and retry.
2023-05-12T10:36:28   acme.sh   [Fri May 12 10:36:28 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:36:28   acme.sh   [Fri May 12 10:36:28 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:36:28   acme.sh   [Fri May 12 10:36:28 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:36:28   acme.sh   [Fri May 12 10:36:28 CEST 2023] Here is the curl dump log:
2023-05-12T10:36:28   acme.sh   [Fri May 12 10:36:28 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:35:58   acme.sh   [Fri May 12 10:35:58 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.ePT0zlfC '
2023-05-12T10:35:58   acme.sh   [Fri May 12 10:35:58 CEST 2023] timeout=
2023-05-12T10:35:58   acme.sh   [Fri May 12 10:35:58 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:35:58   acme.sh   [Fri May 12 10:35:58 CEST 2023] GET
2023-05-12T10:35:48   acme.sh   [Fri May 12 10:35:48 CEST 2023] Sleep 10 and retry.
2023-05-12T10:35:48   acme.sh   [Fri May 12 10:35:48 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:35:48   acme.sh   [Fri May 12 10:35:48 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:35:48   acme.sh   [Fri May 12 10:35:48 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:35:48   acme.sh   [Fri May 12 10:35:48 CEST 2023] Here is the curl dump log:
2023-05-12T10:35:48   acme.sh   [Fri May 12 10:35:48 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:35:18   acme.sh   [Fri May 12 10:35:18 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.VzIvoEDc '
2023-05-12T10:35:18   acme.sh   [Fri May 12 10:35:18 CEST 2023] timeout=
2023-05-12T10:35:18   acme.sh   [Fri May 12 10:35:18 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:35:18   acme.sh   [Fri May 12 10:35:18 CEST 2023] GET
2023-05-12T10:35:08   acme.sh   [Fri May 12 10:35:08 CEST 2023] Sleep 10 and retry.
2023-05-12T10:35:08   acme.sh   [Fri May 12 10:35:08 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:35:08   acme.sh   [Fri May 12 10:35:08 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:35:08   acme.sh   [Fri May 12 10:35:08 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:35:08   acme.sh   [Fri May 12 10:35:08 CEST 2023] Here is the curl dump log:
2023-05-12T10:35:08   acme.sh   [Fri May 12 10:35:08 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:34:38   acme.sh   [Fri May 12 10:34:38 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.ElCDCtjf '
2023-05-12T10:34:38   acme.sh   [Fri May 12 10:34:38 CEST 2023] timeout=
2023-05-12T10:34:38   acme.sh   [Fri May 12 10:34:38 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:34:38   acme.sh   [Fri May 12 10:34:38 CEST 2023] GET
2023-05-12T10:34:28   acme.sh   [Fri May 12 10:34:28 CEST 2023] Sleep 10 and retry.
2023-05-12T10:34:28   acme.sh   [Fri May 12 10:34:28 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:34:28   acme.sh   [Fri May 12 10:34:28 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:34:28   acme.sh   [Fri May 12 10:34:28 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:34:28   acme.sh   [Fri May 12 10:34:28 CEST 2023] Here is the curl dump log:
2023-05-12T10:34:28   acme.sh   [Fri May 12 10:34:28 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:34:04   acme.sh   [Fri May 12 10:34:04 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.85ROWRlU '
2023-05-12T10:34:04   acme.sh   [Fri May 12 10:34:04 CEST 2023] timeout=
2023-05-12T10:34:04   acme.sh   [Fri May 12 10:34:04 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:34:04   acme.sh   [Fri May 12 10:34:04 CEST 2023] GET
2023-05-12T10:33:54   acme.sh   [Fri May 12 10:33:54 CEST 2023] Sleep 10 and retry.
2023-05-12T10:33:54   acme.sh   [Fri May 12 10:33:54 CEST 2023] Can not init api for: https://acme-v02.api.letsencrypt.org/directory.
2023-05-12T10:33:54   acme.sh   [Fri May 12 10:33:54 CEST 2023] ret='6'
       == Info: Closing connection 0
2023-05-12T10:33:54   acme.sh   [Fri May 12 10:33:54 CEST 2023] == Info: Could not resolve host: acme-v02.api.letsencrypt.org
2023-05-12T10:33:54   acme.sh   [Fri May 12 10:33:54 CEST 2023] Here is the curl dump log:
2023-05-12T10:33:54   acme.sh   [Fri May 12 10:33:54 CEST 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.GIECsytR '
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] timeout=
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] url='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] GET
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] _init api for server: https://acme-v02.api.letsencrypt.org/directory
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] Using ACME_DIRECTORY: https://acme-v02.api.letsencrypt.org/directory
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] DOMAIN_PATH='/var/etc/acme-client/home/our.doma.in'
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] Using config home:/var/etc/acme-client/home
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] _alt_domains='no'
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] _main_domain='our.doma.in'
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] Running cmd: issue
2023-05-12T10:33:34   acme.sh   [Fri May 12 10:33:34 CEST 2023] Using server: https://acme-v02.api.letsencrypt.org/directory

Any ideas?

Hallo zusammen,

wir würden gerne MagentaTV über eine Site 2 Site VPN-Konfig sharen. Kann man IGMP über VPN tunneln?

Aktuell ist eine OPNsense (Site 1) mit einer Fritzbox 7490 (Site 2) per Site 2 Site config über Wireguard verbunden.  Falls die Fritte das nicht kann, wäre es auch kein Problem noch ne Sense daneben zu stellen. Aber ich frag mich eher, ob es die Sense oder Wireguard grundsätzlich könnten?

Folgende Stolpersteinge gibts dann noch zu bearchten:
- Die Sense von Site 1 läuft virtualisiert in einem VMware ESXi. Ich bin mir nicht sicher ob der vSwitch das kann.
- Auf Site 2 hängen alle Clients direkt an der Fritte und können deshalb Magentatv ohne Probleme nutzen. Auf Site 2 sind zwischen dem ESXi-Host auf dem die Sense läuft und dem Client auf dem MagentaTV genutzt werden soll zwei Switche* kaskadiert.

Die Wireguardkonfig zwischen Sense und Fritte läuft soweit. Mein erster Testaufbau sieht so aus:

Hab auf Site 1 den IGMP Proxy so eingerichtet, dass als Upstreaminterface das Wireguard-Interface angegeben wird und als Downstreaminterface das LAN-Interface, in dem der MagentaTV-Client (VLC mit entsprechender RDP-Playlist). Geht leider nicht.

* Linksys SRW2016 SWR2016 kann IGMP v1 und v2; Beim TP-LINK SG105 steht leider nur IGMP Snooping ohne IGMP-Version im Datenblatt. Es heißt zwar hier und da, dass MagentaTV zwingend mit v3 arbeiten würde, aber an einigen Stellen ist auch zu lesen, das Paketanalysen gezeigt haben, dass doch nur v2 genutzt wird. Das ergibt auch Sinn, denn angeblich soll ja das IGMP Proxy Plugin auch nur v2 können. Einige Leute haben das Plugin ja erfolgreich in Nutzung.


Weiß jemand Rat, wie man diese Nuss knacken kann?

Bei Site 2 nen Mediaserver hinstellen, der MagentaTV von Multicast in Unicast umwandelt wäre natürlich auch ein Ansatz. Nach Möglichkeit würd ichs aber gern auf Netzwerkerbene lösen.

Danke für die Unterstützung.

Hey all,

my old 16x 1G SRW2016 Linksys switch is driving me nuts, because there is no CLI and the WebUI can only be opend with <=IE8 on WinXP (i have a WinXP-VM to manage this switch). I decided to upgrade to 10G, but i dont know what to do.

Upgrading to a 10G Switch would be a safe bank. But i also could install a 4x 10G PCIe-card in my OPNsense (which is virtualized and running on a Ryzen 4750G). I also have 2x 10GbE (Intel X550-AT2) and (2x 1GbE Intel i210) onboard, so there would be enough ports in this machine to connect all needed devices.

Does anyone have experience running the OPNsense as a switch?

I mean, it should be possible to bridge phys NIC interfaces and let them act like a single broadcast domain.

But will it work reliable? And is there some kind of hardware (depending on used NIC of course) offload support or would all traffic flow over the CPU even if its only Layer2 traffic in a broadcast domain?

Thanks for sharing your experiences.

Hi,

Does anyone have experience with Marvell AQtion Ethernet Controller?
Do these work with OPNsense/Free BSD without limitations (VLAN, Speed/Autosense, etc.)?

I have an older Intel NUC and  would like to upgrade the NUC with one of these NICs, because NUCs only have 1x 1G:

https://www.innodisk.com/en/products/embedded-peripheral/communication/egpl-t101

https://www.tomshardware.com/news/innodisk-m2-2280-10gbe-adapter

[interfaces: allow user-configurable VLAN device names with certain restrictions]

Moin,

seit 22.7.6 gibts folgende Änderung laut Changelog:

interfaces: allow user-configurable VLAN device names with certain restrictions

Hier das Issue in github: https://github.com/opnsense/core/issues/6038

Im Hilfetext steht:
Leave empty to generate a device name. Custom names are possible, but only if the start of the name matches the required prefix and contains numeric characters or dots, e.g. "vlan0.1.2" or "qinq0.3.4".


Ich entnehme daraus, dass  ein VLAN-Device dann immer mit vlan beginnen muss, dahinter können Zahlen folgen. Gleiches analog für QinQ. Dahinter dürfen dann nur Zahlen und Punkte folgen.

Nun hab ich da ein bisschen rumprobiert. Einfach nur vlan mit beliebiger Systematik an Zahlen und Punkten hinten dran scheint nicht zu gehen und führt zu folgender Fehlermeldung:


Only a maximum of 15 characters is allowed starting with "vlan0" combined with numeric characters and dots, e.g. "vlan0.1.104".

Welcher Regel nach bzw. Syntax entsprechend sind die Zahlen und Punkte anzuordnen? Das ist irgendwie nicht so ganz einleuchtend.

Bezogen auf die Beispiele im Hilfetext und der Fehlermeldung:
Was bedeutet die führende 0? Ist das der Adaptertyp? (z.B. vmx)
Ist die Zweite Zahl die Interface-Nummer des entsprechenden Adaptertyps?
Die letzte Zahl ist das VLAN-Interface?

Welchen Spielraum lässt die Syntax?

Hallo zusammen,

ich nutze die aktuelle OPNsense 22.7.4 und wollte mal anfangen, nicht nur für den haproxy saubere Zertikate zu nutzen, sondern auch meine internen Server und Dienste mit LE-Zertifikate zu betanken.

Ich hab mit der ACME-Automation versucht, Zertifikate auf meinen ESXi und einen OmniOS Server zu bekommen. Bin jedoch in beiden Fällen gescheitert.

Das Fehlerbild sieht dann immer so aus, wie im Anhang zu sehen.

Beide Systeme nutzen den SSHD, auf dem ESXi ist er Linuxbasiert, auf OmniOS halt eher Unixbasiert, aber die Konfigfiles sind auf beiden Systemen gleich aufgebaut.

SSH über putty oder so mit User/Pass geht ohne Probleme, aber Dateibasiert wie es der Automatismus der Sense macht, will einfach nicht klappen.

Die ACME-Automation wirft im Log immer diesen Fehler:

/usr/local/opnsense/scripts/OPNsense/AcmeClient/upload_sftp.php: Command execution failed, exit code 1.


Jemand ne Idee, was ich falsch mache?

Wir ziehen gerade ein mandantenfähiges Datacenter-Netzwerk hoch. Räumlich steht das DC auf einem Campus, auf dem auch die Accessswitches ausgerollt werden. Es gibt keine WAN-strecken in dem Sinne, alle Accessswitches auf dem Gelände hängen mit direktem Uplink am Datacenter.

Die Umgebung wird vollständig mit SDDC und SDDN betrieben.

Das SDDC wird mit VMware vSphere 7, vSAN Enterprise und VMwarae NSX-T 3.2 Enterprise Plus realisiert.

Die Switche im DC sind Dell S5248F-ON mit Dell OS 10. Die Switche im Accessbereich sind Dell N3248PXE-ON. Aktuell noch mit Dell OS 6 (OS6 kann kein VXLAN, die Hardware der Switche aber schon) aber wir sind aktuell dabei PICOS zu prüfen, damit wir EVPN bis zu den Accessswitches ausrollen können.

Für das EVPN kommt OSPF oder BGP im underlay fürs Overlay VXLAN  mit MP-BGP zum Einsatz.

Das Routing/Firewalling zwischen den Tenants werden wir wenn möglich zentral in NSX-T machen. Wir wollen also keine VRFs auf den Switches betreiben. Wir sind uns aber noch nicht ganz sicher, ob die Routing/Firewalling-Leistung und die Handhabbarkeit von NSX-T-Edges für diesen Anwendungsfall ausreichen.

Wenn ich das richtig sehe, scheint FRR EVPN mit MP-BGP ja grundsätzlich zu können:
https://docs.frrouting.org/en/latest/bgp.html

Wir würden in der Umgebung gerne auch OPNsense-Router betreiben, die dann direkt ans EVPN angeschlossen werden.

Hat schon mal jemand OPNsense in Verbindung mit EVPN-Netzen eingesetzt? Falls ja, wie sind die Erfahrungen?

Hat die Business Edition spezielle Erweiterungen / Features im repo für diesen Anwendungsfall?

Hallo zusammen,

wir haben ein öffentliches /24er IPv4-Netz. Als Adresse nehmen wir 192.192.192.0/24 an. Dieser Adressblock wird von Router 1 an unsere OPNsense mit der IP 10.1.0.2 geroutet.

Auf der OPNsense wollen wir nun die public IPs verwalten und je nach Bedarf über HA-Proxy oder Portforwardings an entsprechende Dienste in diversen DMZs/lokalen Netzen weiterleiten.

Um die öffentlichen IPs auf der sense zu verwalten, haben wir ein Loopback-Interface angelegt (lo1), dieses aktiviert und ihm die IP 192.192.192.1/32 als Virtual IP gegeben. Diese IP ist auch aus dem Netz erreichbar, wenn man auf dem Transfernetz eine entsprechende Allow-Regel anlegt.

Weil wir mehrere Tenants haben werden, würden wir jedem Tenant gerne zukünftig ein eigenes Loopback-Interface mit jeweils eigener öffentlicher IP zuweisen, also lo2 = 192.192.192.2/32, lo3 = 192.192.192.3/32 usw.. Die Überlegung dahinter ist, dass es übersichtlicher ist, wenn jedes Tenant sein eigenes Interface hat, weil dann die Regeln nicht alle auf einem Interface erstellt werden.


Hier der Plan dazu:

      WAN / Internet
            :
            :
      .-----+-----.
      |  Router1 |
      '-----+-----'
            |.1
            |
        Transfernetz 10.1.0.0/24
            |
            |.2
      .-----+----------------------------------------------------------------.
      |  OPNsense                                                  |         lo1          | -Virtuelle IP 192.192.192.1
      '-----+----------------------------------------------------------------'
            | .1                                |.1                    |         lo2          | -Virtuelle IP 192.192.192.2
            |                                    |                       -------------------'
            |                                    |
   DMZ1 | 10.2.0.1/24        DMZ1 | 10.3.0.0/24   




Wenn wir wie oben angedeutet auf dem Interface 10.1.0.2 Regeln anlegen, die den Zugriff aus dem Internet zu den Public IPs regeln dann klappt es ohne Probleme, den Zugriff auf die Public IPs zu reglementieren.

Unser Problem ist, dass die Regelwerke, die wir auf den Loobackinterfaces definieren nicht greifen.

Wenn man die Regelwerke auf den Loopback-Interface anlegen will, wie müsste dann die Regeln aussehen, wenn z.B. HTTP/HTTPS-Traffic aus dem Internet erlaubt werden soll?


Vielen Dank für die Hilfestellung.

Hallo zusammen,

wie siehts denn mit WiFi im Jahr 2022 aus, seitdem FreeBSD 13 unter OPNsense läuft?

Ich kann mich noch dran erinnern, dass 802.11G eine Zeit lang das höchste der Gefühle war und auch nicht unbedingt sauber lief. Dann gabs irgendwann mal 802.11N support, aber mehr als 802.11G-Geschwindigkeit war in der Regel nicht drin (oder so ähnlich).

So gut wie alle Empfehlungen, die man so findet, stammen noch aus Zeiten, als noch kein FreeBSD13 unter der OPNsense lief.

Ist WiFi mittlerweile ausgereift? Und geht auch 802.11AC oder AX mit ordentlichen Geschwindigkeiten?

Wie sind da eure Erfahrungen?

[Punkt 1 (Tunneling von VLANs / QinQ)]

Hallo zusammen,

ich versuche gerade VXLAN in der OPNsense zu verstehen. Die Doku hilft da aktuell leider nicht weiter, das Forum ist da auch noch nicht sonderlich hilfreich.

Punkt 1 (Tunneling von VLANs / QinQ)

VXLAN heißt, Layer2 über ein Layer 3 Netz tunneln zu können.  Die Tunnelendpunkte (TEPs) können Point to Point- (Unicast) oder Point to Multipoint-Verbindungen (Multicast) aufbauen.

Eine Tunnelendpunkt kann 16.777.215 VNIs (VXLAN Network Identifiers) unterscheiden. Jedes VNI bildet dabei ein eigenes Layer2-Netz. Und in jedes VNI können vollwertige Layer2 Frames gekapselt und an einen anderen TEP geschickt geschickt werden.

Daraus folgt:

Jedes VNI kann untagged Frames transportieren, aber auch genauso gut VLAN-getaggte Frames und auch QinQ-getaggte Frames. Theoretisch wären so 16.777.215 (VNI) * 4094 (Outer Q) * 4094 (Inner Q) unabhängige Layer 2-Netze mit nur einem VXLAN-Netzwerk tunnelbar.

Nun lassen aber viele Netzwerkgeräte nur zu, durch ein VNI ungetaggte Layer 2 Frames zu schicken. Bei solchen Geräten kann man dann immer nur ein VLAN je VNI übertragen. Es wird also bspw. auf Switch A VLAN 100 ungetagged in den TEP mit der VNI 100 geschickt. Auf Switch B kommt dann VNI 100 an und wird dort in ein VLAN ausgekapselt. Auf Switch B muss VNI 100 aber nicht zwingend auf VLAN 100 ausgekapselt werden, man kann es auch z.B. auf VLAN 111 auskapseln.

Der Nachteil dieses Vorgehens ist, dass man für jedes VLAN ein eigenes VNI konfigurieren muss. Der Aufwand dafür ist ggf. recht groß.

Manche Netzwerkgeräte lassen es aber auch zu, dass man VLAN oder QinQ getaggte Frames durch den VNI schicken kann. Somit braucht man nur noch ein VNI konfigurieren, über das man dann 4094 VLANs schicken kann oder eben bei Einsatz von QinQ 4094x4094 VLANs.

Ich hab noch nicht so richtig raus, was die OPNsense kann. Ist beides möglich? Wenn ja, wie? Wenn nein, was ist möglich?

Punkt 2 (untagged, VLAN oder QinQ-Interface an VXLAN binden)

Ein VXLAN-Interface mit einem VNI anzulegen scheint mir jetzt nicht so die Hürde zu sein. Das ist unter Interfaces - Other Types - VXLAN schnell gemacht. Das VXLAN-Interface ist nach der Erstellung verüfgbar um assigned zu werden.

Ich bin mir aber noch nicht sicher, wie ich nun ein Layer2-Netz an ein VNI binde. Verbinde ich ein untagged- / VLAN- / QinQ-Device per Bridging auf das VXLAN device oder wie geht man vor? Und muss man das VLAN/QinQ Device speziell konfigurieren, dass es Layer2-Taffic aufnimmt und an den Tunnel weiter reicht?

Punkt 3 (Standard?)

Hält sich das VXLAN in der OPNsense an RFC7348? Kann ich die OPNsense mit jedem VXLAN-fähigen Netzwerkgerät (Switch, Router, Hypervisor, Server) verbinden welches RFC7348-konform ist? Oder gibts hier irgendwelche Einschränkungen?


Vielen Dank für die Aufklärung.