Messages

Ich vermute mal, dass es wohl nichts mit OPNsense zu tun hat! Das liegt sehr wahrscheinlich an der schlechten WLAN Verbindung des Clients. Anscheinend ist das ziemlich grenzwertig vom Empfang her, aktuell funktioniert es aber wieder recht zuverlässig.

Hallo,

ich habe ein Problem mit einem Client (IoT Modul) der immer wieder keine IP vom DHCP bekommt bzw. anscheinend die DHCPOFFER nicht angenommen wird. Im Log steht folgendes:

2021-12-27T19:16:30   dhcpd[72917]   DHCPOFFER on 10.10.1.88 to dc:4f:22:d5:78:b2 (schuppen) via vtnet0
2021-12-27T19:16:30   dhcpd[72917]   DHCPDISCOVER from dc:4f:22:d5:78:b2 (schuppen) via vtnet0
2021-12-27T19:16:30   dhcpd[72917]   reuse_lease: lease age 17 (secs) under 25% threshold, reply with unaltered, existing lease for 10.10.1.88
2021-12-27T19:16:15   dhcpd[72917]   DHCPACK on 10.10.1.88 to dc:4f:22:d5:78:b2 (schuppen) via vtnet0
2021-12-27T19:16:15   dhcpd[72917]   DHCPREQUEST for 10.10.1.88 (10.10.1.246) from dc:4f:22:d5:78:b2 (schuppen) via vtnet0
2021-12-27T19:16:15   dhcpd[72917]   reuse_lease: lease age 2 (secs) under 25% threshold, reply with unaltered, existing lease for 10.10.1.88
2021-12-27T19:16:13   dhcpd[72917]   DHCPACK on 10.10.1.88 to dc:4f:22:d5:78:b2 (schuppen) via vtnet0
2021-12-27T19:16:13   dhcpd[72917]   DHCPREQUEST for 10.10.1.88 (10.10.1.246) from dc:4f:22:d5:78:b2 via vtnet0
2021-12-27T19:16:13   dhcpd[72917]   DHCPOFFER on 10.10.1.88 to dc:4f:22:d5:78:b2 via vtnet0
2021-12-27T19:16:13   dhcpd[72917]   DHCPDISCOVER from dc:4f:22:d5:78:b2 via vtnet0
2021-12-27T19:15:51   dhcpd[72917]   DHCPOFFER on 10.10.1.88 to dc:4f:22:d5:78:b2 via vtnet0
2021-12-27T19:15:51   dhcpd[72917]   DHCPDISCOVER from dc:4f:22:d5:78:b2 via vtnet0
2021-12-27T19:15:49   dhcpd[72917]   DHCPOFFER on 10.10.1.88 to dc:4f:22:d5:78:b2 via vtnet0
2021-12-27T19:15:49   dhcpd[72917]   DHCPDISCOVER from dc:4f:22:d5:78:b2 (schuppen) via vtnet0

Die oberen drei Zeilen wiederholen sich ständig und müllen das Log total zu. Der Rest im Netz hat kein Problem mit DHCP. Hat hier der IoT Client ein Problem oder kann man da evtl. noch was am DHCP feintunen? So wie ich das Log verstehe, macht der Client einfach kein DHCPACK, akzeptiert diese Adresse also nicht oder?

Hallo,

ich kämpfe aktuell mit dem exakt gleichen Problem und der gleichen Logausgabe:

Code Select Expand


2021-10-09T09:20:26 charon[79660] 13[JOB] <con1|3> deleting half open IKE_SA with 80.187.106.185 after timeout
2021-10-09T09:20:17 charon[79660] 13[IKE] <con1|3> sending keep alive to 80.187.106.185[7116]
2021-10-09T09:19:56 charon[79660] 11[NET] <con1|3> sending packet: from ...........[4500] to 80.187.106.185[7116] (500 bytes)
2021-10-09T09:19:56 charon[79660] 11[NET] <con1|3> sending packet: from ..............[4500] to 80.187.106.185[7116] (1236 bytes)
2021-10-09T09:19:56 charon[79660] 11[ENC] <con1|3> generating IKE_AUTH response 1 [ EF(2/2) ]
2021-10-09T09:19:56 charon[79660] 11[ENC] <con1|3> generating IKE_AUTH response 1 [ EF(1/2) ]
2021-10-09T09:19:56 charon[79660] 11[ENC] <con1|3> splitting IKE message (1664 bytes) into 2 fragments
2021-10-09T09:19:56 charon[79660] 11[ENC] <con1|3> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
2021-10-09T09:19:56 charon[79660] 11[IKE] <con1|3> sending end entity cert ...........
2021-10-09T09:19:56 charon[79660] 11[IKE] <con1|3> authentication of '................' (myself) with RSA signature successful
2021-10-09T09:19:56 charon[79660] 11[IKE] <con1|3> peer supports MOBIKE
2021-10-09T09:19:56 charon[79660] 11[IKE] <con1|3> initiating EAP_IDENTITY method (id 0x00)
2021-10-09T09:19:56 charon[79660] 11[CFG] <con1|3> selected peer config 'con1'

