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 - Nambis

#1
Moin,

ich habe ein kleines Problem mit einer Telefonanlage und einem Softphone (Client Telefonsoftware), wenn ich mich per VPN einwähle. Sporadisch scheint es zu funktionieren, aber dann gibt es immer wieder Verbindungsabbrüche, laut Hersteller Diagnose, wurde beim Support mitgeteilt, dass Datenpakete nicht korrekt am Client ankommen.

Folgendes Szenario:

Im lokalen Netzwerk selbst funktioniert alles so weit, allerdings über das VPN kommt es noch zu Problemen.

Netze:

Opnsense:

192.168.0.1
192.168.1.1
192.168.100.1

Telefonanlage:

192.168.1.100 (Standart-Gateway 192.168.1.10)
192.168.0.100

FritzBox:

192.168.1.10

VPN-Netz:

192.168.100.0




Firewall Konfiguration:

Ich habe eine NAT Regel erstellt, von Host 192.168.100.20 (VPN-Client) auf das Netz 192.168.1.0, die Software scheint sich damit mit der Anlage verbinden zu können. Allerdings vermute ich, dass die Telefonanalage stateless ebenfalls mit dem VPN Client kommunizieren möchte?

Nun meine Frage, sollte ich für die Telefonanlage (Ansitel) eine Route ins 100 er Netz geben oder reicht eine einfache FW- oder NAT-Regel dafür? Möglicherweise sollte die Verbindung von Telefonanlage zu Client Stateless sein?

Hoffe es könnte mir jemand einen Tipp geben, Danke im Voraus!
#2
Moin,

ich habe derzeit das Problem, dass sich meine Opnsense nicht mehr via PPPoE einwählt, wenn das Modem einen Verbindungsabbruch kurzzeitigen erhält.

Ist eine Telekom Business GF Leitung, letztens gab es bei einem Verteiler in unserer Nähe ein größeres Problem. Dieses Problem wurde zwar behoben, allerdings gibt es da alle paar Tage noch kleinere Aussetzer, ich vermute, das sind noch Nachwehen von der Großstörung.

Jetzt wollte ich mal Nachfragen, ist das ein Bug von Opensense, dass sich diese nicht automatisch wieder neu connected, oder habe ich da etwas falsch konfiguriert?

Ich muss halt immer einen Neustart machen, damit es wieder läuft, das kann es doch nicht sein?

Würde mich freuen, wenn sich der Sache jemand annehmen könnte, oder mir zumindest sagt, ob ich der Problemverursacher bin, durch eine falsche Config?


Nachtrag:

Das scheint tatsächlich ein Problem bei der Telekom zu sein, wenn ich manuell das Modem abstecke und wieder anstecke, tritt dieser Fehler nicht auf und Opensense macht die Einwahl, so wie es sein sollte.

Hatte von Euch schon jemand dasselbe Problem?
#3
Hallo,

nach dem ich nun auf 24.1 upgedatet habe, scheint es ein Problem mit Suricata zu geben. Vor dem Update hat es wunderbar funktioniert.

Jetzt scheint es so, als macht der IPS alles dicht, nach wenigen Minuten eines Neustarts. Nachdem ich Suricata deaktiviert habe, scheint alles wieder perfekt zu laufen, sprich ich komme in alle 4 LAN Netze und auch ins Internet. Mit aktivierten Suricata (und im Fehlerfall), kann ich zwar alles anpingen und auch DNS scheint zu funktionieren aber HTTP/HTTPS macht komplett dicht. Das heißt, ich komme weder auf das Web-GUI noch ins Internet noch sonst irgendwo hin via HTTP/HTTPS. Somit habe ich Suricata erstmal komplett deaktiviert, only IDS habe ich nicht getestet.

Mir fehlt gerade im Moment die Zeit für eine genauere Analyse, aber es wäre super, wenn sich das mal jemand aus dem DEV Team genauer anschauen möchte... Danke im Voraus!



