Messages

i tried it on another opnsense with active running sensei.

Short version:

just delete 'sensei-db'

cd /usr/local/opnsense/version/
rm -rv sensei-db

then use auto plugin resolver, and reset local conflicts
done


hint:
there is another folder under /usr/local/sensei-db
im not sure is it still in use or not.
to fix the GUI it is enough to delete the folder /usr/local/opnsense/sensei-db.
I also deleted the folder /usr/local/sensei-db, which had a lot of content, but the instance is still running, but can't say for sure if data (dashboard) is lost.

br
K

resolved!

what i did befor open this thread:
- uninstall sensei
- run automatic plugin resolver
- reset plugin conflicts
- reboot

result= sensei-db missing

then i opened this thread:

meanwhile i searched over cli for everything related for 'sensei' or 'os-sensei' or 'sensei-db' and delete it manually.

find / -name 'sensei-db'


- run automatic plugin resolver
- reset plugin conflicts

result: sensei-db missing still there

- reboot opnsense

result: sensei-db missing still there
- run automatic plugin resolver
- reset plugin conflicts

result: gone :)

Hi,

Did you try System - Firmware - Status - Resolve Plugin Conflicts - Reset all local conflicts?

Yes i tried, but nothing happend. Still there.

hi there

i know os-sensei-db is not used anymore, but how do I remove it from the GUI?
(sensei works fine)

Its still there:

os-sensei-db (missing)   N/A   N/A   N/A   N/A

Where does the gui collects the packages written in the GUI?

I would like to delete it manualy, reinstall isnt possible bc the package isn't in the repo from sensei anymore.

Thank you

Best Regards
K

@Antaris, @ IsaacFL; thanks. 1.8.1 packages are going to fix this and the 'misconfigured' plug-in issue.

1.8.1 is planned for Monday.

nothing changed, still same issue
Have the same Problem on a hardware and a virtual machine. No negative impact but,yes, not healthy :)


see another thing, whats about this? (from the plugins overview):

os-sensei-db (orphaned)   1.8.21031809   64.7MiB   unknown-repository   Databases for Sensei

on both (hardware and virtual machines)

[snort_vrt.rulesfile]

Quick one: do I have to manually type the snort_vrt.rulesfile anytime there is a new version or there is a way for OPNsense to update that automatically ?

good question, it looks like you have to update the string by your self. If opnsense update the file string, they do it rarely.

Between 29151 and 2983 (2021-03-10) are 4 Versions

mistake, sorry

Have you tried rebooting after setting up gateway monitoring? Something is buggy w.r.t. VTI interfaces, haven't looked into what exactly it is yet, but it's possible that VTI interfaces lose their IP addresses after certain configuration changes, i know at least one way to provoke it (change MTU or MSS values in interface config).

When i experimented with this, rebooting usually got everything working. iirc simply disconnecting and reconnecting the tunnel also worked, the VTI interface had its IP address again

Thank you for your message!
With MTU and MSS i played already, this was the solution when i setup the tunnel with pfsense and it was not working at beginning. Now i use the value MSS 1300 and MTU 1400 to be safe. The tunnel works well until i setup gateway monitoring, so i think it is not a failure with MSS and MTU. Now i setup another tunnel to another endpoint pfsense and lets see whats happend.

tbc..

BR
K

Good day


I want to set up a routed VPN between pfsense and opnsense. previously both endpoints were pfsense, but now I want to change one side to an opnsense. unfortunately I was not really successful.

If i do it according to this guide:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html
it works, but as soon as i enable gateway monitoring, the VPN (incl. phase 2) is still UP but ping/connection is gone. Also the gateway does not come green, although I can ping the gateway before activating monitoring with the opnsense.

With the pfsense there were no problems.

Does anyone have an idea what it could be?

Task:
Setup routed VPN, VPN work = OK
ping gateway from side B with opnsense = OK
ping gateway from side B with PC = OK
setup GW monitoring with monitor IP GW Side B = fail
ping gateway from side B with opnsense = fails
ping gateway from side B with pc = fails
vpn does not work anymore!

Szenario:
Side A opnsense
routet VPN GW 1.1.1.1

Side B pfsense
routet VPN GW 2.2.2.2
Monitor side A GW = OK

If i setup the same monitoring on opnsense like pfsense but vice versa, its not working and the all communication over the VPN is gone. (the tunnel ist still up)


I have the feeling it is a bug..

Best Regards
k

Hallo

Bei mir laufen unter Services noch beide, syslog-ng und syslogd.
Sind beide noch notwendig?

Gruss

