Menu

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.

Show posts Menu

Messages - murmelbahn

#1
Ich habe den Fehler gefunden: Das oben erwähnte VPN wurde ursprünglich aus einem anderen herausgelöst.

Der Partner hatte damals alle seine Satelliten über sein HQ geroutet. Aufgrund der hohen Latenzzeiten (welch Überraschung) wurde mein ursprünglicher Vorschlag, die einzelnen Satelliten direkt anzubinden, letztendlich doch umgesetzt. Dabei hatte ich das IP-Netz aus meiner Phase 2 im alten VPN entfernt und es im neuen VPN neu angelegt.

Als ich heute alles noch einmal überprüft habe, ist mir aufgefallen, dass die OPNsense dieses IP-Netz sowohl im neuen als auch im alten VPN angezeigt hat. Ein kurzes Gespräch mit dem Partner brachte die Lösung: Er hatte vergessen, das Netz aus seiner Phase 2 zu löschen. Nachdem er das nachgeholt hatte und wir beide Tunnel neu gestartet hatten, war das Problem behoben.

Thread kann dann zu :)
#2
Hallo,

ich versuche, mit einer Sophos Firewall einen IPSec-Tunnel zwischen zwei Netzwerken einzurichten. Die Verbindung zwischen beiden Geräten kann grundsätzlich hergestellt werden, jedoch bricht der Tunnel alle 30–45 Minuten ab.

Das Problem äußert sich folgendermaßen: Auf der OPNsense scheint alles in Ordnung zu sein, aber der Datenverkehr zwischen den Netzen stoppt. Ich habe bereits verschiedene Einstellungen in Phase 1 und Phase 2 getestet, jedoch ohne dauerhaften Erfolg. Mittlerweile bin ich etwas ratlos, insbesondere hinsichtlich der weiteren Debugging-Möglichkeiten.

Um das Problem besser einzugrenzen, habe ich testweise einen Syslog-Server eingerichtet und die Logs der OPNsense dorthin geleitet. Allerdings fällt es mir schwer, die relevanten Einträge dem betroffenen VPN-Tunnel zuzuordnen, da mehrere VPN-Verbindungen auf der OPNsense konfiguriert sind. Zudem scheinen in den Logs wichtige Informationen zu fehlen.

In den Advanced Settings → Syslog gibt es diverse Parameter, die angepasst werden können. Die Option "Also include sensitive material in dumps, e.g. keys" scheint das höchste Loglevel zu aktivieren, allerdings bin ich unsicher, welche spezifischen Einstellungen erforderlich sind, um detaillierte Logs für genau diesen problematischen Tunnel zu erhalten. Leider bietet die OPNsense-Dokumentation hierzu nur begrenzte Informationen.

Daher meine Fragen:

    Wie kann ich möglichst verbose Logs für exakt diesen Tunnel generieren?
    Gibt es alternative Ansätze, um das Problem gezielt zu analysieren und zu lösen?

Ich freue mich über jede Unterstützung und bin für hilfreiche Hinweise dankbar!

€: Beim weiteren beobachten habe ich soeben festgestellt, dass wenn scheinbar keine Daten mehr durch den Tunnel gehen dieses Problem nicht jeden
Client im Netz bei mir betrifft. Ich habe das Netz 172.16.0.0/24 lokal und 172.16.79.0/24 remote. Kurioserweise kann ich mit der 172.16.0.3 die 172.16.79.3 pingen aber die 172.16.0.50 kann die 172.16.79.3 nicht pingen. Es kommt aber auch vor das die 172.16.0.3 die 172.16.79.3 nicht pingen kann.

Hat jemand eine Idee wonach man als nächstes gucken sollte?

Viele Grüße
#3
German - Deutsch / Re: Basic authentication und HAProxy
February 23, 2024, 08:00:06 AM
Hi,

ich hab keine Chance zu sehen ob NTLM dahinter verwendet wird. Das ist son oller MoCa Adapter der ein Webinterface hat: https://www.gocoax.com/ma2500d Das Anmelde Pop-Up sieht halt wie basic http auth aus.
Ich wüsste nicht wie ich das weiter spezifieren sollte.
#4
German - Deutsch / Basic authentication und HAProxy
February 22, 2024, 01:53:20 PM
Hallo zusammen,

ich benutze HAProxy um für einige interne Websites TLS machen zu können.
Ich hab hier ein Gerät, das verlangt an seiner Website mittels basic authentication username und password.
Wenn ich die Website über HAProxy aufrufe bekomme ich den Anmeldedialog angezeigt aber nach dem Absenden erscheint der Anmeldedialog direkt wieder. Ich vermute irgendeine Option im HAProxy für diesen Server einstellen zu müssen. Hat jemand eine Idee was ich machen muss?

Danke & VG
#5
General Discussion / Re: Wireguard and NAT
November 24, 2022, 10:29:39 AM
Can someone delete this? I had a typo in the ip address for the tunnels...
#6
General Discussion / Wireguard and NAT
November 24, 2022, 07:35:36 AM
Hi all,

sorry for the general title of the topic but I'm not able to specify it.
My problem is as followed:

1x OPNsense Box
1x Openwrt Router