#4
Hallo,

irgendwie habe ich das Problem, dass bei mir der Gateway (upstream) nicht als online angezeigt wird, wenn ich dort die Gateway-Überwachung aktiviere, obwohl das Gateway funktioniert und ich darüber hinaus ins Internet geroutet werde.

Wenn ich die Überwachung deaktiviere, wird er als online markiert. Eigentlich läuft alles, aber es wäre halt schön gewesen, wenn man sich den Status der PPPoE auf dem Dashboard anzeigen lassen könnte... Vielleicht jemand von euch eine Idee, ob ich eine Einstellung übersehen habe?
#5
Hello,

I've been dabbling a bit with Python and have developed a proxy environment with which traffic is first decrypted, inspected by an IPS, and then re-encrypted.

The whole scenario works by means of an SSL terminating proxy, which is connected upstream of the IPS, the downstream proxy2 independently establishes an HTTPS/SSL connection for example to a web server and transmits the data again unencrypted to proxy1.

With this configuration the data stream can be examined, I succeeded to detect Eicar which should be downloaded via HTTPS and to prevent the download automatically, by Suricata IPS.

This solution is still in alpha stage and there are still problems especially for SSL pinning, so not all websites can be accessed without further ado. Furthermore, there may be errors in the display of images, videos or other content.

Schema:




Proxy1 script:

import socket
import ssl
import threading

import subprocess
import os


IP = '0.0.0.0'
PORT = 3128

CERT_FILE = 'server.crt'
KEY_FILE = 'server.key'


PROXY2_IP = '192.168.1.212' 
PROXY2_PORT = 3128 

PROXY2_TIMEOUT = 60  # wait 60 sec.

BUFFER_SIZE = 8128

def handle_client(client_sock):
    try:

        request = client_sock.recv(BUFFER_SIZE)


        if request.startswith(b"CONNECT"):

            response = b"HTTP/1.1 200 Connection Established\r\n\r\n"
            client_sock.sendall(response)


            context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
            context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)
            secured_sock = context.wrap_socket(client_sock, server_side=True)

            request = secured_sock.recv(BUFFER_SIZE)
       

            print(request)


            proxy2_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            proxy2_sock.connect((PROXY2_IP, PROXY2_PORT))
            proxy2_sock.sendall(request)


            def forward_response_to_client():
                try:
                    while True:
                        data = proxy2_sock.recv(BUFFER_SIZE)
                        if not data:
                            break
                        secured_sock.sendall(data)
                except Exception as e:
                    print(f"[ERROR] {e}")


            threading.Thread(target=forward_response_to_client).start()

            proxy2_sock.settimeout(PROXY2_TIMEOUT)
        else:
            print("[ERROR] Unsupported request method!")
            client_sock.close()

    except socket.timeout:
        print("[ERROR] Timeout while waiting for a response from Proxy2.")


    except Exception as e:
        print(f"[ERROR] {e}")
        client_sock.close()



def main():

    domain = "example.com"
    ca_key = "myCA.key"
    ca_cert = "myCA.pem"


    server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

    server_sock.bind((IP, PORT))
    server_sock.listen(5)
    print(f"[INFO] Listening on {IP}:{PORT}")

    while True:
        client_sock, client_address = server_sock.accept()
        print(f"[INFO] Accepted connection from {client_address[0]}:{client_address[1]}")
        client_handler = threading.Thread(target=handle_client, args=(client_sock,))
        client_handler.start()

if __name__ == "__main__":
    main()



Proxy2 script:

import socket
import threading
import ssl

BUFFER_SIZE = 8128 #4096
PORT = 3128

