Messages

1

24.1 Legacy Series / DSL-Verbindung kann nach Störung nicht wiederhergestellt werden

« on: March 24, 2024, 04:55:31 pm »

Hallo,

es ist mir schon ein paar Mal aufgefallen, heute habe ich dann genauer nachgeschaut. Es kommt ab und zu vor, dass die PPPoE-Verbindung nicht wiederhergestellt werden kann, wenn providerseitig ein Fehler auftritt. Mein Setup ist aktuellste OPNSense-Version auf Proxmox, ein Draytek Vigor 165 ist per pci-passthrough direkt an die OPNSense-VM angeschlossen. Der zweite Anschluss des Vigors hängt am LAN, so dass ich aus dem Modem die Logs per rsyslogd habe.

Heute Nacht gegen 05:20 Uhr gab es wohl irgendeine Art Störung, die OPNSense meldete einen LCP Timeout, und hat die Verbindung geschlossen. Interessanterweise zeigt das Log vom Draytek keine Auffälligkeiten, außer das ab dann PPPoE-Passthrough durch die OPNSense versucht wurde für den Wiederaufbau. Der scheitert allerdings.

Gegen 16 Uhr habe ich das dann erst bemerkt, und habe zuerst das DSL-Modem stromlos gemacht und neugestartet. Das hat allerdings nichts gebracht, die OPNSense konnte die Verbindung weiterhin nicht aufbauen. Erst ein Neustart der OPNSense hat das Problem gelöst.

Die Logs der OPNSense zeigen da ggf. einen Fehler ("No such file or directory"). Am Draytek-Log ist zu sehen, dass der Status der Leitung weiterhin "SHOWTIME" war, also dort wohl kein Problem bestand. Der Status wurde weiter periodisch abgerufen.

OPNSense:

Code: [Select]

