1
22.1 Legacy Series / Re: [Solved] 22.1.10 IPsec tunnels not showing up
« on: July 16, 2022, 09:01:43 pm »
Thank you for the quick help. This did the job.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
22.1 Legacy Series / [Solved] 22.1.10 IPsec tunnels not showing up
« on: July 16, 2022, 09:34:53 am »
Norning all,
I just updated one of my OPNsenses from 21.1.8 to 21.1.10 and found that my IPsec tunnels (net-net) are not showing up any more. Neither in the dashboard applet nor in the status overview. Also the log file is not accessible from the GUI.
The corresponding tunnels are up and running, though, which means I can access the site and vice versa can access remote resources from this site. So technically spoken not a critical problem of operations.
The remote endpoints are running a mix of 21.1.8 and 21.1.9 (the latter one being the one which I usually update first).
The security allocation+policies both show reasonable data.
The phenomenon does not change after stopping/starting IPsec and rebooting the firewall.
Did I miss something which I was supposed to do, and/or do others see the same situation?
I just updated one of my OPNsenses from 21.1.8 to 21.1.10 and found that my IPsec tunnels (net-net) are not showing up any more. Neither in the dashboard applet nor in the status overview. Also the log file is not accessible from the GUI.
The corresponding tunnels are up and running, though, which means I can access the site and vice versa can access remote resources from this site. So technically spoken not a critical problem of operations.
The remote endpoints are running a mix of 21.1.8 and 21.1.9 (the latter one being the one which I usually update first).
The security allocation+policies both show reasonable data.
The phenomenon does not change after stopping/starting IPsec and rebooting the firewall.
Did I miss something which I was supposed to do, and/or do others see the same situation?
3
German - Deutsch / Re: Hilfe für ein Isoliertes VLAN. Nur Internet
« on: January 02, 2021, 01:21:34 pm »
Stimmt, danke für den Hinweis @Gauss23
Da ich es gerade nicht schaffe, meinen Beitrag zu berichtigen, nochmal: 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
Da ich es gerade nicht schaffe, meinen Beitrag zu berichtigen, nochmal: 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
4
German - Deutsch / Re: Problematik mit dem Zertifikat
« on: January 02, 2021, 01:18:48 pm »
Mist, ich hätte ordentlich was drauf gewettet 
. Stimmt denn die Browserzeit, wenn du sowas aufrufst wie wie http://browserspy.dk/date.php ?
. Stimmt denn die Browserzeit, wenn du sowas aufrufst wie wie http://browserspy.dk/date.php ?
5
German - Deutsch / Re: Problematik mit dem Zertifikat
« on: January 02, 2021, 11:38:53 am »
Das Zertifikat ist erst 18.576 Tage in der Zukunft gültig, steht da? Tipp ins Blaue: Das sind rund 50,9 Jahre. Kriegt die Glotze denn ne vernünftige Uhrzeit, oder steht die zufällig auf Unixnull, also 1970 (das war zwar ein verdammt guter Jahrgang, aber ist ist in diesem Falle eher hinderlich)?
6
German - Deutsch / Re: Durchwachsen bis jetzt
« on: January 02, 2021, 12:37:41 am »
Dass jeder Umstieg erstmal frustrierend ist, weil hier und da und dort irgendeine widerwärtig versteckte Kleinigkeit nicht funktioniert, das kenne ich selbst. Ich hatte da neulich ne Sophos UTM abzulösen (einfach weil ich deren Geschäfts- und Lizenzmodell nicht mehr unterstützen wollte), und nachdem das mit professioneller Hilfe echt richtig geil vorbereitet war, war ich von der Couch aus, also remote, in ner guten Stunde durch, so dass ich auf nem anderen Standort genauso dann auch noch nen IPcop abgelöst hatte. Letzterer war sowas von dran, aber ich hatte das Monat um Monat immer vor mir her prokrastiniert, weil das Setup doch auch recht komplex war. Nur verkabelt war da schon mal alles.
Ja, an beiden Standorten gab es noch die ein oder andere Nachwehe – das waren dann irgendwelche falsch eingestellten Parameter in der IKE-Lebensdauer oder das ein oder andere vergessene Pinhole aus der DMZ heraus und an dem anderen Standort ein auf dem IPcop noch laufender DHCP-Server –, aber ich habe den Umstieg zu keinem Zeitpunkt bereut.
Ich würde jetzt mal den Vorschlag in den Raum werfen, für die Anbindung von deinem iPhone (das ist dann wohl ein externer Roadwarrior, richtig?) evtl OpenVPN zu verwenden.
Ich arbeite bei meinen Sensen mit IPsec bei den Netz-Netz-Geschichten. Einfach deswegen, weil ich es schon seit anderthalb Jahrzehnten so mache (weil damals OpenVPN einiges mehr an Ressourcen brauchte und noch bissi experimentell war). Die ganzen Roadwarrior sind diverse Windows, OSX, iOS und Androids, ach ja, ein Debian ist auch dabei. Hier ist nach meiner Erfahrung die Client-Unterstützung einfach schicker mit OpenVPN gelöst. Wenn es muss, sogar über Port 443, das geht von überall aus. Wenn sich das mit nem anderen Webserver auf derselben IP beißen sollte, wäre HAproxy dein Freund (nur um dich schon mal ein bisschen prophylaktisch zu verwirren). Will sagen, mit dem Standard UDP/1194 liegst du schon mal nicht falsch, auch hier habe ich noch keine Restriktionen erlebt.
Ja, an beiden Standorten gab es noch die ein oder andere Nachwehe – das waren dann irgendwelche falsch eingestellten Parameter in der IKE-Lebensdauer oder das ein oder andere vergessene Pinhole aus der DMZ heraus und an dem anderen Standort ein auf dem IPcop noch laufender DHCP-Server –, aber ich habe den Umstieg zu keinem Zeitpunkt bereut.
Ich würde jetzt mal den Vorschlag in den Raum werfen, für die Anbindung von deinem iPhone (das ist dann wohl ein externer Roadwarrior, richtig?) evtl OpenVPN zu verwenden.
Ich arbeite bei meinen Sensen mit IPsec bei den Netz-Netz-Geschichten. Einfach deswegen, weil ich es schon seit anderthalb Jahrzehnten so mache (weil damals OpenVPN einiges mehr an Ressourcen brauchte und noch bissi experimentell war). Die ganzen Roadwarrior sind diverse Windows, OSX, iOS und Androids, ach ja, ein Debian ist auch dabei. Hier ist nach meiner Erfahrung die Client-Unterstützung einfach schicker mit OpenVPN gelöst. Wenn es muss, sogar über Port 443, das geht von überall aus. Wenn sich das mit nem anderen Webserver auf derselben IP beißen sollte, wäre HAproxy dein Freund (nur um dich schon mal ein bisschen prophylaktisch zu verwirren). Will sagen, mit dem Standard UDP/1194 liegst du schon mal nicht falsch, auch hier habe ich noch keine Restriktionen erlebt.
7
German - Deutsch / Re: Hilfe für ein Isoliertes VLAN. Nur Internet
« on: January 02, 2021, 12:16:55 am »
Habe ich das richtig verstanden, dass du aktuell vier Zonen hast, die jeweils nur "Internet dürfen sollen"? Das hieße ja, die dürfen grundsätzlich alles außer 10., 172.16…31 und 192.168. Und genau hier liegt die Lösung dafür. Denk einfach dran, dass automatisch alles verboten ist, was du nicht erlaubst 
Leg einen Network(s)-Alias an mit dem Inhalt 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24 (das kannste grad so rüberkopieren) und nem einschlägigen Namen, also "RFC1918" oder "PRIVATE". Dann kommst du mit einer Allow-Rule je Zone aus, mit Destination/invert angeklickt, Destination "RFC1918".
Oder halt mehrere Regeln, wenn du nur bestimmte Ports/Protokolle erlauben willst. Aber auch bei den Ports würde ich dann mit Aliassen arbeiten, da hast du es einfacher, wenn du hinterher Ports hinzufügen oder rausnehmen willst. So ein Port(s)-Alias namens "UDPstd" könnte dann beispielsweise den Inhalt 53,123,500,1194,3478,4500,5938,17500 haben.
Und wenn du bestimmte einzelne Zonenpärchen doch miteinander reden lassen willst, erlaubst du das entsprechend vor dieser Regel mit der Quick-Option bzw First match (wird dann ja immer alles von oben nach unten abgearbeitet). In diesem Fall natürlich ohne Invert. Da brauchst du dann keinen Alias, da kannst du die Destination direkt aus der Liste auswählen.
Für alle zukünftigen Zonen wird das dann ganz stumpf genauso angelegt. Simpel, aber herrlich übersichtlich. Grüße gehen an dieser Stelle raus an mimugmail für diesen sehr ästhetischen Tipp
Leg einen Network(s)-Alias an mit dem Inhalt 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24 (das kannste grad so rüberkopieren) und nem einschlägigen Namen, also "RFC1918" oder "PRIVATE". Dann kommst du mit einer Allow-Rule je Zone aus, mit Destination/invert angeklickt, Destination "RFC1918".
Oder halt mehrere Regeln, wenn du nur bestimmte Ports/Protokolle erlauben willst. Aber auch bei den Ports würde ich dann mit Aliassen arbeiten, da hast du es einfacher, wenn du hinterher Ports hinzufügen oder rausnehmen willst. So ein Port(s)-Alias namens "UDPstd" könnte dann beispielsweise den Inhalt 53,123,500,1194,3478,4500,5938,17500 haben.
Und wenn du bestimmte einzelne Zonenpärchen doch miteinander reden lassen willst, erlaubst du das entsprechend vor dieser Regel mit der Quick-Option bzw First match (wird dann ja immer alles von oben nach unten abgearbeitet). In diesem Fall natürlich ohne Invert. Da brauchst du dann keinen Alias, da kannst du die Destination direkt aus der Liste auswählen.
Für alle zukünftigen Zonen wird das dann ganz stumpf genauso angelegt. Simpel, aber herrlich übersichtlich. Grüße gehen an dieser Stelle raus an mimugmail für diesen sehr ästhetischen Tipp
8
Hardware and Performance / Sophos SG210 hardware
« on: October 09, 2020, 03:25:28 pm »
Quick and direct question: Has anyone succeeded installing OPNsense onto a Sophos SG210 hardware?
9
German - Deutsch / Re: Telekom verlangt Firmware-Upgrade, SRV-Diensteauflösung
« on: September 05, 2020, 01:22:57 pm »
Echt, du meinst wirklich, dass da jemand wirklich denkt? Mir kam das eher so vor, als würde der von einer Tafel ablesend sein Mantra beten "Sie müssen die Firmware aktualisieren!" -- "Welche Firmware? Mein Setup sieht wie folgt aus: blablablabla..." -- "Na die Firmware, die müssen Sie aktualisieren" -- "Vom Gateway? Na die ist schon aktuell" -- "Dann müssen Sie halt nochmal aktualisieren"
Immerhin der Mitarbeiter, mit dem ich im Nachgang ncohmal gesprochen habe, hatte wohl die Mitleidstafel zum Ablesen vor Augen: "Mir tut das ja auch leid, aber ich habe keine Möglichkeit, das gegenzuprüfen"
Immerhin der Mitarbeiter, mit dem ich im Nachgang ncohmal gesprochen habe, hatte wohl die Mitleidstafel zum Ablesen vor Augen: "Mir tut das ja auch leid, aber ich habe keine Möglichkeit, das gegenzuprüfen"
10
German - Deutsch / Re: Telekom verlangt Firmware-Upgrade, SRV-Diensteauflösung
« on: September 03, 2020, 02:30:33 pm »
Hallo Leute, danke für die Antworten. Ich glaube jedoch, dass ich die Lösung gefunden habe (wobei mir das die Hotline vom Gilb weder bestätigen noch dementieren wollte/konnte/durfte oder so).
Danke auch für die Erinnerung an das schöne altgermanische Wort "Gilb", welches wieder in meinen Sprachgebrauch zurück gekehrt ist und im Folgenden auch stur durchgezogen wird.
Da ich mir ja eigentlich schon von Anfang an sicher war, dass es nicht an "meinen" DNS-Servern liegt (weil die allenfalls "sip.gilb.de" auflösen), hab ich mal nach Gigaset, VoIP, SRV gesucht...
Das Gigaset-Telefon hatte noch ne sehr alte Firmware drauf. Nach Aktualisierung gibt wird die Option "DNS SRV Lookup" in der Verbindungseinstellung wahlweise unterstützt (das hatte ich, glaube ich, irgendwo auf ner Netcologne-Seite gefunden). NAch dem Aktivieren und Bestätigen der Einstellungen darf man sich nicht am "fehlgeschlagen" irritieren lassen, sondern einfach nochmal auf "sichern" gehen, dann klappts.
Toll ist im Nachgang, dass mir der Gilb wiederum weder bestätigen oder dementieren kann, dass oder ob das des Rätsels Lösung war.
Danke auch für die Erinnerung an das schöne altgermanische Wort "Gilb", welches wieder in meinen Sprachgebrauch zurück gekehrt ist und im Folgenden auch stur durchgezogen wird.
Da ich mir ja eigentlich schon von Anfang an sicher war, dass es nicht an "meinen" DNS-Servern liegt (weil die allenfalls "sip.gilb.de" auflösen), hab ich mal nach Gigaset, VoIP, SRV gesucht...
Das Gigaset-Telefon hatte noch ne sehr alte Firmware drauf. Nach Aktualisierung gibt wird die Option "DNS SRV Lookup" in der Verbindungseinstellung wahlweise unterstützt (das hatte ich, glaube ich, irgendwo auf ner Netcologne-Seite gefunden). NAch dem Aktivieren und Bestätigen der Einstellungen darf man sich nicht am "fehlgeschlagen" irritieren lassen, sondern einfach nochmal auf "sichern" gehen, dann klappts.
Toll ist im Nachgang, dass mir der Gilb wiederum weder bestätigen oder dementieren kann, dass oder ob das des Rätsels Lösung war.
11
German - Deutsch / Telekom verlangt Firmware-Upgrade, SRV-Diensteauflösung
« on: September 03, 2020, 11:10:48 am »
Hallo liebes Forum!
Mit Schreiben von vorgestern möchte mir die Telekom erklären, dass ich in einer Filiale wegen eines "veralteten DNS-Eintrags über A-Record" ab 21. September nicht mehr telefonieren könne. Stattdessen möge ich doch bitte eine "SRV-Diensteauflösung" benutzen.
Die technische Hotline verwies nur relativ stumpf auf "Sie müssen 'DAS' Update machen", konnte mir jedoch keinerlei weitere Hinweise geben außer "ja wenn Sie einen Router von uns verwenden würden…" — dann kann ich aber meine IPsec-Tunnel grad mal in die Tonne treten. Als ob alle anderen Geschäftskunden den ganzen Tag nur Katzenvideos glotzen würden
Kann mir hier jemand einen Schubs in die richtige Richtung geben? Was genau wollen die von mir, wie schaffe ich das?
Setup:
Telekom ADSL, 16 Mbit/s, BNG, statische IPV4-Adresse.
Modem: Dlink DSL-321b
Router: OPNsense, WAN-Anschluss über PPPOE (derzeit noch 20.1.8, das Upgrade auf 20.7 habe ich hier noch prokrastiniert ).
Telefon: Gigaset C430A GO, steht im LAN, erhält eine fixe V4-Adresse über DHCP der OPNsense. Als DNS-Server verweise ich auf einige interne BIND9-Server, welche für alles externe bei Google oder Quad9 anfragen.
Für die SIP-Anbindung (zur Telekom) habe ich für das Telefon "NAT ausgehend" mit statischen Ports definiert sowie UDP Portweiterleitungen von der PPPOE-Adresse (3478,5060:5076,40000:40100) zum Telefon angelegt.
Mit Schreiben von vorgestern möchte mir die Telekom erklären, dass ich in einer Filiale wegen eines "veralteten DNS-Eintrags über A-Record" ab 21. September nicht mehr telefonieren könne. Stattdessen möge ich doch bitte eine "SRV-Diensteauflösung" benutzen.
Die technische Hotline verwies nur relativ stumpf auf "Sie müssen 'DAS' Update machen", konnte mir jedoch keinerlei weitere Hinweise geben außer "ja wenn Sie einen Router von uns verwenden würden…" — dann kann ich aber meine IPsec-Tunnel grad mal in die Tonne treten. Als ob alle anderen Geschäftskunden den ganzen Tag nur Katzenvideos glotzen würden
Kann mir hier jemand einen Schubs in die richtige Richtung geben? Was genau wollen die von mir, wie schaffe ich das?
Setup:
Telekom ADSL, 16 Mbit/s, BNG, statische IPV4-Adresse.
Modem: Dlink DSL-321b
Router: OPNsense, WAN-Anschluss über PPPOE (derzeit noch 20.1.8, das Upgrade auf 20.7 habe ich hier noch prokrastiniert
). Telefon: Gigaset C430A GO, steht im LAN, erhält eine fixe V4-Adresse über DHCP der OPNsense. Als DNS-Server verweise ich auf einige interne BIND9-Server, welche für alles externe bei Google oder Quad9 anfragen.
Für die SIP-Anbindung (zur Telekom) habe ich für das Telefon "NAT ausgehend" mit statischen Ports definiert sowie UDP Portweiterleitungen von der PPPOE-Adresse (3478,5060:5076,40000:40100) zum Telefon angelegt.
12
German - Deutsch / Re: Opnsense und Unifi VLAN Setup
« on: April 06, 2020, 06:25:59 pm »
Alsoooo... ich hab diverse APs an ner OPNsense (und auch an ner UTM, solange das Abo noch bezahlt ist, aber das tut hier nix zur Sache.
Der Controller läuft für alle Standorte zentral auf ner Ubuntu-VM. Bei nem neuen Standort erst den Standort im Controller anlegen, dann spioniert der Controller dort automatisch rum und provisioniert. Falls nicht, einfach set-inform http://<<IPaddr>>:8080/inform
Setup je Standort ist immer VLAN0 untagged = internes WLAN. Hier gibt es aus historischen Gründen unterschiedliche Standorte, die entweder eine separate Maske für WLAN (versus LAN) haben oder auch nicht (dann ist WLAN und LAN einfach zusammen). Gäste-WLAN ist VLAN 100 tagged, das liegt natürlich auf demselben physischen Port, auf dem auch der WLAN-Anschluss liegt. Das VLAN habe ich natürlich auch auf den entsprechenden Ports ALLER dazwischen liegenden Switche konfiguriert (VLAN0 untagged und VLAN100 tagged).
Ergebnis: Läuft. Erstaunlich problemlos. Hin und wieder mal Updates aussenden, ansonsten absolut pflegeleichte Dinger, diese kleinen unscheinbaren Ufos.
Der Controller läuft für alle Standorte zentral auf ner Ubuntu-VM. Bei nem neuen Standort erst den Standort im Controller anlegen, dann spioniert der Controller dort automatisch rum und provisioniert. Falls nicht, einfach set-inform http://<<IPaddr>>:8080/inform
Setup je Standort ist immer VLAN0 untagged = internes WLAN. Hier gibt es aus historischen Gründen unterschiedliche Standorte, die entweder eine separate Maske für WLAN (versus LAN) haben oder auch nicht (dann ist WLAN und LAN einfach zusammen). Gäste-WLAN ist VLAN 100 tagged, das liegt natürlich auf demselben physischen Port, auf dem auch der WLAN-Anschluss liegt. Das VLAN habe ich natürlich auch auf den entsprechenden Ports ALLER dazwischen liegenden Switche konfiguriert (VLAN0 untagged und VLAN100 tagged).
Ergebnis: Läuft. Erstaunlich problemlos. Hin und wieder mal Updates aussenden, ansonsten absolut pflegeleichte Dinger, diese kleinen unscheinbaren Ufos.
13
German - Deutsch / Re: Umstieg von Sophos XG
« on: April 06, 2020, 06:16:39 pm »
Gude und willkommen hier. Ich antworte einfach mal zum Thema der Unifi. Ich habe in diversen Netzen inzwischen vom IPcop auf die OPNsense migriert. Ein weiteres Nezt läuft nach wie vor auf ner Sophos UTM, da endet das Abo im Oktober, dann kommt die weg und ne Sense hin. Die paranoide Konfig von meinem Vorgänger nervt mich eh, aber ich bin ja ein geduldiger Mensch.
In dem Sophos-Netz gab es vor meiner Machtübernahme gar kein WLAN. Aufgrund der etwas seltsamen Architektur (mehr Stahl im Beton als Beton um den Stahl) hatte ich dann mal ne AP AC LR bestellt, inzwischen habe ich zwei Stück in der Hütte, und gut ist.
Der Controller läuft inzwischen für diverse Standorte zentral auf ner Ubuntu-VM total tiefenentspannt. Gäste-WLAN über VLAN war auch kein Problem, ich war echt erstaunt, wie einfach das ging. Wichtig ist hier halt, dass deine Switche, die zwischen der Sense und den APs liegen, entsprechend konfiguriert werden (also in der Regel VLAN0 untagged und VLAN XXX tagged). Aber da reicht schon ein recht einfacher Managed Switch. Anfangs hatte ich mal nen kleinen POE-Switch von Ubiquity mit drin, den habe ich aus ästhetischen Grunden inzwischen wieder rausgeworfen und mache POE mit den Injektoren, die bei den APs dabei waren. Okay, ästhetisch ist das auch net, aber die Teile kann ich einfacher um nen Pfosten vom Rack schnallen als den Miniswitch, der unmotiviert rumfliegt, wie es ihm die Kabel halt diktieren.
Fazit: Geht erstaunlich problemlos sowohl an der UTM als auch an den Sensen. Wenn du soweit bist, kannste mich gern antickern, falls du konkrete Fragen hast.
In dem Sophos-Netz gab es vor meiner Machtübernahme gar kein WLAN. Aufgrund der etwas seltsamen Architektur (mehr Stahl im Beton als Beton um den Stahl) hatte ich dann mal ne AP AC LR bestellt, inzwischen habe ich zwei Stück in der Hütte, und gut ist.
Der Controller läuft inzwischen für diverse Standorte zentral auf ner Ubuntu-VM total tiefenentspannt. Gäste-WLAN über VLAN war auch kein Problem, ich war echt erstaunt, wie einfach das ging. Wichtig ist hier halt, dass deine Switche, die zwischen der Sense und den APs liegen, entsprechend konfiguriert werden (also in der Regel VLAN0 untagged und VLAN XXX tagged). Aber da reicht schon ein recht einfacher Managed Switch. Anfangs hatte ich mal nen kleinen POE-Switch von Ubiquity mit drin, den habe ich aus ästhetischen Grunden inzwischen wieder rausgeworfen und mache POE mit den Injektoren, die bei den APs dabei waren. Okay, ästhetisch ist das auch net, aber die Teile kann ich einfacher um nen Pfosten vom Rack schnallen als den Miniswitch, der unmotiviert rumfliegt, wie es ihm die Kabel halt diktieren.
Fazit: Geht erstaunlich problemlos sowohl an der UTM als auch an den Sensen. Wenn du soweit bist, kannste mich gern antickern, falls du konkrete Fragen hast.
14
Tutorials and FAQs / Re: Google Drive Backup
« on: February 09, 2020, 10:38:49 am »
@rcrules: Thank you a lot for posting the detailled tutorial. I followed it step for step and was able to succesfully set up an automated backup for all my OPNsenses.
15
German - Deutsch / Re: IPsec, ein spezieller Tunnel durcheinander seit Update von 18.1.5 nach 18.1.8
« on: June 05, 2019, 08:26:47 pm »
Sooooo. Die con5 hab ich deaktiviert und stattdessen eine neue Verbindung angelegt. Die geht. Zurück bleibt ein Mysterium.
Pages: [1] 2