Messages

I upgraded two instances (libressl) last week from 21.7.4 to 21.7.5 and both of them rebooted fine even if it took a long time until all services were shutdown. Today I searched for updates again got 21.7.5_2 presented without any further notice. After installation the machine rebooted immediately. Luckily it happened in our maintenance timeframe but I was quite surprised seeing the machine rebooting without warning.

Yes, it's correct. You are assigning networks, consisting of 1 network address, 2 routed IP and 1 broadcast address.

It works!  ;D

Thanks for your helpful hint! I just managed to run the OVPN connection, do a NAT for outgoing requests and tunnel this connection via ssh over our ipsec VPN to our office. Now we all can reach the remote host from our office PCs. 3 weeks of trial and error and this way it works.  8)

[all]

To make this work you have to setup a new interface in Interfaces->Assignment using ovpnc2 as "Network port".
After that you should be able to configure NAT in Firewall->NAT->Outbound for this newly generated interface.

:o sounds complicated. I'll try that.

We solved this several months ago with a quick and dirty patch enabling outgoing IPv4 and IPv6 NAT for all OpenVPN Client connections, which is not the correct way to do this :)

How did you do this? Currently we just have one client but there might come more and handling separate interfaces and NAT rules for each of them might become confusing by time.

Hi,

I imported an OpenVPN client connection on my OPNSense (21.1.6) and got it already up and running. I can ping hosts on remote site and successful ssh to a host on remote site from OPNsense terminal. But I cannot reach any remote host from other hosts in my LAN. Even if i do a ping from OPNsense to remote host with source address set to LAN address of my OPNSense I get no answer.
This is what it looks like:


  .-------------.   .----------------.                  .--------------.
  |   OVPN IP   |   |    OVPN NET    |   .--------.     |  Dest Host   |
  |--------------------------------------- TUNNEL ---------------------|
  | 10.112.63.9 |   | 10.112.63.0/24 |   '--------'     | 10.112.62.54 |
  '-------------'   '----------------'                  '--------------'

  .------------------.   X
  | OPNsense IP/Mask |  /
  |--------------------'
  | 172.22.0.150/24  |
  '------------------'


There is a routing entry set up on OPNsense for 10.112.62.54 and when enabling the client there is a new interface called ovpnc2 which is used for routing. Hosts in my LAN have routing entries for 10.112.62.54 pointing to 172.22.0.150. Pakets reach OPNsense but are not transmitted to tunnel.

My firewall has an entry for allowing all traffic from LAN to OVPN connection, set up in OpenVPN.

When inspecting traffic with tcpdump I see that connections coming from OPNsense itself are using 10.112.63.9 as source address. Changing this to LAN address breaks communication. So I guess I need to do NAT but I don't know where and how. I think that this should be enabled by default. Or at least by some setting in client configuration.

How is such scenario supposed to be setup?

Yesterday morning I upgraded one of my opnsenses from 21.7.1 to 21.7.2 and some minutes later to 21.7.2_1. No issues while upgrading or rebooting after upgrade to 21.7.2. Upgrade / Patch 21.7.2_1 triggered no more reboot. And redis is installed, but not ntopng:

os-acme-client (installed)
os-firewall (installed)
os-netdata (installed)
os-nginx (installed)
os-postfix (installed)
os-qemu-guest-agent (installed)
os-redis (installed)
os-theme-cicada (installed)
os-theme-rebellion (installed)
os-theme-tukan (installed)
os-theme-vicuna (installed)

Hallo hsiewert,

danke für den Hinweis, aber damit kann ich nur die gesamten DHCP Einstellungen synchronisieren, was ich aber nicht will. Denn die "globalen" Daten wie default route bzw classless-static-routes sind unterschiedlich und müssen es auch bleiben. Ich will nur die statischen Einträge synchronisieren.

Leider habe ich noch nicht herausfinden können, wo die Daten gespeichert werden. Da muss ich vermutlich doch mal in den Code bzw eine technische Beschreibung der DHCP Implementierung in OPNsense schauen.

Hallo,

ich bin aktuell auf der Suche nach einer einfachen Möglichkeit, die statischen Host-Einträge im DHCPv4 von einer OPNsense auf eine andere zu syncen. Der Sync soll nur in eine Richtung laufen und bestehende Einträge auf dem Zielsystem unverändert lassen. Alternativ kann auch der gesamte Bestand 1:1 übernommen werden, dann würde ich die wenigen Einträge des Zielsystems vorher ebenfalls auf dem Quellsystem anlegen.

Gesehen habe ich die Konfigdatei /var/dhcpd/etc/dhcpd.conf, die jedoch nicht die Quelle der Einträge ist, sondern selbst nur aus einer Datenbasis generiert wird. Allerdings finde ich die eigentliche Datenquelle nicht. Also wo die Einträge, die ich im WebUI sehe, tatsächlich gespeichert sind. Denn in der generierten Konfig stehen bspw nicht die Namen, die ich den Einträgen im Feld Description gegeben habe.

Kann mir hier jemand auf die Sprünge helfen?
Danke!

Ich nutze in 21.7.1 den DHCPv4 und sehe dort im Eintrag Leases die statischen leases aufgelistet. Rechts in der Spalte "Status" sehe ich ein Symbol, ob der Host online ist (bzw sich die DHCP Daten kürzlich geholt hat) oder nicht. In letzterem Fall ist ein durchgestrichener Kreis angezeigt, ähnlich wie ein Parkverbot.
Ist es das was du suchst?

