Messages

Am Freitag habe ich 23.7.3 auf 23.7.4 upgedated. Danach hat ddclient die IP nicht mehr bei spdns.de eingetragen.

Diverse Versuche mit unterschiedlichen Einstellungen (native/ddclient, unterschiedliche IP-Methoden) brachten keine Besserung.

Nach einem heutigen Rollback auf 23.7.3 wurde die IP direkt wieder eingetragen.

Ist da schon was bekannt?

VG - Fossi

https://github.com/opnsense/core/commit/0ee3ecde53ff336d3c49ec48e5cb86d5c9d90813

This solved the whole challenge. The spaces i removed - so that could be still a challenge, but that could be fixed within minutes.

After this everything working fine again. Many Thx to Nils.

Hello Franco.

Thx for the reply. Yesterday a found some time for testing. I got a config working but found more changes, which wondering me a bit.

- peer2peer didn't work in TLS/SSL mode. I have changed it to pre-shared-key. I thought, ssl/tls is more secure, 10 years ago i changed all openvpn-configs to work with certs. (IPFire)
- The cipher GCM (256-GCM) didn't worked, I changed it to CBC but I thought till today that GCM is the more secure cipher. But that coul'd be a fault. Wouldn't it be nice, if only the possible ciphers would choosable in the drop down if someone chose peer2peer in top of the menu?
- for the ovpn-intern-net (Transfernetz) I have chooseen a /30 net, (I migrated some version of 18 or 19 from IPFire to Opnsense) and the well known /24 didn't worked with opnsense for me and ther /30 for Opnsense I found in a forum thread. So now the /24 is working.

The littel remote and lokal-subnets wasn't the challenge, the spaces I don't know exactly, but I removed them here.

Markus
Ich hatte genau das lokaale und remote Netze /24 und /25er, das Transfernetz als /30er. Das will er nicht mehr.
Nee kein Haken bei Topology gesetzt. Geht bei dem, was ich gestern testen konnte auch mit dem 24er Netz ohne Topologie IPs werden die 1 und die 2 vergeben. Davor, als es mit 24er nicht ging, waren es die 1 und die6 meine ich.
NilsS
ja logisch , das /24 kann natürlich auch las net30 laufen
hmm der parser von opnsense mag das /30 nicht
NilsS
https://github.com/opnsense/core/blob/master/src/www/vpn_openvpn_server.php#L207 ist der Punkt. sollte eingengrenzt werden auf Remote SSL und nicht peer2peer
https://github.com/opnsense/core/commit/35b373407cdde12c882dc6ef49b2ea5f3cf0eb78#diff-0eba9f068e6802636d7ff3e578931a563210eee384260648bfff7ad739b72339
NilsS
(($pconfig['mode'] == "server_user") || ($pconfig['mode'] == "server_tls_user")) muss da mit rein für die überprüfung
eigentlich macht doch bei peer2peer alles ausser /30 keinen sinn

The quote is from an other conversation. Nils is more familiar to code as me. I shell remark the commit in behalf of peer2peer.

I hope, this is helping a bit.

VG - Markus

Ok thats, what we dicussed in bashclub also. But i didn't arrived yet.

First of all I reinstalled the sytem with 21.1.9, the the productive lines are back. Thats for not loose too much time.

Now i can start a virtualized or a second hardware. To test the .xml

Hello Forum.

Need really Help. Today I updated to 21.7.2 and the whole OPNVPN config stopps working.

CDIR for VPN Net set to 10.10.10.0/30 - didn't acceppted anymore

CDIR for lokal and remot 10.x.x.0/25 - didn't acceppted anymore

What can I do? Whats wrong there? Is it a bug. What configs must be changed. Im totally helpless, because this configuration worked for years and now all is down and i cant get to the whole remote-hosts.

I will set up my firewall new and get back to 21.7.1. I have no idea to tholve this quickly.

thx for helping

Fossi

Das vermute ich auch - kann mir nicht vorstellen, dass die ein Bug ist, dann würde man da mehr von lesen.

Erstmal läuft die Maschine normal - das ist das wichtigste. Der Tunnel stand heute Morgen.

Aber Danke für die Unterstützung.

VG Fossi

Das ist richtig, aber ich hab grad kein grafisches Tool zur Hand gehabt, um die einige der Infos auszuxxxen.

Aber was anderes habe ich festgestellt. Die nicht funktionierende VPN-Verbindung wird mit einem nicht funktionierenden Dyn-DNS zusammenhängen. Der ist zwar am Client auch nicht kriegsentscheidend, aber irgendwas im Hintergrund wird blockiert werden.

