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

Topics - murmelbahn

#1
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
#2
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
#3
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.
#4
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?
#5
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?
#6
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?

#7
Hallo,

ich habe ein Problem zu dessen Lösung ich einen Denkanstoss benötige. Ich habe ein LAN Netz auf meiner Opensense. Über eine IP
dieses Netzes ist es möglich ein weiteres Netz zu erreichen. Damit ich dieses Netz erreichen kann habe ich ein zuerst ein neues
Gateway angelegt welches das gleiche Interface benutzt wie das reguläre LAN. Als nächstes habe ich dann eine Route angelegt, die
das entfernte Netz über dieses Gateway erreichbar macht. Ich kann jetzt auch toll hin und her Pingen, das funktioniert super.
Ich kann auch aus meinem LAN auf jeden Port in das entfernte Netz zugreifen. Leider funktioniert das ganze aber nicht umgekehrt.
Wenn ich beispielsweise eine SSH Session aus dem entfernten Netz auf eine IP im internen Netz machen möchte bekomme ich eine Fehlermeldung
im Log zu sehen. Die Fehlermeldung hänge ich euch an. Falls ich SSH von meinem Netz in das entfernte Netz machen möchte funktioniert das
ohne Probleme. Ich vermute das hat irgendwas mit den NAT Einstellungen zu tun. Leider finde ich da aber keine Lösung.
Kann mir jemand einen Tipp geben?


Hier ein kleines Diagramm dazu.


      .-----+------. Gateway         .-----------------.
      |  OPNsense  +-----------------+ entferntes Netz |
      '-----+------'   192.168.10.1  '-----------------'
            |                         192.168.101.0/24
        LAN | 192.168.10.2/24 (.2 ist die IP der OPNSense)
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------... (Clients/Servers)

#8
Hi all,

I have a little problem with my WireGuard setup. All my clients are connected to my OPNsense Server and can access everything on the OPNsense side. I have one Debian client which I want to access from the OPNsense side.
Sadly I don't know how to archieve this. Basicly I want to use the VPN to "both" sides.
Can someone give me a hint how to configure this? When I try to ping the VPN IP of the Debian client (100.65.1.2) from the OPNsense it does not send the packages through the tunnel.

€: Has to add the VPN Network (100.65.1.0/24) to the allowed IPs of the client.
#9
German - Deutsch / Split-DNS Probleme
July 02, 2020, 03:07:42 PM
Hallo zusammen,

ich habe da ein kleines Problem mit der OPNsense. Ich benutz HAProxy mit Let's Encrypt Zertifikaten um einige Dienste von außen zu erreichen. Bevor ich das ganze mit der OPNsense gemacht habe, habe ich einen Nginx Reverse Proxy auf einer VM benutzt. Damit ich sowohl von intern als auch von extern auf die diversen Dienste zugreifen kann hatte ich immer ein Split-DNS laufen. In meinem internen DNS Server hatte ich dann Einträge wie:

extern.url.tld -> 1.2.3.4

Wobei 1.2.3.4 die IP des Reverse Proxy war. Auf der OPNsense war dann einfach ein NAT von 443 bzw 80 auf die 1.2.3.4. Jetzt wollte ich einfach nur die 1.2.3.4 durch die interne IP meiner OPNsense ersetzen. Leider funktioniert das ganze nicht so wie gedacht:D Ich kenne das Problem bei Watchguard Firewalls, da musste man dann an den NAT Settings drehen, Stichwort "Hairpinning". Leider hab ich keine Ahnung wie ich das in OPNsense umsetzen muss. Hat da jemand vielleicht einen Tipp für mich?

Vielen Dank im Vorraus.
#10
Hi all,
I'm using Mullvad VPN like descriped here:

https://forum.opnsense.org/index.php?topic=15105.0

I have a few VM's, Windows and Debian. I can assign default gateways in the firewall rules.  It seems like they are using it to a half. When I ran apt update they didn't get any files from the servers but each time it is another server. Other Services like SABNZBD on the same maschine are working fine. Sometimes I get a timeout, sometimes websites are loading. Continuously pings are working. Sometimes the ping doenst get "through" at the first try but when i try it again its running. I really don't know where to look at. Can someone give me a hint?
Thanks!
#11
Hi all,

I'm using a WireGuard VPN to Mullvad. If configured an interface and a gateway for this. I've created a rule for a alias to use the WireGuard gateway. This works fine for me. The next step would ne to deny internet access for the alias if the interface is down. I've created a second rule to deny any traffic. But this sadly doenst work. Attached is a screenshot which shows the rules for my lan. Maybe someone can help me to configure this correct.

Thanks in advance!
#12
Hallo liebe community,

ich nutze die OPNsense Firewall auf meinem ESXi 6.7, Netzwerkkarten sind wie in der Doku empfohlen auf E1000 gestellt. Leider habe ich das Problem, das Regeländerungen an Firewall erst greifen wenn ich die VM einmal neustarte. Das ist im Betrieb natürlich eher unschön. Hat einer eine Idee woran das liegen könnte?

Vielen Dank!
#13
Hallo zusammen,

ich habe hier ein Problem das mich schon ewig beschäftig und ich finde einfach keine Lösun
g.
Im Grunde genommen möchte ich das Geräte aus zwei unterschiedlichen Interfaces miteinander sprechen.

Folgender Aufbau:

OPNSense:
Interface WLAN (VLAN1 auf den Switches), dahinter Unifi Access Points
Interface LAN -> Geht direkt in den Switch ist das default VLAN.

Ich möchte nun, dass die Geräte aus dem WLAN und dem normalen LAN miteinander sprechen.