2024-03-24T15:59:52 Informational ppp [opt6_link0] LCP: LayerStart
2024-03-24T15:59:52 Informational ppp [opt6_link0] LCP: state change Initial --> Starting
2024-03-24T15:59:52 Informational ppp [opt6_link0] LCP: Open event
2024-03-24T15:59:52 Informational ppp [opt6_link0] Link: OPEN event
2024-03-24T15:59:52 Informational ppp [opt6] Bundle: Interface ng0 created
2024-03-24T15:59:52 Informational ppp web: web is not running
2024-03-24T15:59:52 Informational ppp process 56420 started, version 5.9
2024-03-24T15:59:52 Informational ppp
2024-03-24T15:59:52 Informational ppp Multi-link PPP daemon for FreeBSD
### reboot ###
2024-03-24T15:54:31 Informational ppp [opt6_link0] PPPoE: Connecting to ''
2024-03-24T15:54:31 Informational ppp [opt6_link0] Link: reconnection attempt 3272
2024-03-24T15:54:28 Informational ppp [opt6_link0] Link: reconnection attempt 3272 in 3 seconds
2024-03-24T15:54:28 Informational ppp [opt6_link0] LCP: Down event
2024-03-24T15:54:28 Informational ppp [opt6_link0] Link: DOWN event
###################################################################################################
2024-03-24T05:23:45 Informational ppp [opt6_link0] Link: DOWN event
2024-03-24T05:23:45 Informational ppp [opt6_link0] PPPoE connection timeout after 9 seconds
2024-03-24T05:23:36 Informational ppp [opt6_link0] PPPoE: Connecting to ''
2024-03-24T05:23:36 Informational ppp [opt6_link0] Link: reconnection attempt 4
2024-03-24T05:23:32 Informational ppp [opt6_link0] Link: reconnection attempt 4 in 4 seconds
2024-03-24T05:23:32 Informational ppp [opt6_link0] LCP: Down event
2024-03-24T05:23:32 Informational ppp [opt6_link0] Link: DOWN event
2024-03-24T05:23:32 Informational ppp [opt6_link0] PPPoE connection timeout after 9 seconds
2024-03-24T05:23:23 Informational ppp [opt6_link0] PPPoE: Connecting to ''
2024-03-24T05:23:23 Informational ppp [opt6_link0] Link: reconnection attempt 3
2024-03-24T05:23:22 Informational ppp [opt6_link0] Link: reconnection attempt 3 in 1 seconds
2024-03-24T05:23:22 Informational ppp [opt6_link0] LCP: Down event
2024-03-24T05:23:22 Informational ppp [opt6_link0] Link: DOWN event
2024-03-24T05:23:22 Informational ppp [opt6_link0] PPPoE connection timeout after 9 seconds
2024-03-24T05:23:13 Informational ppp [opt6_link0] PPPoE: Connecting to ''
2024-03-24T05:23:13 Informational ppp [opt6_link0] Link: reconnection attempt 2
2024-03-24T05:23:12 Informational ppp [opt6_link0] Link: reconnection attempt 2 in 1 seconds
2024-03-24T05:23:12 Informational ppp [opt6_link0] LCP: Down event
2024-03-24T05:23:12 Informational ppp [opt6_link0] Link: DOWN event
2024-03-24T05:23:12 Informational ppp [opt6_link0] PPPoE: can't connect "[11]:"->"mpd51462-0" and "[9]:"->"left": No such file or directory ####### Fehler?
2024-03-24T05:23:12 Informational ppp [opt6_link0] Link: reconnection attempt 1
2024-03-24T05:23:11 Informational ppp [opt6_link0] Link: reconnection attempt 1 in 1 seconds
2024-03-24T05:23:11 Informational ppp [opt6_link0] LCP: state change Stopping --> Starting
2024-03-24T05:23:11 Informational ppp [opt6_link0] LCP: Down event
2024-03-24T05:23:11 Informational ppp [opt6_link0] Link: DOWN event
2024-03-24T05:23:11 Informational ppp [opt6_link0] can't remove hook mpd51462-0 from node "[11]:": No such file or directory ###### Fehler ?
2024-03-24T05:23:11 Informational ppp [opt6_link0] PPPoE: connection closed
2024-03-24T05:23:11 Informational ppp [opt6_link0] LCP: LayerDown
2024-03-24T05:23:11 Informational ppp [opt6_link0] LCP: SendTerminateReq #2
2024-03-24T05:23:11 Informational ppp [opt6] IPCP: state change Closing --> Initial
2024-03-24T05:23:11 Informational ppp [opt6] Bundle: No NCPs left. Closing links...
2024-03-24T05:23:11 Informational ppp [opt6] IPCP: LayerFinish
2024-03-24T05:23:11 Informational ppp [opt6] IPCP: Down event
2024-03-24T05:23:11 Informational ppp [opt6] IFACE: Rename interface pppoe1 to pppoe1
2024-03-24T05:23:11 Informational ppp [opt6] IFACE: Down event
2024-03-24T05:23:11 Informational ppp [opt6] IPCP: LayerDown
2024-03-24T05:23:11 Informational ppp [opt6] IPCP: SendTerminateReq #4
2024-03-24T05:23:11 Informational ppp [opt6] IPCP: state change Opened --> Closing
2024-03-24T05:23:11 Informational ppp [opt6] IPCP: Close event
2024-03-24T05:23:11 Informational ppp [opt6] Bundle: Status update: up 0 links, total bandwidth 9600 bps
2024-03-24T05:23:11 Informational ppp [opt6_link0] Link: Leave bundle "opt6"
2024-03-24T05:23:11 Informational ppp [opt6_link0] LCP: state change Opened --> Stopping
2024-03-24T05:23:11 Informational ppp [opt6_link0] LCP: peer not responding to echo requests
2024-03-24T05:23:11 Informational ppp [opt6_link0] LCP: no reply to 5 echo request(s)
2024-03-24T05:23:01 Informational ppp [opt6_link0] LCP: no reply to 4 echo request(s)
2024-03-24T05:22:51 Informational ppp [opt6_link0] LCP: no reply to 3 echo request(s)
2024-03-24T05:22:41 Informational ppp [opt6_link0] LCP: no reply to 2 echo request(s)
2024-03-24T05:22:31 Informational ppp [opt6_link0] LCP: no reply to 1 echo request(s
2024-03-22T13:03:11 Informational ppp [opt6] IFACE: Rename interface ng0 to pppoe1
2024-03-22T13:03:11 Informational ppp [opt6] IFACE: Up event

DrayTek

Code: [Select]

Mar 24 05:17:58 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ]
Mar 24 05:19:09 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ]
Mar 24 05:20:21 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ]
Mar 24 05:21:32 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ]
Mar 24 05:22:43 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ]
Mar 24 05:23:04 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:06 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:10 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:14 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:16 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:20 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:27 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:29 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:33 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:38 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:40 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:44 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:50 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:52 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:23:55 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ] ###### Status OK
Mar 24 05:23:56 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:03 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:05 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:09 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:14 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:16 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:20 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:24 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:26 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:49 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:53 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:24:58 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:00 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:04 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:06 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ] ###### Status OK
Mar 24 05:25:11 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:13 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:17 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:21 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:23 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:27 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:31 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:33 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:37 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:42 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:44 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:48 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:54 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:25:56 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:26:00 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:26:07 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:26:09 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:26:13 192.168.6.252 DrayTek: PASS THROUGH PPPoE <== V:1 T:1 PADI ID:0
Mar 24 05:26:18 192.168.6.252 DrayTek: ADSL_Status:[Mode=35B States=SHOWTIME UpSpeed=46717000 DownSpeed=258775000 SNR=4 Atten=16 ] ###### Status OK