def handle_client(client_sock, client_addr):
    try:
        request = client_sock.recv(4096).decode('utf-8')
        print(f"Received request:\n{request}")

        # Add the X-Forwarded-For header
        headers_end = request.find("\r\n\r\n")
        if headers_end != -1:
            request = request[:headers_end] + f"\r\nX-Forwarded-For: {client_addr[0]}\r\n" + request[headers_end:]


        lines = request.split('\r\n')
        domain = None
        for line in lines:
            if line.startswith("Host:"):
                domain = line.split()[1]
                break

        if not domain:
            print("[ERROR] Host header not found.")
            return

        context = ssl.create_default_context()
        with context.wrap_socket(socket.socket(socket.AF_INET, socket.SOCK_STREAM), server_hostname=domain) as server_sock:
            server_sock.connect((domain, 443))  # HTTPS-Port
            server_sock.sendall(request.encode())

            response = b""
            while True:
                chunk = server_sock.recv(BUFFER_SIZE)
                if not chunk:
                    break
                response += chunk

        print(f"Sending {len(response)} bytes back to Proxy1.")
        client_sock.sendall(response)

    except Exception as e:
        print(f"[ERROR] {e}")
    finally:
        client_sock.close()

def main(proxy_port):
    proxy_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    proxy_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    proxy_sock.bind(('0.0.0.0', proxy_port))
    proxy_sock.listen(5)

    print(f"Proxy 2 started on port {proxy_port}.")

    while True:
        client_sock, client_addr = proxy_sock.accept()
        threading.Thread(target=handle_client, args=(client_sock, client_addr)).start()

if __name__ == '__main__':
    proxy_port = PORT
    main(proxy_port)





To make the server certificate:

openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes



The certificate can also be produced differently, for initial testing purposes this should be sufficient...

My configuration:

Client: 192.168.0.34
Proxy1: 192.168.0.212

OPNsense: (IPS) 192.168.0.12
OPNsense: (IPS) 192.168.1.12

Proxy2: 192.168.1.212

Ok that with the gateway on in the net 192.168.1 I must look again more exactly, because in my constellation the traffic occurs then twice on the 192.168.1.12, this should be solved more elegantly

Ok an enterprise feature it is probably not yet, but I have the hope to find a better solution for it with the help of the community.

Even though SSL decryption has its drawbacks, I'm convinced that with the necessary caution it can add value.



#6
German - Deutsch / 2 Gateways - HA Konfiguration
May 28, 2023, 09:19:34 AM
Hallo,

ich habe versucht, in einer Testumgebung 2 Gateways zu nutzen. Per Default soll der Traffic nur über einen GW laufen und wenn dieser wegfällt, dann soll eben der zweite genutzt werden.

Was ich versucht habe war, die Gateways mit 1 und 2 zu priorisieren und anschließend in einer Gruppe zusammen zufassen.

Unter NAT habe ich beide eingetragen, mit den entsprechenden Interfaces, siehe Bild.

Komischerweise, erhalte ich dann, wenn ich das GW 2 deaktiviere eine seltsame Routenverfolgung:

VirtualBox:~$ traceroute google.de
traceroute to google.de (142.251.36.163), 30 hops max, 60 byte packets
1  opnsense-testing(192.168.0.202)  0.605 ms  0.747 ms  0.767 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * muc12s11-in-f3.1e100.net (142.251.36.163)  26.142 ms
VirtualBox:~$ traceroute google.de
traceroute to google.de (142.251.36.163), 30 hops max, 60 byte packets
1  opnsense-testing(192.168.0.202)  0.763 ms  0.906 ms  0.921 ms
2  10.10.10.1 (10.10.10.1)  15.049 ms  15.105 ms  15.129 ms
3  10.255.255.2 (10.255.255.2)  15.182 ms  15.214 ms  15.253 ms
4  93.90.196.12 (93.90.196.12)  15.452 ms 93.90.196.13 (93.90.196.13)  15.278 ms 93.90.196.12 (93.90.196.12)  15.488 ms
5  ae-0-0.bb-a.bap.rhr.de.net.ionos.com (212.227.121.4)  15.690 ms ae-16.bb-b.bs.kae.de.net.ionos.com (212.227.121.32)  16.843 ms ae-1-0.bb-a.bap.rhr.de.net.ionos.com (212.227.122.4)  15.484 ms
6  ae-10-0.bb-a.fra3.fra.de.net.ionos.com (212.227.120.146)  21.147 ms ae-9.bb-b.fr7.fra.de.net.ionos.com (212.227.120.169)  17.954 ms ae-10-0.bb-a.fra3.fra.de.net.ionos.com (212.227.120.146)  20.147 ms
7  212.227.112.63 (212.227.112.63)  18.700 ms  18.271 ms 212.227.112.83 (212.227.112.83)  19.919 ms
8  * * *
9  142.250.226.148 (142.250.226.148)  17.983 ms 142.250.46.248 (142.250.46.248)  18.033 ms 142.250.226.148 (142.250.226.148)  16.823 ms
10  108.170.251.208 (108.170.251.208)  24.187 ms 108.170.252.82 (108.170.252.82)  20.433 ms 108.170.252.83 (108.170.252.83)  18.706 ms
11  209.85.241.71 (209.85.241.71)  24.574 ms 209.85.241.231 (209.85.241.231)  24.329 ms 108.170.228.9 (108.170.228.9)  19.535 ms
12  142.250.46.171 (142.250.46.171)  26.597 ms 142.250.46.105 (142.250.46.105)  23.139 ms 209.85.241.43 (209.85.241.43)  26.321 ms
13  172.253.72.248 (172.253.72.248)  24.569 ms 108.170.233.58 (108.170.233.58)  23.545 ms 216.239.62.242 (216.239.62.242)  23.123 ms
14  74.125.244.81 (74.125.244.81)  21.668 ms 74.125.244.97 (74.125.244.97)  25.734 ms 74.125.244.81 (74.125.244.81)  21.681 ms
15  142.251.68.125 (142.251.68.125)  25.501 ms 142.251.68.123 (142.251.68.123)  21.359 ms  24.545 ms
16  muc12s11-in-f3.1e100.net (142.251.36.163)  24.321 ms  25.566 ms  26.022 ms



Für die Testumgebung habe ich einfach auf einer virtualisierten Opensense, ein VPN zu einer VPS aufgebaut und diese Verbindung als GW eingetragen.

Auf der VPS scheint der Trace normal zu funtkionieren:

Quoteroot@localhost:~# traceroute google.de
traceroute to google.de (172.217.18.3), 30 hops max, 60 byte packets
1  10.255.255.2 (10.255.255.2)  0.126 ms  0.093 ms  0.095 ms
2  93.90.196.12 (93.90.196.12)  0.762 ms 93.90.196.13 (93.90.196.13)  0.782 ms  0.765 ms
ae-17.bb-b.bs.kae.de.net.ionos.com (212.227.122.31)  1.951 ms ae-16.bb-b.bs.kae.de.net.ionos.com (212.227.121.32)  1.825 ms ae-17.bb-b.bs.kae.de.net.ionos.com (212.227.122.31)  1.951 ms
ae-9.bb-b.fr7.fra.de.net.ionos.com (212.227.120.169)  3.716 ms ae-10-0.bb-a.fra3.fra.de.net.ionos.com (212.227.120.146)  6.381 ms  6.375 ms
5  212.227.112.83 (212.227.112.83)  5.811 ms  4.679 ms 212.227.112.63 (212.227.112.63)  5.000 ms
6  * * *
7  142.250.62.150 (142.250.62.150)  3.356 ms 108.170.252.65 (108.170.252.65)  5.846 ms 142.250.62.150 (142.250.62.150)  3.329 ms
8  172.253.66.137 (172.253.66.137)  5.018 ms  6.584 ms 108.170.251.208 (108.170.251.208)  3.729 ms
9  * 108.170.229.168 (108.170.229.168)  7.068 ms fra15s28-in-f3.1e100.net (172.217.18.3)  3.175 ms
root@localhost:~# ping 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=11.9 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=13.0 ms
^C
--- 10.10.10.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 11.930/12.481/13.032/0.551 ms