Wenn ich ein Windows 10 Client in das WLAN hänge erreiche ich diesen leider nicht.
Wenn ich ein tracert beim Windows 10 Client mache sehe ich, dass die OPNSense die Anfragen an das LAN Netz einfach in das Internet bläst und nicht an das Interface in dem Netz vom LAN.

Hat einer eine Idee was ich tun kann?

Edit: Nochmal ein Diagram:


      WAN / Internet
            :
            : Fibre
            :
      .-----+-----.
      |  Fritzbox  | 
      '-----+-----'
            |
        WAN | IP
            |
      .-----+------.   WLAN           .------------.
      |  OPNsense  +-----------------+ DMZ-Server |
      '-----+------'   10.15.0.0/16   '------------'
            |
        LAN | 192.168.10.0/24
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------... (Clients/Servers)
#14
Hey all,

I have a little question. I've configured my OPNSense to use Mullvad VPN service. I was using the following guide:
https://docs.opnsense.org/manual/how-tos/wireguard-client-mullvad.html

Now all my clients are using the VPN connection to Mullvad but I want only one client to use this connection. When the VPN is down the client shouldnt be allowed to use the internet at all. The last sentence in the manual says the following:
Quote
When assigning interfaces we can also add gateways to them. This would offer you the chance to balance traffic via different VPN providers or do more complex routing scenarios.

I think something like this is needed for me? Like IP 1.2.3.4 only use Gateway Mullvad VPN without failover and all the others using the default WAN gateway?

Maybe someone can give me a hint to handle this situation?
#15
Hi all,

at home I have only one dynamic IP adaress. As today I'm using multiple cnames on a duckdns entry. I'm forwarding port 80 and 443 to a NGINX reverse proxy. My question is if it is possible to use a SSL VPN with port 443 and also using my current setup? I think the OPNsense should must take a look at the domain name for example vpn.domain.tld and decide if it should answer a VPN or a web access.

Thanks in advance.
#16
General Discussion / Problems with NAT in S2S VPN
June 04, 2019, 05:00:07 PM
Hello all,

I have a problem NAT in a side 2 side VPN.

My local network at the OPNsense is:

192.168.178.0/24

I'm using 3 tunnels in the second phase of my IPSec VPN. Each one is
on my side for one IP and on the other side for a whole network:

192.168.11.1/32 to 192.168.211.0/24
192.168.11.2/32 to 192.168.211.0/24
192.168.11.3/32 to 192.168.211.0/24

Because the network 192.168.178.0/24 is already in use at the remote side,
Im using the 192.168.11.1, 11.2 and 11.3.

In the configuration for Phase 2 in the OPNsense I've created a
"Manual SPD" entrie in each of the tunnels:

In 192.168.11.1/32 -> Manual SPD = 192.168.178.1/32
In 192.168.11.2/32 -> Manual SPD = 192.168.178.2/32
In 192.168.11.3/32 -> Manual SPD = 192.168.178.3/32

On the remote side the tunnel configurations looks like this:

192.168.11.1/32 to 192.168.211.0/24
192.168.11.2/32 to 192.168.211.0/24
192.168.11.3/32 to 192.168.211.0/24

I have two problems with this setup.

1: How can i tell the OPNsense firewall to rewrite outgoing packages from .178 to .11?
2: How can i tell the OPNsense firewall to rewrite ingoing packages from .11 to .178?

I've found the this:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html#

I've tried all possible settings in the One-to-One Nat but
it doesnt work:(

Can someone give me a hint what I have to do?

Thanks in advance
#17
Hallo zusammen,

ich habe ein Problem mit dem NAT von einem Side 2 Side VPN:

Lokales Netz an der OPNsense ist:

192.168.178.0/24

In Phase 2 des VPNs gibt es 3 Tunnel die jeweils eine einzelne lokale IP
enthalten:

192.168.11.1/32 darf auf 192.168.211.0/24
192.168.11.2/32 darf auf 192.168.211.0/24
192.168.11.3/32 darf auf 192.168.211.0/24

Die .178 kann ich im Tunnel nicht benutzen da das Netz bei der Gegenseite
schon anderweitig in Verwendung ist. Ich habe deshalb die .11 gewählt. In
der Phase 2 auf der OPNsense habe ich dann pro Tunnel jeweils in Manual SPD entries
die .178 IPs eingetragen.

Im Tunnel der Gegenseite steht dann:

192.168.11.1/32 darf auf 192.168.211.0/24
192.168.11.2/32 darf auf 192.168.211.0/24
192.168.11.3/32 darf auf 192.168.211.0/24


Ich müsste jetzt ja eigentlich der OPNsense sagen, dass Sie
a) ausgehende Pakete aus .178 die in den Tunnel gehen mit .11 umschreibt
b) eingehende Pakete die an .11 adressiert sind an .178 umschreibt

Ich habe versicht unter Firewall -> NAT -> One-to-One Einstellungen
nach dem Beispiel von hier:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html#
Vorzunehmen, bekomme aber leider keinen Traffic durch den Tunnel.
Aufgebaut sind die Tunnel aber, es scheitert leider nur am NAT.
Kann mir einer von euch da vielleicht weiterhelfen?

Danke und viele Grüße
#18
Hallo zusammen,

ich habe ein merkwürdiges Problem bei einem Side2Side IPSec VPN zu einer Watchguard.
Ich habe mehrere Phase 2 Tunnel auf beiden Seiten eingetragen, leider
ist aber immer nur der Tunnel, der als erstes im OPNsense eingetragen ist
der aktive Tunnel. Alle anderen Tunnel werden nicht aufgebaut.
Weiß jemand in welchem Log ich das Loglevel ändern muss um zu sehen
was passiert bzw was nicht passiert? Hat vielleicht jemand eine Idee
woran es liegen könnte?