Vielleicht kann mir hier jemand weiterhelfen bzw. TO einen Tip geben?

Ach ja: vom Handy aus geht das VPN problemlos!

Gruß

Erledigt  :D

Ich muss als Benutzer natürlich den nehmen, der unter Pre-Shared Keys hinterlegt ist! Ich hab einen "normalen" OPNsense User genommen  ::)

Hallo zusammen,

ich versuche seit ein paar Tagen, IPsec einzurichten um es am (Android) Handy nutzen zu können. Die strongSwan App versucht einen Connect und sagt dabei immer: Benutzerauthentfizierung ist fehlgeschlagen.
Das Log der OpnSense sieht so aus:

2021-10-05T16:01:50   charon[78707]   11[IKE] <con1|20> EAP-MS-CHAPv2 verification failed, retry (1)   
2021-10-05T16:01:50   charon[78707]   11[IKE] <con1|20> no EAP key found for hosts 'hier steht mein servername' - 'vpn'   
2021-10-05T16:01:50   charon[78707]   11[ENC] <con1|20> parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]   
.
.
.
2021-10-05T16:01:50   charon[78707]   11[ENC] <con1|20> generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]   
2021-10-05T16:01:50   charon[78707]   11[IKE] <con1|20> initiating EAP_MSCHAPV2 method (id 0x3D)   
2021-10-05T16:01:50   charon[78707]   11[IKE] <con1|20> received EAP identity 'vpn'   
2021-10-05T16:01:50   charon[78707]   11[ENC] <con1|20> parsed IKE_AUTH request 2 [ EAP/RES/ID ]

Jemand ne Idee wo das Problem liegen könnte? Der Benutzer ist natürlich an der OpnSense vorhanden, muss man dem irgendwo das Recht geben, sich per VPN verbinden zu dürfen? Gesehen habe ich nichts.

Gruß

Korrektur: War komplett abgeschalten, sowohl am Host als auch am Guest!

Am Host ist aktiv, alles was per default aktiviert ist. Nix selber konfiguriert. Am Guest ist sie ausgeschalten.

Aber wieso geht das wenn der Switch dran hängt? Seit ich heute vormittag den Switch wieder angeschlossen habe läuft die Verbindung stabil? Kann jetzt leider nicht mehr abstöpseln, aber morgen in der Früh werd ich mal wieder direkt anstecken...

Im Log am Proxmox sieht man folgendes:

Code Select Expand


Oct 13 11:20:32 pve kernel: [ 8230.414107] vmbr1: port 1(eno4) entered blocking state
Oct 13 11:20:32 pve kernel: [ 8230.414112] vmbr1: port 1(eno4) entered forwarding state
Oct 13 11:31:57 pve kernel: [ 8916.122515] ixgbe 0000:07:00.1 eno4: NIC Link is Down
Oct 13 11:31:57 pve kernel: [ 8916.123147] vmbr1: port 1(eno4) entered disabled state
Oct 13 11:32:19 pve kernel: [ 8937.317048] ixgbe 0000:07:00.1 eno4: NIC Link is Up 100 Mbps, Flow Control: RX/TX
Oct 13 11:32:19 pve kernel: [ 8937.317560] vmbr1: port 1(eno4) entered blocking state
Oct 13 11:32:19 pve kernel: [ 8937.317565] vmbr1: port 1(eno4) entered forwarding state
Oct 13 11:33:12 pve kernel: [ 8991.100071] ixgbe 0000:07:00.1 eno4: NIC Link is Down
Oct 13 11:33:12 pve kernel: [ 8991.100590] vmbr1: port 1(eno4) entered disabled state
Oct 13 11:33:33 pve kernel: [ 9011.555637] ixgbe 0000:07:00.1 eno4: NIC Link is Up 100 Mbps, Flow Control: RX/TX
Oct 13 11:33:33 pve kernel: [ 9011.556109] vmbr1: port 1(eno4) entered blocking state
Oct 13 11:33:33 pve kernel: [ 9011.556113] vmbr1: port 1(eno4) entered forwarding state
Oct 13 11:38:15 pve kernel: [ 9294.186407] ixgbe 0000:07:00.1 eno4: NIC Link is Down
Oct 13 11:38:15 pve kernel: [ 9294.187050] vmbr1: port 1(eno4) entered disabled state
Oct 13 11:38:36 pve kernel: [ 9314.718725] ixgbe 0000:07:00.1 eno4: NIC Link is Up 100 Mbps, Flow Control: RX/TX
Oct 13 11:38:36 pve kernel: [ 9314.719245] vmbr1: port 1(eno4) entered blocking state
Oct 13 11:38:36 pve kernel: [ 9314.719249] vmbr1: port 1(eno4) entered forwarding state
Oct 13 11:38:50 pve kernel: [ 9328.472976] ixgbe 0000:07:00.1 eno4: NIC Link is Down
Oct 13 11:38:50 pve kernel: [ 9328.473511] vmbr1: port 1(eno4) entered disabled state
Oct 13 11:39:11 pve kernel: [ 9349.295820] ixgbe 0000:07:00.1 eno4: NIC Link is Up 100 Mbps, Flow Control: RX/TX
Oct 13 11:39:11 pve kernel: [ 9349.296356] vmbr1: port 1(eno4) entered blocking state
Oct 13 11:39:11 pve kernel: [ 9349.296361] vmbr1: port 1(eno4) entered forwarding state
Oct 13 11:39:13 pve kernel: [ 9351.343113] ixgbe 0000:07:00.1 eno4: NIC Link is Down
Oct 13 11:39:13 pve kernel: [ 9351.343656] vmbr1: port 1(eno4) entered disabled state
Oct 13 11:39:15 pve kernel: [ 9354.054067] ixgbe 0000:07:00.1 eno4: NIC Link is Up 100 Mbps, Flow Control: RX/TX
Oct 13 11:39:15 pve kernel: [ 9354.054590] vmbr1: port 1(eno4) entered blocking state
Oct 13 11:39:15 pve kernel: [ 9354.054594] vmbr1: port 1(eno4) entered forwarding state
Oct 13 11:39:20 pve kernel: [ 9358.923622] ixgbe 0000:07:00.1 eno4: NIC Link is Down
Oct 13 11:39:20 pve kernel: [ 9358.924162] vmbr1: port 1(eno4) entered disabled state
Oct 13 11:39:41 pve kernel: [ 9379.731704] ixgbe 0000:07:00.1 eno4: NIC Link is Up 100 Mbps, Flow Control: RX/TX
Oct 13 11:39:41 pve kernel: [ 9379.732224] vmbr1: port 1(eno4) entered blocking state
Oct 13 11:39:41 pve kernel: [ 9379.732228] vmbr1: port 1(eno4) entered forwarding state
Oct 13 11:42:17 pve kernel: [ 9535.598978] perf: interrupt took too long (3163 > 3137), lowering kernel.perf_event_max_sample_rate to 63000