Warum erhalte ich diese komische Trace, wenn ich die VPN trenne?

traceroute google.de
traceroute to google.de (142.251.36.163), 30 hops max, 60 byte packets
1  opnsense-testing.niedata (192.168.0.202)  0.605 ms  0.747 ms  0.767 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * muc12s11-in-f3.1e100.net (142.251.36.163)  26.142 ms



Weil wenn ich von meiner Workstation ebenfalls über diesen Gateway gehe, läuft alles ganz normal:

Routenverfolgung zu google.de [142.251.36.163]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  opnsense.niedata [192.168.0.12]
  2     2 ms     2 ms     2 ms  62.156.244.4
  3     4 ms     3 ms     3 ms  62.156.246.74
  4     3 ms     3 ms     3 ms  m-ef1-i.M.DE.NET.DTAG.DE [62.154.28.70]
  5     2 ms     2 ms     2 ms  80.157.129.174
  6     4 ms     4 ms     4 ms  172.253.78.199
  7     3 ms     3 ms     2 ms  142.251.68.125
  8     2 ms     2 ms     2 ms  muc12s11-in-f3.1e100.net [142.251.36.163]

Ablaufverfolgung beendet.



Netzwerkplan:

                         LAN-TELEFON -> Fritzbox -> IP-Telefone
                            |
  Internet ->  GF Sense -> LAN -> Clients + Drucker + Server
                            |
                           WAN -> Virtualisierte Opensense + Server
 
Braucht man einen bestimmten Port für die Routenverfolgung?

Vielleicht hat jemand ne Idee, würde mich freuen, Danke im Voraus!

Grüße


EDIT:

Wenn ich auf WAN über die FW Regeln, alles erlaube, dann macht der Traceroute keine Probleme, unabhängig welcher GW aktiv ist... jetzt frage ich mich, welche Ports sollte ich öffnen? ICMP ist eigentlich schon auf, für jegliche ICMP-Typen ... ???


EDIT II:

Ok, habs rausgefunden:

QuoteDie Standard-Unix-Version von traceroute verwendet UDP-Pakete, die an hohe, unbenutzte Ports gesendet werden, typischerweise beginnend mit Port 33434. Für jede zusätzliche (hop) wird der Port um 1 erhöht.

Das heißt, damit funktioniert der Traceroute:

IPv4 UDP * * * 33434 - any * *


#7
Hallo,

seit dem vorletzten Update, Anfang Mai, habe ich mit Suricata das Problem, dass CPU Auslastung extrem hoch ist.

Früher gab es kurzzeitig auch mal Peaks aber wie gesagt, bleibt die Auslastung dann bei ca. 70 %. Ist ein Quadcore Xeon mit 3,4 GHZ, normalerweise sollte das nicht so extrem sein?

Hat dazu jemand ne Idee? Oder kommt evtl. bald ein Update?

Würde mich über Infos und Hilfe freuen.

Grüße


Edit:

Das Problem tritt nur auf, wenn ich zum Beispiel ein Interface deaktiviere und anschließend wieder aktiviere.
#8
German - Deutsch / openVPN
May 26, 2023, 12:48:05 AM
Hallo,

ich bekomme openVPN nicht zum Laufen, egal was ich versuche. Need help, pls.

Ich habe es nach Anleitung konfiguriert "https://www.thomas-krenn.com/de/wiki/OPNsense_OpenVPN_f%C3%BCr_Road_Warrior_einrichten#Firewall_Regeln_f.C3.BCr_OpenVPN_erstellen", die Zertifikate generiert alles wie beschrieben und es funktioniert nichts...