Habs gerade selber rausgefunden.
Es muss unter System->Settings->logging folgendes deaktiviert (angewählt)werden:
   
Disable legacy circular logging

Hallo

Bei mir laufen unter Services noch beide, syslog-ng und syslogd.
Sind beide noch notwendig?

Gruss

Guten Tag

Ist es vorgesehen, dass nach Installation des Plugins L2TP die OPNsense L2TP over IPsec unterstützt? Oder L2TP und IPsec nur unabhängig voneinander verwendet werden können?

Es wäre super, wenn L2TP over IPsec funktionieren würde, da dann der Windows 10 native VPN Client verwendet werden kann ohne ein Zertifikat zu installieren.
Auf einer pfSense funktioniert die Verbindung Windows 10 und L2TP/IPsec. Dort ist aber auch spezifisch von einem L2TP/IPsec Dienst die rede.

Meine Tests ergeben, dass die OPNsense zwar IPsec und L2TP unterstützt, aber die Kombination von L2TP und IPsec zu L2TP over IPsec ist nicht vorgesehen.
Festgestellt habe ich dies beim pcapen der Verbindungsaufbau und anschliessendem vergleichen. Die Konfiguration wurde identisch zur pfSense erstellt.

Wenn der Windows Client zur pfSense L2TP/IPsec Verbindung aufnimmt, wird alles über ESP gesteuert.
Ich sehe keine 1701 UDP Pakete für den L2TP Server.

Wenn der Client zur OPNsense L2TP+IPsec Verbindung aufnimmt, startet der Client mit der ESP Kommunikation zum Server, der IPsec Server reicht die Daten anhand der Header-Informationen des eingepackten Pakets an den L2TP Server weiter, dieser Antwortet auch, aber sendet die Daten direkt zurück auf UDP1701 ohne diese Zuerst durch den IPsec Dienst entsprechend zu ESP enkapsulieren.

Dies zeigt mir, dass der L2TP Server nichts von einem IPsec Server wissen will und somit L2TP over IPsec auf der OPNsense nicht möglich ist.

Es würde wahrscheinlich nicht die Welt kosten, dem L2TP Server bei zu bringen, die Daten nach Verarbeitung zurück an den IPsec Dienst zu senden, damit L2TP over IPsec möglich wäre.
Da aber L2TP (als einzelne Instanz) als veraltet angeschaut wird, wird wohl nicht mehr viel in diese Richtung unternommen.

Ist meine Erkenntnis richtig?

BR

I've looked into it further.
I think the bug is that the L2TP server does not return the data back to the IPSec service.

When I record a connection start between client and pfsense I can't detect UDP1701 packets but only ESP.

When I record a connection start between client and opnsense I see that the firewall tries to reach the client on 1701 UDP. The client, however, has never tried to reach the firewall on this port. I only see traffic from client to opnsense ESP.



opnsense 10.100.2.151

Code Select Expand

20:03:29.992063 IP 10.50.2.170 > 10.100.2.151: ESP(spi=0xcd0e2536,seq=0x1), length 164
20:03:30.987384 IP 10.50.2.170 > 10.100.2.151: ESP(spi=0xcd0e2536,seq=0x2), length 164
20:03:32.994776 IP 10.50.2.170 > 10.100.2.151: ESP(spi=0xcd0e2536,seq=0x3), length 164


pfsense 10.100.2.148

Code Select Expand

20:04:43.419714 IP 10.50.2.170 > 10.100.2.148: ESP(spi=0xc4f9eacd,seq=0x1), length 164
20:04:44.423593 IP 10.50.2.170 > 10.100.2.148: ESP(spi=0xc4f9eacd,seq=0x2), length 164
20:04:44.426226 IP 10.100.2.148 > 10.50.2.170: ESP(spi=0x93ecb4d8,seq=0x1), length 164
20:04:44.430347 IP 10.50.2.170 > 10.100.2.148: ESP(spi=0xc4f9eacd,seq=0x3), length 68
20:04:44.434370 IP 10.50.2.170 > 10.100.2.148: ESP(spi=0xc4f9eacd,seq=0x4), length 100
20:04:44.435850 IP 10.100.2.148 > 10.50.2.170: ESP(spi=0x93ecb4d8,seq=0x2), length 84
20:04:44.438398 IP 10.50.2.170 > 10.100.2.148: ESP(spi=0xc4f9eacd,seq=0x5), length 100
20:04:44.440815 IP 10.100.2.148 > 10.50.2.170: ESP(spi=0x93ecb4d8,seq=0x3), length 100


someone any idea?

hi im also struggeling with this topic.

