Topics

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?

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!

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.

Moin zusammen,

ich brauch mal einen Schubser in die richtige Richtung. Das ist nicht direkt Opnsense spezifisch, eher ein allgemeines Routingproblem. Und in Netzwerkangelegenheiten tue ich mich manchmal etwas schwer. Folgendes Setup kriege ich nicht zum laufen:

Code Select Expand


  .............      .-------.  .-------.  .-------.  .-------.
  . Cluster I .      | 10.50 |  | 10.51 |  | 10.53 |  | 10.55 |
  .............      '-------'  '-------'  '-------'  '-------'
                                    /
    opnsense 1  -------------------'
   __________   
  [_...__...°] 
                          .-,(  ),-.   
       ----------------.-(          )-.
                      ( '  internet    ----------.
                       '-(          ).-'          ' opnsense 2 
                           '-.( ).-'               __________   
                                                  [_...__...°] 
                                                               
                             .--------------------..............
                            /                     . Cluster II .
  .-------.  .-------.  .-------.  .-------.      ..............
  | 10.52 |  | 10.54 |  | 10.56 |  | 10.57 |
  '-------'  '-------'  '-------'  '-------'


Wir haben auf beiden Seiten das gleiche Netzwerk, in diesem Falle das 172.20.0.0/16. Daraus sollen einzelne Adressen aus dem 172.20.10.0/23-er Subnetz umgeroutet werden. Wenn die 172.20.10.51 aus Cluster I mit der 172.20.10.56 in Cluster II reden will müssen die Pakete jeweils über beide Opnsense geroutet werden. Das Problem ist aber, dass wir in beiden Clustern insgesamt fünf Gateways haben und die Maschinen je nach anzubindenden VPN Verbindungen das passende Gateway als default nutzen. Bislang haben die Maschinen ebenfalls eine /16-er Netzmaske und werden per Firewallregeln "gezüchtigt". Sendet also die .51 ein Paket an die .56, geht das über das Interface direkt in das lokale Netzwerk wo jedoch keine .56 existiert. Jetzt könnte ich alle Weiterleitungen auf allen gateways definieren, aber hätte damit das Grundproblem nicht erschlagen: Ich kann nicht einfach allen Maschinen per DHCP eine /32-er Netzmaske verpassen und alle Pakete ganz brutal über das jeweilige Standardgateway leiten. Unter anderem bekommen wir dann ein Performanceproblem, weil die Gateways für den internen Traffic zum Flaschenhals werden. Wir haben teilweise mehrere tausend Websocket Verbindungen zwischen den Maschinen offen und haben im LAN schon Probleme deswegen.

Mal einen Schritt zurück gemacht und auf das große Ganze geschaut: Wir haben zwei getrennte Cluster mit Proxmoxknoten als Virtualisierungshosts. Die Maschinen sind alles Linuxkisten mit überwiegend CentOS drauf, ein paar mit Debian und eine einzelne Win10 Kiste, die mir aber grad ziemlich egal ist. Wir wollen jetzt alle Maschinen sukzessive von Cluster I nach Cluster II umziehen und dann Cluster I nach /dev/null verschieben. Alles im laufenden Betrieb und natürlich mit geringstmöglicher Beeinträchtigung der Systeme. Der Umzug ist an sich nicht zeitkritisch aber wenn wir starten sollte es möglichst ruckelfrei vonstatten gehen. Also suche ich nach einer Lösung mit der ich folgendes erreichen kann:

* Ich definiere für eine einzelne IP Adresse aus dem LAN, dass diese über das remote Gateway erreichbar ist
* Alle Systeme im betreffenden Cluster nutzen das Routing über die beiden Opnsense Instanzen (resp. nutzen die jeweils lokale Instanz als Gateway für diese Adresse)

Idealerweise würde ich das einmal zentral definieren und es würde sich in kurzer Zeit (wenige Minuten bis eine Stunde sind OK) im Netz herumsprechen und umgesetzt werden.

Muss ich dafür auf den einzelnen VM etwas installieren? Sollte ich das eher über die Knoten verwalten, also über Proxmox? Muss ich doch alle Pakete über definierte Gateways laufen lassen, um dort das weitere Routing bestimmen zu können?

Was nicht geht sind folgende Lösungen:

* den Maschinen beim Umzug eine neue IP aus einem anderen Subnet zuweisen und dieses Subnet komplett "umbiegen".
* alles herunterfahren und die Maschinen in einem Rutsch verschieben

Was offenbar nicht funktioniert (oder ich habe es falsch gemacht) ist, auf opnsense einfach einzelne routing Einträge anzulegen. Die gelten nur für opnsense selbst, werden aber nicht per DHCP weitergereicht. In DCHP wiederum sehe ich keine Möglichkeit, mehrere Dutzend Routingregeln zu hinterlegen, die dann ALLEN CLients übermittelt werden.

Vielleicht übersehe ich hier den Wald vor lauter Bäumen, aber ich stecke gedanklich grad etwas fest und wäre für eine Hilfestellung sehr dankbar!

Hi,
trying to create a wildcard certificate for some of our domains I'm catching this error in current acme-client package:
"Can not find dns api hook for: dns_hetzner"
Our Domains are hosted by Hetzner (a german ISP) and they released a new DNS API about two months ago. I know that acme.sh, the underlying script of this package, knows about this API very well. But for some reason, the version shipped with OPNsense doesn't.
Version is:
os-acme-client: 1.34

Before upgrading to 20.7 today, I also tried to fetch a certificate with latest 20.1 release. But no difference.

I found this thread, regarding the same topic: https://forum.opnsense.org/index.php?topic=15655.msg71634#msg71634
But reverting to version from 19.7.10_1 wouldn't help me in any way, as in 2019 there was no new Hetzner DNS API.

Does anyone have a glue what I could do to enable wildcard certificates with Let's Encrypt and Hetzner DNS?

Edit:
In some way the framework does know about the Hetzner DNS API, because I can select it as validation method. But when the script actually runs it throws this error and expects the respective DNS entries to be added manually.

[eigene]

Hallo Experten!

Sorry dass mein erster Beitrag gleich eine solche Frage ist, aber ich verzweifle gerade an der Einrichtung eines BINAT in Kombination mit IPsec. Immerhin gibt es diese Option bei OPNsense, weswegen ich auch gerade die Migration von IPfire zu OPNsense vorbereite.

Erst einmal die grundsätzliche Frage:
Kann ich auf einer OPNsense Installation ein entferntes Netzwerk unter einer anderen Adresse verfügbar machen, ohne dass die Gegenstelle irgendetwas anpassen muss? Beispielsweise muss ich den Host 192.168.1.10 auf der Gegenseite lokal in ein anderes Netz "verschieben". Dafür ist BINAT doch eigentlich da, oder nicht? Die Anleitung unter https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html mappt jedoch gleich beide Netze und zwar so, dass das eigene Netz bereits vor dem Tunnel transformiert wird. Ich will jedoch das Gegenteil erreichen. Ich versuche das mal als Textgrafik aufzuzeichnen:

Code Select Expand


lokales Netz [172.20.0.0/24] <===> NATted IP [192.168.250.10] <===> BINAT <===> Remote IP [192.168.1.10] <===> IPsec <===W=A=N===> remote ipsec ....


Die Fußangel ist natürlich, dass es das Netz 192.168.1.0/24 mehrfach gibt, deswegen lokal die Umsetzung. Aber der Einfachheit halber sagen wir mal, dass auf dem OPNsense nur ein IPsec dieses Netz verwendet.

Kann ich das so überhaupt umsetzen? Ich habe es eingerichtet und sehe auch, dass das BINAT greift, allerdings gehen keine Pakete in den Tunnel. Die Pakete scheinen immer auf das WAN Interface geroutet zu werden, daher vermute ich, dass die Firewall nach dem BINAT keine passende Route mehr findet.
Vielleicht stimmen auch die Firewallregeln nicht. Hier habe ich folgendes eingetragen:

Code Select Expand

Firewall: Rules: IPsec
IPv4      * 172.20.0.10 * 192.168.1.10 * * * [Traffic ausgehend]
IPv4      ICMP 192.168.1.10 * 172.20.0.10 * * * [ping eingehend]

Stimmt hier eventuell die Firewallgruppe nicht? Müssten die Regeln auf LAN oder WAN gesetzt werden? Käme mir aber unlogisch vor. Ich kann versuchen, die Regeln als floating zu setzen, aber ich möchte später nicht alle VPN betreffenden Regeln als floating setzen nur um es schnell und bequem zu haben. Die Regeln sollen dort sitzen wo sie hingehören.

Wenn ich einen Ping von meinem Host auf die Gegenstelle loslasse, passiert folgendes: ping auf 192.168.250.10 erreicht OPNsense, die IP wird dort übersetzt in 192.168.1.10 und wird von der Firewall auf dem WAN Interface mit der Regel "let out anything from firewall host itself" akzeptiert. BINAT hat also funktioniert, aber das Paket landet auf der WAN Schnittstelle und nicht bei IPsec.  :-\

An diesem Punkt bin ich etwas ratlos. Vermutlich verstehe ich grundlegende Zusammenhänge bei OPNsense noch nicht. Ich nutze seit 2½ Jahren IPfire und habe mich natürlich an dessen Arbeitsabläufe gewöhnt.

Die nächste Hürde, die dann zu nehmen wäre, ist die Einrichtung mehrerer solcher BINAT auf identische Zielnetze. Also, dass ich VPN A und VPN B mit dem Zielnetz 192.168.1.0/24 einrichten kann und VPN A bspw lokal auf 192.168.250.0/24 mappe und VPN B auf 192.168.251.0/24. Aber eins nach dem anderen.  ;D


Meine Version laut Dashboard:
OPNsense 20.1.6-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
LibreSSL 3.0.2

Alle Updates sind eingespielt und die Installation kann ich vorerst noch zum Testen verwenden.