Da ich jetzt schon von einigen Leute hier gelesen habe, dass es da anscheinend Probleme gibt, wollte ich nachfragen, welche Alternativen es auf der Sense zu openVNP und IPSec sonst so gibt? Speziell für eine Roadwarrior Konfiguration.

Oder kennt jemand von euch ein Tutorial, was mit der aktuellen Version von OpenVPN welches auf der Sense mit ausgeliefert wird zum Erfolg führt?

Würde mich über Hilfe freuen!

#9
Ich verstehe nicht, warum das nicht richtig durchläuft, habe jetzt schon verschiedene Spiegelserver ausprobiert, liegt das an mir oder den Servern? Laut DNS (Pihole) scheint es keine Probleme zu geben... hat jemand eine Idee und welche nicht Business Spiegelserver, könnt ihr, empfehlen?

Laut System bin ich schon bei 23.1.1, aber irgendwas fehlt ihm noch... base-23.1.1?
#10
Irgendwie scheint das "mimugmail" repository nicht erreichbar zu sein!?

Updating mimugmail repository catalogue...
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/meta.txz: Not Found
repository mimugmail has no meta file, using default settings
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/packagesite.pkg: Not Found
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/packagesite.txz: Not Found
Unable to update repository mimugmail
Error updating repositories!
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***


Edit:

Hups, gibts schon nen Thread dazu: https://forum.opnsense.org/index.php?topic=31520.0
sry!
#11
Moin,

keine Ahnung, was da jetzt nicht passt, aber ich komme seit einiger Zeit nicht mehr auf Github, vor allem was mich irritiert ist, die Blockliste die ich beim Firehol Alias eingegeben hatte, ist von raw.githubusers ... kapiere es nicht?

Ausschnitt von der Live Ansicht des FW Protokoll

LAN      2022-11-26T19:07:46   192.168.0.24   140.82.121.4   icmp   FireHOL3

Weder Ping noch logischerweise eine Seite Aufruf von Github.com ist möglich:
Beim Verbinden mit github.com trat ein Fehler auf.

Zum testen habe ich die FW regel deaktiviert, welche unter LAN eingehend konfiguriert wurde, wo mit ich github.com wieder erreiche, ja ok ist logisch aber was soll ich machen um Firehol3 und github verwenden zu können?


Was sollte ich machen, einen Alias von Github anlegen und diesen per Regel erlauben?

Nachtrag:

Manchmal funktioniert github und dann wieder nicht, scheint so, als würden dort von manchen Spiegelserver die IP's geblockt.

Wie kann ich nen Domain Alias machen auf Github welcher nie geblockt wird?



$ ping github.de
PING github.de (140.82.113.17) 56(84) bytes of data.
64 bytes from lb-140-82-113-17-iad.github.com (140.82.113.17): icmp_seq=1 ttl=50 time=112 ms
64 bytes from lb-140-82-113-17-iad.github.com (140.82.113.17): icmp_seq=2 ttl=50 time=112 ms
^C
--- github.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 111.560/111.987/112.415/0.427 ms


$ ping github.com
PING github.com (140.82.121.3) 56(84) bytes of data.
^C
--- github.com ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8189ms


Nachtrag:

Mit dem github.com Alias funktioniert es nicht?
#12
Moin,

irgendwie dauert das Laden des Dashboards relativ lange, ca. 10 sek., ging früher gefühlt viel schneller. Glaube kaum, dass es an der Hardware liegt.

Xeon-D 4 Core 3,4 GHz
32 GB RAM
NVME Festplatte

Hat jemand von euch ähnliche Effekte oder ist das sogar normal?
#13
German - Deutsch / Frage zu DHCP
October 18, 2022, 07:59:30 PM
Hi,
wie lange dauert bei Euch eine Zuweisung der Client IP mittels DHCP? Bei mir wird DHCP als Dienst von der Opnsense gehostet. Seit dem letzten oder vorletzten Update dauert die Zuweisung der IP an den Clients länger. Sind zwar nur 10 Sekunden oder 15, aber komischerweise hatte ich vor den letzten Updates immer innerhalb von 4- 5 Sekunden die Zuweisung. An den DHCP Einstellungen wurde nichts geändert. Woran könnte es liegen?