i tried this:

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/l2tp-ipsec.html

and it works directly with pfsense without any issue.
so i tried to do the same with opnsense (setup is almost the same)
but it doesnt work.

on ipsec log it stocks on:
Jun 13 16:06:03 OPNsense charon: 09[NET] <23> sending packet: from "opnsenseWANIP"[500] to "clientIP"[500] (56 bytes)

on l2tp log, nothing happen

Setup is the same, same Network, same client, but only in pfsense it is working.


Someone was susseccfull with L2TP/IPsec with opnsense?

best regards

10.50.2.170 is client
10.100.2.151 is opnsense wan interface

Code Select Expand

Jun 13 16:24:38 OPNsense charon: 16[NET] <29> received packet: from 10.50.2.170[500] to 10.100.2.151[500] (408 bytes)
Jun 13 16:24:38 OPNsense charon: 16[ENC] <29> parsed ID_PROT request 0 [ SA V V V V V V V V ]
Jun 13 16:24:38 OPNsense charon: 16[ENC] <29> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:01
Jun 13 16:24:38 OPNsense charon: 16[IKE] <29> received MS NT5 ISAKMPOAKLEY vendor ID
Jun 13 16:24:38 OPNsense charon: 16[IKE] <29> received NAT-T (RFC 3947) vendor ID
Jun 13 16:24:38 OPNsense charon: 16[IKE] <29> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 13 16:24:38 OPNsense charon: 16[IKE] <29> received FRAGMENTATION vendor ID
Jun 13 16:24:38 OPNsense charon: 16[ENC] <29> received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
Jun 13 16:24:38 OPNsense charon: 16[ENC] <29> received unknown vendor ID: 26:24:4d:38:ed:db:61:b3:17:2a:36:e3:d0:cf:b8:19
Jun 13 16:24:38 OPNsense charon: 16[ENC] <29> received unknown vendor ID: e3:a5:96:6a:76:37:9f:e7:07:22:82:31:e5:ce:86:52
Jun 13 16:24:38 OPNsense charon: 16[IKE] <29> 10.50.2.170 is initiating a Main Mode IKE_SA
Jun 13 16:24:38 OPNsense charon: 16[CFG] <29> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Jun 13 16:24:38 OPNsense charon: 16[ENC] <29> generating ID_PROT response 0 [ SA V V V V ]
Jun 13 16:24:38 OPNsense charon: 16[NET] <29> sending packet: from 10.100.2.151[500] to 10.50.2.170[500] (160 bytes)
Jun 13 16:24:38 OPNsense charon: 16[NET] <29> received packet: from 10.50.2.170[500] to 10.100.2.151[500] (388 bytes)
Jun 13 16:24:38 OPNsense charon: 16[ENC] <29> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Jun 13 16:24:39 OPNsense charon: 16[IKE] <29> no shared key found for '10.100.2.151'[10.100.2.151] - '%any'[10.50.2.170]
Jun 13 16:24:39 OPNsense charon: 16[IKE] <29> no shared key found for 10.100.2.151 - 10.50.2.170
Jun 13 16:24:39 OPNsense charon: 16[ENC] <29> generating INFORMATIONAL_V1 request 3358429950 [ N(INVAL_KE) ]
Jun 13 16:24:39 OPNsense charon: 16[NET] <29> sending packet: from 10.100.2.151[500] to 10.50.2.170[500] (56 bytes)

Sorry I'm not responding in German. I don't speak or read German, but I can tell that the issue you're experiencing is the same issue I had. Take a look at this article that I wrote. You'll need to flash the v4.0.23 BIOS on your APU4b4 in order for OPNsense 19.1 to work. The problem stems from a BIOS bug that is triggered in FreeBSD 11.2, but not in FreeBSD 11.1.

If you have an existing OPNsense 18.7 installation, you will want to perform the following:

1. Gain console access to your OPNsense installation
2. Install the flashrom package: pkg install flashrom
3. Download the BIOS firmware (this link is for the APU4): fetch http://pcengines.ch/file/apu4_v4.0.23.rom.tar.gz
4. Untar the BIOS: tar -xf apu4_v4.0.23.rom.tar.gz
5. Flash it: flashrom -p internal:boardmismatch=force -w apu4_v4.0.23.rom

Now you can go ahead with the OPNsense 19.1 upgrade (or installation).

The article I wrote with more detailed instructions is: https://github.com/lattera/articles/blob/master/hardware/apu/2019-02-05_flashing_bios/article.md

Is it possible to do this from remote over ssh?
..i know it is dangerous..

Regards
kinch