Das Motherboard ist ein Supermicro A2SDi-4C-HLN4F mit 64 GB Ram. Da sind vier Gigabit Ports drauf, Controller ist von Intel Typ X553.

Hallo Forum,

meine Umgebung:
Proxmox Virtualisierer
opensens  20.7.3-amd64
(2 Kerne, 4 GB RAM)

Das ganze läuft an einem DSL Anschluss über eine Fritzbox 7530. Das WAN Interface der opensense geht also direkt an einen Port der Fritzbox.

Problem: Die Internetverbindung setzt immer wieder kurz aus, unterschiedlich lange,so Sekunden Bereich. In dieser Zeit geht die LEDs an der Netzwerkbuchse aus und dann wieder an!
Leider find ich auch nix in den Logs wo ich nachschauen könnte ;-(
Hat jemand eine Idee? Da muss doch irgendwas in irgendwelchen Logs zu finden sein oder?

Umgehungslösung: Wenn ich einen kleinen Switch zwischen schalte, tritt das Problem nicht auf! Nur wenn WAN Port und Fritzbox direkt verbunden sind, kappt irgendwas/wer die Verbindung?!? Die Ports der Fritzbox sind auf Powermode....

Hat jemand eine Idee?

Also das Umstellen aud die verschlüsselte Verbindung scheint tatsächlich das Problem behoben zu haben! Bisher kein Ausfall mehr, grad 40 Minuten telefoniert!  ;D

Danke für die Tipps!

Was sagt denn die Fritz dazu?

Die sagt gar nix dazu! Im Ereignisprotokoll ist keinerlei Hinweis dazu vorhanden?!? Leider...

Moin,

ist ein Telekom Anschluss, die Box eine 7490 mit aktueller Firmware 7.21.

Ich habe jetzt mal die Verschlüsselung aktiviert, danke für den Hinweis. Ich werde das mal testen und berichten ob das was gebracht hat. Falls nicht, muss ich wohl mal eine Aufzeichnung analysieren :o

Gruß - Markus

Hallo Forum,

ich habe vor kurzem meine Firewall umgestellt von Sophos UTM auf openSense umgestellt. Aktuell läuft OPNsense 20.7.3-amd64 auf einem Proxmox Host. Die Umstellung war relativ reibungslos und warf erstmal keine größeren Probleme auf. Nach einigen Tagen stellte ich fest, dass VoiP Gespräche immer nach ziemlich genau 24 Minuten abbrechen. Das äußert sich darin, dass der Gesprächspartner nicht mehr zu hören ist und dieser auch nichts mehr hört. Nach Auflegen und neu wählen kann das Gespräch fortgesetzt werden, zumindest für 24 Minuten?!??!?  :o
Konfiguration: Die Ports 5060, 7078-7109 werden an die Box (feste IP) genattet. In der Outbound Regel ist der Static Port aktiviert.

Es kann nur mit der Konfig auf der OpenSense VM zusammen hängen, vorher auf der UTM lief es ohne Probleme ???

Hat jemand eine Idee wo hier das Problem begraben liegen könnte??? Vor allem die 24 Minuten irritieren mich  :o