Folgendes ist passiert: Mir ist gestern Vormittag aufgefallen, das auf dem betroffenen Client der Punkt DynDNS nicht richtig ansprechbar war. Das war mir zwar mal aufgefallen, ist dann aber wieder ins Hinterstübchen gewandert. Zufällig habe ich gerstern auf meiner eigenen Firewall Wireguard eingerichtet. Und heute hatte ich den gleichen Fehler auch bei mir - die DynDNS Accounts haben sich nicht mehr aktualisiert und wenn man den Punkt in der Webgui anklickt, dreht das system erstmal 5 Sekunden im Kreis und zeigt einem erst dann den Punkt an.
Also kurz nachgedacht - was habe ich verändert - ok Wireguard wieder deaktiviert. Neustart und DynDNS lässt sich flüssig ansprechen, Accounts sind grün. Das selbe habe ich jetzt auch auf dem anderen OPNSense gemacht, also WG erstmal deaktiviert. Auch da ist DynDNS jetzt wieder normal anzusprechen - wir hatten schon überlegt die Kiste neu aufzusetzen. Morgen kann ich sehen, ob die VPN-Verbindung wieder sauber läuft.

Lange Rede kurzer Sinn: Warum beeinflusst Wireguard die Funktion vom DynDNS, so das der Dienst ausfällt?

VG Fossi

PS: Sollte ich da einen neuen Thread aufmachen?

Bild machen und dann irgendwas ausixsen geht grad nicht. Ich hab mal den entspr. Teil der Konfig.xml gepostst. Die gesetzten Parameter sind ja zu sehen. 

Code Select Expand

<openvpn-client>
      <protocol>UDP4</protocol>
      <dev_mode>tun</dev_mode>
      <server_addr>xxx.xxxxx.de</server_addr>
      <server_port>1194</server_port>
      <resolve_retry>yes</resolve_retry>
      <proxy_authtype>none</proxy_authtype>
      <description>somedesccript</description>
      <mode>p2p_tls</mode>
      <crypto>AES-256-GCM</crypto>
      <digest>SHA512</digest>
      <engine>rdrand</engine>
      <tunnel_network>x.x.x.0/30</tunnel_network>
      <remote_network>x.x.x.0/25, x.x.x.0/25</remote_network>
      <compression>adaptive</compression>
      <no_tun_ipv6>yes</no_tun_ipv6>
      <verbosity_level>1</verbosity_level>
      <interface>wan</interface>
      <vpnid>1</vpnid>
      <custom_options/>
      <caref>xxx</caref>
      <certref>xxx</certref>
      <tls> xxx</tls>
   </openvpn-client>


Ok, einen Plan habe ich zwar nicht, aber ich versuchs zu erklären:

Es geht um Netz zu Netz (N2N) Verbindungen.

Der Server (Master) mit inzwischen 10 Verbindungen zu anderen Netzen (Clients/ Slaves) steht bei uns und läuft barematal auf einer Sophos SG310. Die Clients laufen als VMs auf Proxmox. Alles ist auf dem aktuellsten Stand gepatched.

Netz_100 ---- OPNse ---- Fritz.box ---- WAN ---- Zyxcel ---- VM-OPNse ---- Netz_xxx
                            |                                                                       |
                            |_____________   OpenVPN  ____________|

Alle bis auf ein Netz laufen einwandfrei, nur das mit dem Zyxcel-Router und dem T-Com Anschluss, der keine Zwangstrennung durchführt, baut sich nicht automatisch wieder auf.

Ich habe bereits den Punkt "ServerIP unbegrenzt auflösen" und "IP des Clients dynamisch" in der OVPN Server bzw. Client konfiguration geändert. Der Tunnel kommt aber immer erst nach einem Neustart des Clients wieder hoch - Neustart innerhalb der VM, der Virtualisierer läuft weiter. Da am Server in dem Moment nichts geändert wird, und die anderen Tunnel laufen, gehe ich nicht von einem DNS-Problem aus. Ich vermute, das der Client auf Grund der nicht durchgeführten Zwangstrennung den Wechsel der IP des Servers nicht erkennt und somit nicht neu gestartet wird.

Wie kann ich da ansetzen? Wie kann ich z.B. einen Neustart der VPN Clientkonfiguration über Cron einpflegen?

VG Fossi

Hallo liebes Forum.

An meiner Opnsense hängen mehrere weiter Opnsense per N2N über OpenVPN. Alle Tunnel funktionieren zumeist einwandfrei, alle Clients und der Server hängen an Internetanschlüssen mit wechselden IP Adressen. Der Wechsel erfolgt nachts, so dass eigentlich niemand dahinter kommt oder Dienste zusammenbrechen.

Bis auf eine einzellne Clientverbindung. Die Konfiguration habe ich inzw. mehrfach mit den anderen abgeglichen und auch einmal vollständig neu erzeugt. An diesem Client gibt es zwei wesentliche Unterschiede: Der Zugang erfolgt über einen Zyxel Router der Telekom (alle anderen hängen an Fritzboxen) und der Zugang erfolgt über einen Telekom Business Zugang. Die IP-Adresse wechselt nicht regelmässig, ist teilweise über 3 Monate identisch.