The Openwrt Router connects to the OPNsense box as a Wireguard client. At the Openwrt Router are more clients attached. I have disabled the masquarading for the Wireguard net on the openwrt router. I can access everything from one side to the other. But I have two problems with this setup:

1. The voip telefons / softphones on the Openwrt side does not work as intended. They ring and they connected to the sip registrar on the OPNsense side butwhen someone calls or they are called nobody hears the other.

2. There are a few road warrior clients on the same wireguard server. They can not ping or access anything in the openwrt side.

I think this is a NAT problem?

Maybe someone can point me in the right direction.
#7
Thanks buddy! Works perfect!
#8
Hi,

I'm usind OPNsense 21.9. When I try to update i get the following errors:

Quote***GOT REQUEST TO CHECK FOR UPDATES***
Fetching changelog information, please wait... Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
6540779847680:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
fetch: https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/sets/changelog.txz.sig: Authentication error
Updating OPNsense repository catalogue...
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/latest/meta.txz: Authentication error
repository OPNsense has no meta file, using default settings
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
1763635204096:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/latest/packagesite.txz: Authentication error
Unable to update repository OPNsense
Error updating repositories!
pkg: Repository OPNsense cannot be opened. 'pkg update' required
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

Ive tested a few HTTPS mirrors and I get on all the same SSL problem. When I try to use a http one, everything seems to be fine. Did someone know how to resolve this?
#9
Hi mimugmail,

das bestätigt meinen Verdacht, die OPNsense wirft die Pakete nicht über das WG Interface. Als wenn Sie vergisst, dass Pakete aus dem IP Kreis über das Interface geroutet werden sollen.
#10
Hi,

das war auch mein Notfallplan. Ich habe so 20 externe Devices die per WireGuard angebunden sind und da läuft alles toll, deshalb wollte ich auch den VPS über WG anbinden. Ich verstehe das Problem halt nicht.
#11
Hallo zusammen,

ich habe hier ein wirklich merkwürdiges Problem. Ich habe auf meiner OPNsense zwei WireGuard Instanzen laufen. Die eine benutze ich von unterwegs mit diversen Geräten. Funktioniert 1a.

Die zweite Instanz bindet einen VPS als Client an. Jetzt kommt das merkwürdige:
Der VPS kann jederzeit beliebige Geräte im Netzwerk erreichen. Umgekehrt funktioniert es aber nur manchmal. Es kann sogar sein, dass ein Client aus dem internen Netz den VPS erreichen kann, ein anderer aber nicht. Im tcpdump auf dem VPS sehe ich auch nichts, wenn er nicht erreicht werden kann. Mir scheint das es ein Problem mit den routen gibt. Wenn ich ein traceroute von einem Client mache der den VPS erreicht wird im ersten Hop die Gateway Adresse der OPNsense angezeigt und im nächsten dann der VPS. Wenn ich das gleiche von einem Client mache der den VPS nicht erreicht wird auch als erster Hop die OPNsense angezeigt und danach läuft es sich tot oder er geht über ein falsches Gateway weiter.

Unter System -> Routes -> Status sehe ich auch eine Route zum Client. Ich verstehe nur nicht warum die anscheinend manchmal nicht genutzt wird.

Ich habe für die WireGuard instanz weder interface noch gateway angelegt. Müsste ich an dieser Stelle etwas tun? Wenn ja wie muss die konfiguration dafür aussehen?

Kann mir jemand einen Tipp geben wo ich weiter forschen soll?
#12
Hardware and Performance / SYS-E300-9D-4CN8TP
January 06, 2021, 09:14:23 AM
Hi all,

I'm looking for a new hardware for our OPNsense installation. I found a nice Supermicro Server and now I try to verify if the Hardware is supported. I'm talking about the SYS-E300-9D-4CN8TP. Here you can find a datasheet:

https://www.supermicro.com/en/products/system/Mini-ITX/SYS-E300-9D-4CN8TP.cfm

Did someone already use this an can confirm that everything works as expected? I really need the 10G connectivity which is my biggest concern about this.

Maybe there is even a better hardware out there? Can you recommend something?

#13
Hi,

wenn ich auf der 192.168.10.12 eine Route in das Netz 192.168.101.0/24 mit dem Gateway 192.168.10.1 setze funktioniert das ganze. Kann mir jemand erklären warum das nicht über die OPNsense funktioniert?
#14
Quote from: Gauss23 on December 07, 2020, 04:33:38 PM
Was ist denn LAN und LAN2? Also IP/Netzwerk?

Die Deny rule reagiert auf Interface LAN2 incoming mit Source 192.168.10.12 und dest 192.168.101.50.

Kann das überhaupt hinkommen?

LAN2 ist mein internes Netz mit dem IP Kreis 192.168.10.0/24. Das Netz 192.168.101.0/24 ist das Netz, dass über die IP 192.168.10.1 erreicht wird. Die Deny Meldung interpretiere ich so, dass die Antwort von der 10.12 zur 101.50 denied wird. Es scheint also so, dass die 101.50 das Paket richtig bei der 10.12 "abliefert" aber die Antwort dann nicht zurück kommt. Irre ich mich da?
#15
Hi, das andere Netz kennt die Route. Die beiden IP Adressen können sich auch gegenseitig pingen. Nur Dienste wie SSH funktionieren nur von meinem LAN zum entfernten.