Auch wenn es lächerlich erscheint, fand ich es besser, als die Zuweisung noch schneller ging.
#14
Moin,

was ich fragen wollte ist, was ist der beste Weg, zwei oder drei verschiedene Subnetze miteinander zu verknüpfen routen?

Ich hatte letztens versucht, LAN und OPT1 über Opnsesnse zusammenzubringen, allerdings lief das nicht ganz so reibungsfrei, wie ich es gerne gehabt hätte. Die Schnittstellen LAN und OPT1 habe ich dabei direkt auf einen L2 Switch ohne VLAN gegeben und mit 192.168.0 und 192.168.1 für die jeweiligen Netze konfiguriert.

Dann noch jeweils eine FW Regel für LAN und OPT1, welche den eingehenden Traffic  ins jeweilige Netz erlaubt, von einer beliebigen Quelle. Letzten Endes  konnte ich von LAN auf OPT1 zu greifen, andersherum gab es teilweise Probleme, das zB. manche Hosts nicht gefunden wurden usw... Auch mit asynchronen TCP Verbindungen gab es Schwierigkeiten, so musste Statustyp auf sloppy-status gesetzt werden.

War auch nur testweise und keine dauerhafte Konfiguration. Nun meine eigentliche Frage ist, gibt es dafür einen eleganteren Weg, separate Router-Hardware oder L3 Switche vielleicht?

Wie würdet Ihr das professionell lösen, wenn mehrere Subnetze miteinander verbunden werden sollen, damit eine reibungsfreie Kommunikation zwischen den Netzen in beiden Richtungen funktioniert?
#15
Moin,

nach dem letzten größeren Update habe ich festgestellt, dass ich die internen Hostnames nicht mehr nach ihrer IP auflösen kann, was vorher aber ohne Probleme funktioniert hat.

ZB.: nslookup 192.168.0.16 liefert "*** 192.168.0.16 wurde von opnsense.xyz nicht gefunden: Non-existent domain."

Andersherum können die IP-Adressen nach Hostnames aufgelöst werden. Für die Hosts welche über DHCP ihre IP Konfiguration erhalten, funktionieren so weit ich das sehe, beide Richtungen.

An den Einstellungen habe ich nichts geändert. Hat sich da bei Unbound etwas verändert, die Einstellungen sehen immer noch gleich aus?

Vielleicht weiß hier jemand mehr, eine schnelle Suche hat mich jedenfalls nicht weiter gebracht.

Edit:

Aus der Protokoll Datei werde ich auch nicht schlau:

[66018:0] info: 192.168.0.34 16.0.168.192.in-addr.arpa. PTR IN
#16
German - Deutsch / Neue Features für die Opnsense?
June 15, 2022, 09:12:43 PM
Hi,

an wen kann man sich wenden bzw. wo finde ich Leute, die an Opnsense entwickeln und ich gerne neue Funktionen hätte, also natürlich vorausgesetzt den Fall, dass mein Feature überhaupt machbar, zeitlich für die Developer umsetzbar und für die Community interessant wäre?

Ein Link wäre hilfreich, vielen Dank im Voraus!
#17
Hi,

ich habe einen Lokalen Host (192.168.0.xyz) zu einer selbst erstellten Blockliste hinzugefügt unter Aliase und anschließend auf speichern und dann anwenden geklickt, danach war die Sense nicht mehr erreichbar, kein Web-Interface und Ping möglich.

Auf der IPMI Console ist, wie im folgenden Bild zu sehen, diese Ausgabe ständigen im Loop durchgelaufen. Nach einem Neustart läuft das System wieder normal, evtl. ein Bug?

Ah genau, unter dem einen Alias habe ich noch zusätzlich Statistiken aktiviert, keine Ahnung, ob da irgendwas durcheinander gekommen sein könnte?