Just to confirm that firefox behaves the same way as chrome (didn't see any mention of FF yet). While upgrading from 21.1.6-amd64 to 21.1.7_1-amd64 the output stopped while unpacking firmware. After a while I reloaded the page an got login page as opnsense meanwhile finished upgrade and rebooted.

As far as I can tell all pages display correctly except for upgrade and security check, which I tested. Even forced reload of the tab didn't work (<ctrl><shift><r>) and standard reload of course neither. After clearing the cache everything was fine again. I can search for updates and run security check again.

(sorry if it is obvious) - do your clients support option 33?

Is it optional? In fact, I really didn't think about that.  :-\
I will have a look.

Hi there,

we are currently preparing a migration of our servers from old cluster to new cluster. All settings will be left untouched so we are having the sam LAN on both clusters. The connection between the clusters is done via another network:

Code Select Expand


  .---------------.                    .---------------.
  |   Cluster A   |                    |   Cluster B   |
  | 172.22.0.0/16 |                    | 172.22.0.0/16 |
  '-------.-------'                    '-------.-------'
          |                                    |
          |                                    |
   .------'-------.                    .-------'------.
   |  Gateway A   |   172.23.1.0/24    |  Gateway B   |
   | 172.22.4.240 |--------------------| 172.22.4.250 |
   | 172.23.1.240 |                    | 172.23.1.250 |
   '--------------'                    '--------------'


Now I want to do the following: For each Host that is migrated to the new cluster I want to spread a static route in the old cluster to all hosts. This static route will route all traffic to that migrated host via a dedicated gateway.
The result should look like this:

default via 172.22.0.152 dev ens18 proto dhcp src 172.22.240.60 metric 100
172.22.0.0/16 dev ens18 proto kernel scope link src 172.22.240.60
172.22.0.0/16 via 172.22.4.250 dev ens18 proto dhcp src 172.22.240.60 metric 100
172.22.0.152 dev ens18 proto dhcp scope link src 172.22.240.60 metric 100
172.22.10.205 via 172.22.4.250 dev ens18

For spreading static routes the DHCP standard implements option 33 where I can concatenate pairs of destination and gateway. (THX to BertM for his HowTo on classless static routing)

BUT:

When adding some pairs in DHCPv4 -> Additional Options as number 33 of type string, the receiving host (dhclient) will take one of the entries as default gateway and all other static routes are lost:

default via 172.22.0.150 dev ens18
172.22.0.0/16 dev ens18 proto kernel scope link src 172.22.240.60

The host 172.22.0.150 is the standard gateway for some hosts on the other cluster. I know, I could just assign an additional IP to the gateway 172.22.0.152, so it will reply to packets, but I also need to reach the real 0.152 as there are also VPN tunnels. And after all, there are no more static routes assigned to the host even there are many of them defined.

The entry for option 33 is this:

Code Select Expand


AC:16:00:64:AC:16:04:FA:AC:16:00:96:AC:16:04:FA:AC:16:00:97:AC:16:04:FA:AC:16:04:F0:AC:16:04:FA:AC:16:0A:CD:AC:16:04:FA:AC:16:0B:0A:AC:16:04:FA:AC:16:0B:0B:AC:16:04:FA:AC:16:0B:0C:AC:16:04:FA:AC:16:0B:0D:AC:16:04:FA

In human readable form this is the list of ip adresses, each followed by 172.22.4.250 as gateway:

172.22.0.100
172.22.0.150
172.22.0.151
172.22.2.70
172.22.4.240
172.22.10.205
172.22.11.10
172.22.11.11
172.22.11.12
172.22.11.13

Can anyone point me to the failure I've made? I need to do this or similar setting on both clusters as traffic has be routed between them in both directions until the migration is done.

[kein]

Vorsicht, Stolperfalle: Optional sollte die Prüfung nur sein, wenn tatsächlich in einem nachgelagerten Schritt das Zertifikat dann geprüft wird. Falls diese Prüfung nicht erfolgt, gibt es dieses auf den ersten Blick unsinnige Verhalten:
Wenn du ein Zertifikat hast, das zu dem hinterlegten Serverzertifikat passt, dann muss es auch gültig sein, damit du zugreifen darfst.
Wenn du kein Zertifikat hast, dann darfst du sofort zugreifen!

Gib doch bitte nochmal deine jetzige Konfig an, denn ich vermute, dass du möglicherweise etwas zu kompliziert rangegangen ist. Ich hatte dich so verstanden, dass du eine eigene Domain für dein Nextcloud nutzt, damit kannst du die Prüfung doch direkt im Public Service erledigen, ohne mit weiteren Conditions arbeiten zu müssen. Denn das macht die Konfig nur unnötig komplex und fehleranfällig.

Gepriesen sei dein Arbeitgeber!  ;D

OK, du musst trennen zwischen dem Serverzertifikat, mit dem der Server sich dem Client gegenüber ausweist (TLS Verbindung) und dem Zertifikat, das der Server nutzt um das eingereichte Clientzertifikat zu prüfen (Client Authentifizierung). Das KÖNNEN serverseitig die gleichen Zertifikate sein, müssen es aber nicht.

Also im Klartext: Der Server weist sich für den Aufbau der TLS Verbindung mit einem Lets Encrypt Zertifikat dem Client gegenüber aus. Dafür muss die Domain im Zertifikat enthalten sein, sonst gibt der Client (meistens also der Browser) eine Warnung aus. Dann steht die TLS Verbindung und der Server fragt den Client im nächsten Schritt nach einem Zertifikat, das den Client berechtigt, die aufgerufene Seite zu sehen. Dafür verwaltet der Server ein oder mehrere weitere Zertifikate, die an dieser Stelle nichts mit TLS zu tun haben.

Du hast auch zwei Stellen in der haproxy Konfig wo du diese Zertifikate auswählst. Einmal beim TLS Offloading, da wählst du das Serverzertifikat für die TLS Verbindung. Und im Bereich Client Authentication wählst du das Zertifikat, mit dem du dein Clientzertifikat signiert hast.