2

German - Deutsch / Re: os-ddclient mit Infomaniak

« on: May 17, 2022, 09:38:24 pm »

Da sehe ich aktuell auch dasselbe Problem - ich benutze auch einen custom dns, und müsste eine URL mit Parametern eintragen, und auf eine bestimmte Antwort checken. Mit dem alten Plugin läuft das seit Jahren einwandfrei, das neue lässt sich nicht so konfigurieren. Damit wäre es leider absolut nutzlos.

3

22.1 Legacy Series / Re: Random reboots on a new Alder Lake System

« on: April 29, 2022, 03:48:38 pm »

fixed by replacing the quad port realtek nic with an intel counterpart. System is up and running for 7 days without any problems.

The power usage is with 33W idle quite bad with freebsd, the same system runs with 19W idle on Windows 11. Let's see with 22.7 / FreeBSD14

Only the 2x25 GbE fibre card is missing now.

4

22.1 Legacy Series / [fixed] Random reboots on a new Alder Lake System

« on: April 13, 2022, 02:47:52 pm »

Hi,

i am planning to replace my current Kaby-Lake-based installation with a new Alder-Lake based system. Alder Lake is very new, so i expected some sort of trouble and made preparations so i can instantly switch back to the "old" system.

Steps:
- made a config backup of the old system (22.1.5 ufs)
- installed the new system with 22.1.5 zfs
- manually edited the backup file to represent new interface names (igb to re)
- imported the edited backup file
- fixed plugins and packages
- did health checks

So far, the system is up and running blazing fast without any problems. Some ACPI errors while booting, but they look negligible.

But after a while, after 20-30 hours uptime, the system reboots randomly without any trace in the logs or /var/crash. Usually that would indicate some hardware problems, but after intense tests i think the problem must be somewhere else. the system is 24 hours memtest-stable, Windows and a current Debian 11 don't show these problems. So, i am well aware that alder lake is very new and that running a BSD or Linux OS may be a bit gambling, so this thread is more about ideas and discussion and not about support.

I tried different things, like disabling powersaving mechanisms in UEFI, but currently without success. Tomorrow i'll connect a KVM switch to the machine, maybe i can record the screen in the moment of a reboot.

system info:

Intel i5-12400 on Gigabyte B660M Chipset
2x 8GB DDR4-3200 RAM (via XMP)
1x 250 GB Samsung 970 Evo Plus NVME SSD
1x Realtek 2.5 GbE onboard NIC
1x 4-Port 1 GbE Realtek NIC
Maybe there is a newer kernel or something like that i can try.

5

German - Deutsch / Re: Kein Durchsatz durch VPN-Tunnel nach unterschiedlicher Zeit

« on: May 02, 2020, 02:52:15 am »

Klar, kein Problem.

Die OPNSense von meinem Netz zuhause läuft direkt auf der Hardware:

CPU: i5-7500, RAM: 16 GB DDR4-2400, SATA-SSD 120GB, Mainboard MSI B110M ECO, Netzwerkkarten: Intel X520-DA2 (2x 10 GBit/s), 1x Quad-Port Intel PCIe.
Angebunden an ein TC-4400 Kabelmodem im Bridge-Mode, d.h. OPNSense hat die WAN-IP direkt und keine Schweinereien mit NAT-T etc.
Das Netzwerk verteilt sich über drei Stockwerke, im Keller der Serverraum mit Modem, Firewall, NAS und einem kleinen 4x 10 GBit/s Mikrotik-Switch, EG und OG haben je einen großen Mikrotik Switch mit 24 Ports + 2x 10 Gbit/s. Die laufen auch alle als Switch und nicht als Router. Die Workstation (mit der ich die VPN-Verbindung aufbaue) ist also bis zur OPNSense mit 10 GBit/s angebunden. Im internen Netzwerk gibt es zumindest keine Fehler (Paketverluste, Fragmentierung, ...).

Auf der anderen Seite an einem Telekom-DSL Anschluss mit reinem DSL-Modem steht wieder eine OPNSense (Supermicro Board mit Atom C2558, 8 GB RAM, SSD, 4x 1 GBit/s Intel onboard, OPNSense läuft direkt auf der Hardware), die direkt die externe IP hat. Netzwerk ist ebenfalls ein Mikrotik-Setup mit 5x 24 Port Switchen (ca. 100 Geräte) und 12 VLANs. Die Geräte auf die ich per VPN und SSH/RDP/VNC zugreife sind allerdings per Kabel im Kernnetz, also kein VLAN. Auch hier, das interne Netz ist völlig unauffällig.

Anbei noch der vereinfachte Netzwerkplan von meinem Zuhause, das Büro ist eigentlich redundant, da habe ich grad keinen Plan zur Hand. Nach der OPNSense kommt der Hauptswitch, an dem direkt die Server hängen. Weitere Switches hängen direkt am Hauptswitch, die VLANs per extra Trunk direkt an der OPNSense.

6

German - Deutsch / Kein Durchsatz durch VPN-Tunnel nach unterschiedlicher Zeit

« on: May 01, 2020, 02:28:38 pm »

Hallo,

ich habe seit längerem ab und zu Probleme mit meinen VPNs. In der Regel arbeitet alles einwandfrei, aber es geschieht öfter das nach unterschiedlicher Länge der Verbindungsdauer der Tunnel einfach "stirbt". Ich benutze grundsätzlich dieses Setup: EAP-MSCHAPv2 via IKEv2

Gegenstelle ist meine Workstation zuhause, aktuellstes Windows 10 mit dem eingebauten VPN-Client. Über die VPN-Verbindung in mein Büro benutze ich hauptsächlich klassischen Kram wie SSH, VNC, RDP. Das Problem äußert sich dann wie folgt, dass die Verbindung mit den remote-Servern verloren geht, und auch nicht wiederhergestellt werden kann. Währenddessen zeigen sowohl Windows als auch OPNSense noch einen bestehenden Tunnel an. Das Problem kann nach Stunden oder auch Minuten auftreten, das ist vollkommen zufällig. Wenn ich parallel eine SSH-Verbindung ohne VPN per Port Forwarding aufbaue, bleibt diese bestehen, d.h. es liegt wahrscheinlich nicht an Problemen mit dem Internet. 

Die Logfiles zeigen, dass es die OPNSense trotz totem Tunnel noch "mitbekommt", wenn ich bei Windows die VPN-Verbindung trenne. Nach einem Neuaufbau der Verbindung funktioniert alles wieder, bis zum nächsten Mal jedenfalls.

Wie kann ich die Ursache des Problems herausfinden ?

Logs der OPNSense, die Verbindung ging irgendwann zwischen 13:42 und 13:52 (SSH Session vom Server aufgrund von Timeout geschlossen) verloren. RASMan auf Windows meldet nichts, außer dem manuellen Trennen der Verbindung:

Code: [Select]