Edit:
Was mir auch noch eingefallen ist, nach dem ich letzte Woche Sensei installiert und konfiguriert habe, hatte ich ein ähnliches Problem, es scheint fast so, als würden die Ethernet Adapter down gehen und nicht wieder hochfahren. Also etwas simplifiziert ausgedrückt.

Vielleicht weiß jemand, was das sein könnte?

(Ich hoffe das es evtl. mit dem nächsten Update weggeht)
#18
German - Deutsch / Verständnisfrage zu DNSSEC
May 19, 2022, 02:14:32 PM
Hallo,

reicht es eigentlich bei den Resolvern DNSSEC zu aktivieren oder muss es dies ebenfalls beim Forwarder aktiviert sein, damit der DNS Request nach draußen sicher ist?

Meine Senese ist quasi der Forwarder und alle DNS Anfragen vom Port 53 und TLS 853? werden an die Sense Redirected. Es ist soweit ich weiß, aktuell noch nicht möglich via DoH oder TLS DNS Anfragen an die ROOT DNS-Server zu stellen. DNSSEC ist zwar auch keine Verschlüsselung, aber so wie ich es verstanden habe, ein Sicherheitsfeature, was dafür sorgt, dass keine falschen Informationen in die DNS Anfrage bzw. Datenpakete durch MITM injektet werden können? Insofern ich das richtig verstanden habe...

Wie kann ich es testen, normalerweise erhalte ich vom Win10 Client, nicht autorisierte Antwort, mittels nslookup. Am Forwarder also der Sense ist DNSSEC aktiviert und einmal PiHole und Adguard welche als recursive DNS Server arbeiten als Standart DNS Server konfiguriert.

Sowohl am Pihole als auch Adguard ist DNSSEC aktiviert. Würde mich freuen wenn mir das jemand kurz erklären könnte wo mein Fehler liegt, Danke!

Edit:
Ok, DNSSEC scheint zu funktionieren, das hat nichts mit "Nicht autorisierende Antwort:" zu tun. Laut dieser Seite https://dnssec.vs.uni-due.de/ scheint DNSSEC zu funtkionieren. Aber eine Sache die ich nicht verstehe ist, warum erhalte ich dann am Pihole direkt "Nicht autorisierende Antwort:", dort sollte doch unboun direkt als resolver bei den ROOT Servern abfragen?

/etc/unbound/unbound.conf.d/server.conf

auth-zone:
name: "."
primary: 199.9.14.201       # b.root-servers.net
primary: 192.33.4.12        # c.root-servers.net
primary: 192.112.36.4       # g.root-servers.net
primary: 2001:500:200::b    # b.root-servers.net
primary: 2001:500:2::c      # c.root-servers.net
primary: 2001:500:12::d0d   # g.root-servers.net
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: /var/lib/unbound/root.zone


Edit2:

Ok, jetzt kapiere ich das, wenn der DNS Eintrag nicht direkt im übergeordneten Zonen Domain Server liegt, wäre das eine "Nicht autorisierende Antwort". zum Beispiel ist google.de im domain Server ns1.google.com registriert, wenn dort direkt angefragt wird, wird nur die IP zurückgegeben ohne "Nicht autorisierende Antwort".

Hat sich dann erledigt, sorry für die dumme Frage ;-)
#19
Sunny Valley's website says that it is yet to be implemented, when can we expect it?

Such a function would probably make sense nowadays, since as we all know, the majority of traffic is now encrypted.
#20
Hi,
whenever i try to change the retention of the log data, for example from 7 to 5 days, then the lan and wan nic are on down ... also with other changes of the configuration this problem occurs

Only by a hardware reset the system can be restarted and reached in the network.

It is the current version of sensei (zenamor) incl. home subscription installed.

Maybe someone already had the same problem, apart from that, sensei seems to run error free on my system?