Kann jemand anhand dieser Daten einschätzen, wo ich ansetzen kann bzw. einschätzen, wo diese Herausforderung seinen Ursprung haben könnte? Gibt es da ein problem mit der Erkennung eines Wechsels der IP Adresse? Ich würde sonst evt. mal die Routerzwangstrennung aktivieren, Vielleicht wählt der Client dann selbstständig neu ein.

Danke für die Unterstützung.

VG Fossi

Im just stuggeling AT the same point. SG310 and 210

Did you find any solution? Could you Post your config, please?

Im completly new on FreeBSD, come from Debian.  I was able to start lcdd by cli with onestart, but wasn't able to get it working while Boot.
On top i didnt understand the menu: i can navigate, but the entrees are confusing and i cant managing thomething. So i  need a litte starthelp.

Ach so. Die config der jeweiligen Seite gibt immer an, was laut Routing in den Tunnel soll.

Wenn also der Client auf seiner Seite 0.0.0.0/0 bekommt, hat er routingseitig Zugriff auf alle Netze auf dem Opnsense. Alles weitere muss dann ggf. über die Firewall erlaubt oder verneint werden, richtig?


Ich hab an openvpn gedacht, dort geht's ja immer um die jeweiligen Netze.

Sollte man die entsprechenden Einträge für die Firewall unter Wireguard oder unter wg0 eintragen? Hab da auch unterschiedliches gelesen. Teilweise wird auch noch eine NAT roule eingetragen, die ist bei mir unter WAN aber bereits vorhanden.

Danke bis hierher.

VG - Fossi

Auch das führt zum gleichen Ergebnis - habs grad mal probiert.

Grundsätzlich ist dein Vorschlag logisch, jedoch wird auch hier die 0.0.0.0/0 nur für einen Client übernommen.

Hab grad mal nochwas probiert: 10.10.10.1/24 und 10.10.10.2/24 geht auch nicht, macht ja auch keinen Sinn.
Die Angabe wird korrekt interpretiert: 10.10.10.0/24 wird in List Configuration angezeigt und somit wieder nur bei einem Client übernommen.

Das ist echt schräg.

Hallo liebes Forum.

Ich versuche mich grad an der Konfiguration eines Wireguard Servers für mehrere Mobil Devices als quasi "immeran VPN" und möchte die Clients auch über PIHole in unserem Netz laufen lassen.

Die Tunnel laufen auch, aber was mich grundsätzlich stutzig macht: Wenn ich die allowed Subnets in den Endpoints auf den Servern angebe, kann ich eine Netzkonfiguration immer nur einmal angeben, beim zweiten client wird sie ignoriert.

10.10.15.2/32 geht auf dem ersten Client
10.10.15.3/32 geht auf dem zweiten Client

Muss ja auch so, weil das das VPN-Netz ist.

10.10.15.2/32, 10.10.10.0/24 geht auf dem ersten Client (das zweite Netz ist das Lan-Netz)
10.10.15.3/32, 10.10.10.0/24 geht auf dem zweiten Client NICHT (das zweite Netz wird ignoriert, der Client kann somit nicht auf Server im lokalen Lan zugreifen)

Code Select Expand

interface: wg1
  public key: xxxxxxxxxxxxxxxxxx=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxx=
  endpoint: xx.xx.xx.xx:22735
  allowed ips: 10.10.10.0/24, 10.10.15.2/32
  latest handshake: 1 minute, 48 seconds ago
  transfer: 307.01 KiB received, 1.41 MiB sent

peer:xxxxxxxxxx=
  endpoint: xx.xx.xx.xx:51820
  allowed ips: 10.10.15.3/32

Bitte nicht daran stören, dass das zweite Device grade nicht connected ist - Hab grad keinen Zugriff drauf.

Auf den Devices selbst habe ich 0.0.0.0/0 angegeben, damit tatsächlich alles über den Tunnel läuft.

Es macht ein bisschen den Eindruck, als wenn eine interne Prüfung der Konfiguration vorgenommen wird, und bei zwei identischen Adressen einfach eine rausgeschmissen wird. Für das VPN Netz würde das ja auch noch Sinn machen, aber nicht mehr für die Netze, die geroutet werden sollen. Handelt es sich hier um einen Bug, oder hab ichs noch nicht verstanden. Eigentlich hab ich it etlichen Beschreibungen, auch für andere Distros abgeglichen.

Und noch eine Frage: Welche IP muss ich angeben, wenn der unbound auf dem opnsense selbst der DNS für die Clients sein soll? Die .15.1 Des Wireguardtunnels oder z.b. die .10.1 als des Lan-Interfaces?

Danke schonmal.

VG - Fossi