2020-05-01T14:10:03 charon: 11[CFG] <con1|57> lease 10.0.250.1 by 'vpnuser@domain.tld' went offline
2020-05-01T14:10:03 charon: 11[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (80 bytes)
2020-05-01T14:10:03 charon: 11[ENC] <con1|57> generating INFORMATIONAL response 9 [ ]
2020-05-01T14:10:03 charon: 11[IKE] <con1|57> IKE_SA deleted
2020-05-01T14:10:03 charon: 11[IKE] <con1|57> deleting IKE_SA con1[57] between VPN-SERVERIP[vpn.domain.tld]...CLIENT-WAN-IP[192.168.X.YYY]
2020-05-01T14:10:03 charon: 11[IKE] <con1|57> received DELETE for IKE_SA con1[57]
2020-05-01T14:10:03 charon: 11[ENC] <con1|57> parsed INFORMATIONAL request 9 [ D ]
2020-05-01T14:10:03 charon: 11[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (80 bytes)
2020-05-01T14:10:03 charon: 11[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (80 bytes)
2020-05-01T14:10:03 charon: 11[ENC] <con1|57> generating INFORMATIONAL response 8 [ D ]
2020-05-01T14:10:03 charon: 11[IKE] <con1|57> CHILD_SA closed
2020-05-01T14:10:03 charon: 11[IKE] <con1|57> sending DELETE for ESP CHILD_SA with SPI cf3334c8
2020-05-01T14:10:03 charon: 11[IKE] <con1|57> closing CHILD_SA con1{295} with SPIs cf3334c8_i (87798 bytes) 6cd39980_o (60176 bytes) and TS 0.0.0.0/0 === 10.0.250.1/32
2020-05-01T14:10:03 charon: 11[IKE] <con1|57> received DELETE for ESP CHILD_SA with SPI 6cd39980
2020-05-01T14:10:03 charon: 11[ENC] <con1|57> parsed INFORMATIONAL request 8 [ D ]
2020-05-01T14:10:03 charon: 11[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (80 bytes)
2020-05-01T13:42:21 charon: 09[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (80 bytes)
2020-05-01T13:42:21 charon: 09[ENC] <con1|57> generating INFORMATIONAL response 7 [ D ]
2020-05-01T13:42:21 charon: 09[IKE] <con1|57> CHILD_SA closed
2020-05-01T13:42:21 charon: 09[IKE] <con1|57> sending DELETE for ESP CHILD_SA with SPI c697ebff
2020-05-01T13:42:21 charon: 09[IKE] <con1|57> closing CHILD_SA con1{294} with SPIs c697ebff_i (0 bytes) a504004a_o (0 bytes) and TS 0.0.0.0/0 === 10.0.250.1/32
2020-05-01T13:42:21 charon: 09[IKE] <con1|57> received DELETE for ESP CHILD_SA with SPI a504004a
2020-05-01T13:42:21 charon: 09[ENC] <con1|57> parsed INFORMATIONAL request 7 [ D ]
2020-05-01T13:42:21 charon: 09[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (80 bytes)
2020-05-01T13:37:32 charon: 09[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (208 bytes)
2020-05-01T13:37:32 charon: 09[ENC] <con1|57> generating CREATE_CHILD_SA response 6 [ N(ESP_TFC_PAD_N) SA No TSi TSr ]
2020-05-01T13:37:32 charon: 09[IKE] <con1|57> CHILD_SA con1{295} established with SPIs cf3334c8_i 6cd39980_o and TS 0.0.0.0/0 === 10.0.250.1/32
2020-05-01T13:37:32 charon: 09[CFG] <con1|57> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
2020-05-01T13:37:32 charon: 09[ENC] <con1|57> parsed CREATE_CHILD_SA request 6 [ SA No TSi TSr ]
2020-05-01T13:37:32 charon: 09[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (336 bytes)
2020-05-01T13:37:21 charon: 08[IKE] <con1|57> CHILD_SA closed


7

19.7 Legacy Series / reset particular service configuration (ipsec vpn)

« on: December 09, 2019, 10:39:46 pm »

hello,

i am on the latest version of opnsense with some massive problems with vpn. i just can't connect with my mobole clients anymore (using IKEv2+MSCHapv2/EAP, error: charon: 15[IKE] <con1|8> no EAP key found for hosts '***hostname***' - '***ikeuser***'). The configuration ist just the same as on other opnsense machines i use - i think somehow the IPSEC part is broken, as the service does not start automatically at boot, and the ipsec firewall rules aren't inserted automatically anymore. maybe a recent hardware change messed something up.
So, is there a possibility to reset/reconfigure the ipsec part only to default state?

8

German - Deutsch / Seltsames Problem mit VLAN (timeout außer während shutdown/boot)

« on: October 06, 2019, 07:09:34 pm »

Hallo,

ich habe neuerdings ein seltsames Problem mit meiner OPNSense. Kurz zum Aufbau:

OPNSense:
onboard Intel NIC Port 1: direkt angebunden an LTE Modem für WAN-Failover
onboard Intel NIC Port 2: Switch für ein separates zweites LAN
Mellanox Connect-X2 Port 1: WAN-Uplink Glasfaser (1 Gbit/s)
Mellanox Connect-X2 Port 2: Trunk zu Mikrotik CRS305G-1G-4S+ (LAN untagged, GUEST tagged VID 10)

Auf dem Mikrotik läufts CapsMan um meine Access Points zu verwalten, diese bieten zwei Netze an, einmal für Gäste, einmal Intern. Der Verkehr der Gäste wird mit der VLAN-ID 10 getagged, alles aus dem internen LAN+WLAN ist untagged.
An der OPNSense ist das VLAN entsprechend eingerichtet, und es hat auch einige Monate einwandfrei funktioniert. Innerhalb des Netzwerkes funktioniert alles, ich kann einen Gast vom Mikrotik aus über das ganze Netzwerk hinweg anpingen, und zurück. Es hakt also irgendwo zwischen OPNSense und dem Mikrotik, diese können sich gegenseitig nicht anpingen - mittels tcpdump ist auch kein Traffic zu finden. Firewall-Log, OPNSense-Log komplett unauffällig.
Inzwischen habe ich stark die OPNSense in Verdacht - wenn ich auf dem Mikrotik konstant einen Ping auf die VLAN-IP der OPNSense laufen lasse, erhalte ich timeouts. Zufälligerweise habe ich dann einmal die OPNSense neugestartet, kurz nach dem Klick auf Shutdown gingen einige Pings während des Herunterfahrens durch und wurden beantwortet. Dasselbe passiert während des Hochfahrens, sobald dieses abgeschlossen ist, geht nichts mehr (timeout). Daraus werde ich leider nicht wirklich schlau, weil laut Live-View der Paketfilter nichts blockiert o.Ä.

Hat jemand eine Idee, was ich ausprobieren kann oder ob es noch eine Möglichkeit gibt genauer nachzuschauen was hier passiert ?

9

Zenarmor (Sensei) / Re: Sensei on OPNsense - Application based filtering

« on: September 22, 2019, 11:42:12 pm »

@marcri, thanks for the feedback. @nullinger, then it looks like if you have just the username, we have an issue. We were just about to do a code freeze for 1.0.3. Good timing Looks like an easy fix.

That's true, i am using a local mail relay which allows mail without authentication from specific IPs. Thank you very much !

10

Zenarmor (Sensei) / Re: Sensei on OPNsense - Application based filtering

« on: September 17, 2019, 10:41:50 pm »

Hello @mb,

i am on my third day with sensei, and i like it very much. Today, i tried to setup reports by mail and got some problems because the system sets "autoreports@sunnyvalley.io" as sender. As my mail relay does not allow sender addresses with non-local/external domains it would be very nice to have the possibility to set an own sender address.

Thanks !

11

German - Deutsch / Re: Probleme mit X520-DA2: no carrier - neueren Intel Treiber kompilieren ?

« on: February 05, 2019, 10:12:20 pm »

Ich vermute hier das Problem aber tatsächlich im Treiber, unter nicht BSD-Systemen gibt es ja keine Probleme. Nachdem ich noch eine Mellanox Connect-X2 mit zwei Ports auftreiben konnte, läuft jetzt für das erste diese produktiv, und mit der Intel experimentiere ich im Backup-System weiter. Ich würde halt gerne den neuesten Treiber ausprobieren, dafür muss ich aber den Kernel neu kompilieren, da der bisherige Treiber fest einkompiliert ist.

12

German - Deutsch / Re: Probleme mit X520-DA2: no carrier - neueren Intel Treiber kompilieren ?

« on: February 02, 2019, 01:28:18 am »

Update: Das Problem hängt direkt mit VLANs zusammen. Sobald nur ein Tag gesetzt wird (Schnittstellen -> Andere Typen -> VLAN) ist nach dem nächsten Reboot das Interface mit "no carrier" offline. Auch, wenn noch keine Zuweisung erfolgt ist. Bis dahin funktioniert die Schnittstelle sowie das VLAN korrekt. Wird der VLAN Tag wieder gelöscht, ist das Interface nach einem Reboot wieder funktional. Das Neuladen der Services bringt keine Abhilfe.

13

German - Deutsch / Probleme mit X520-DA2: no carrier - neueren Intel Treiber kompilieren ?

« on: January 31, 2019, 01:03:39 am »

Hallo,

ich habe meine alte OPNSense-Hardware ausgetauscht, und ein neues System aufgebaut - unter anderem mit einer originalen Intel X520-DA2. Mit der habe ich das Problem, das inzwischen einer der beiden Ports der X520 nicht mehr korrekt funktioniert. Es sieht so ähnlich aus, wie das Problem welches hier geschildert wird.

Zu Beginn, während des Setups und nach dem ersten Boot lief alles einwandfrei, ix0 = LAN, ix1 = WAN, alles online und sauber am funktionieren. Beim Update von 19.1-rc1 auf rc2 kam ix0 dann nicht mehr online. Das Webinterface sagt "Ethernet autoselect", ifconfig ix0 liefert "no carrier" aus. Der Switch am anderen Ende des Kabels zeigt "no link". ix1 funktioniert allerdings wie gehabt. Mittlerweile habe ich so gut wie alles ausprobiert:

• Kabel getauscht, unter anderem andere DACs, oder auch Kupfer-SFPs
• Switch getauscht
• MSI-X deaktiviert
• Manuelle Konfiguration der Linkgeschwindigkeit

Das führte zu keiner Änderung der Situation. Beim Booten einer Ubuntu-CD, oder auch einer festen Installation treten keine Probleme auf, beide Links funktionieren dauerhaft.
Weitere Tests haben ergeben, dass bei einem Reboot der Maschine der Link während des POST, Grub und dem Booten von OPNSense funktioniert und Pakete in beide Richtungen überträgt, und erst bei "configuring interfaces" verschwindet. Hier ein kurzes Youtube-Video, das den Switch zeigt. Der Ping geht auf ein normales GBit-Interface.

Daher vermute ich hier ein Problem mit dem in Free/Hardened-BSD ausgelieferten Treiber (3.2.12-k) und würde gerne den aktuellen Treiber direkt von Intel (3.3.6) kompilieren und testen. Mit FreeBSD und eventuellen Änderungen durch OPNSense bin ich im Gegensatz zu Linuxen nicht gut vertraut. Gibt es für die 19.1-rc2 schon Kernel-Sources ? Kann ich den neuen Treiber dann auch persistent installieren ?

14

19.1 Legacy Series / Re: Issues with IPSEC and Diffie Hellman Groups on 19.1

« on: December 29, 2018, 02:19:07 am »

I have a similar issue with the same possible cause. After importing configuration from 18.7 to 19.1 my IKEv2 VPNs are broken, the clients can't connect due to some errors with the DH Group

Code: [Select]

Dec 29 02:04:39 opnsense charon: 12[IKE] <40> XYZ is initiating an IKE_SA
Dec 29 02:04:39 opnsense charon: 12[IKE] <40> remote host is behind NAT
Dec 29 02:04:39 opnsense charon: 12[IKE] <40> DH group MODP_2048 inacceptable, requesting MODP_2048
Dec 29 02:04:39 opnsense charon: 12[ENC] <40> generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]

DH Groups:

Code: [Select]

root@opnsense191:~ # ipsec listall | grep DH
    DH:CURVE_25519

root@opnsense187:~ # ipsec listall | grep DH
    DH:ECP_256
    DH:ECP_384
    DH:ECP_521
    DH:ECP_224
    DH:ECP_192
    DH:ECP_256_BP
    DH:ECP_384_BP
    DH:ECP_512_BP
    DH:ECP_224_BP
    DH:MODP_3072
    DH:MODP_4096
    DH:MODP_6144
    DH:MODP_8192
    DH:MODP_2048
    DH:MODP_2048_224
    DH:MODP_2048_256
    DH:MODP_1536
    DH:MODP_1024
    DH:MODP_1024_160
    DH:MODP_768
    DH:MODP_CUSTOM
    DH:CURVE_25519


15

18.7 Legacy Series / Re: LetsEncrypt Renewal failes due to DNS(?) error

« on: September 04, 2018, 10:53:29 am »

bump...