Messages

I am using the option "failover-ip" ... always (correctly) configured to the IP address of the backup OPNsense machine. On the backup machine the logs show:

Code Select Expand


2022-05-26T10:48:21 Error dhcpd bind update on 10.130.3.90 from dhcp_opt12 rejected: incoming update is less critical than outgoing update
2022-05-26T10:43:22 Error dhcpd bind update on 10.130.2.29 from dhcp_opt12 rejected: incoming update is less critical than outgoing update
2022-05-26T10:31:50 Error dhcpd bind update on 10.129.1.199 from dhcp_opt11 rejected: incoming update is less critical than outgoing update
2022-05-26T10:19:56 Error dhcpd dhcp.c:4131: Failed to send 300 byte long packet over fallback interface.
2022-05-26T10:19:56 Error dhcpd send_packet: Host is down
2022-05-26T10:19:43 Error dhcpd dhcp.c:4131: Failed to send 300 byte long packet over fallback interface.
2022-05-26T10:19:43 Error dhcpd send_packet: Host is down
2022-05-26T10:19:36 Error dhcpd dhcp.c:4131: Failed to send 300 byte long packet over fallback interface.
2022-05-26T10:19:36 Error dhcpd send_packet: Host is down
2022-05-26T10:19:19 Error dhcpd dhcp.c:4131: Failed to send 300 byte long packet over fallback interface.
2022-05-26T10:19:19 Error dhcpd send_packet: Host is down
2022-05-26T10:19:03 Error dhcpd dhcp.c:4131: Failed to send 300 byte long packet over fallback interface.
2022-05-26T10:19:03 Error dhcpd send_packet: Host is down
2022-05-26T10:18:54 Error dhcpd dhcp.c:4131: Failed to send 300 byte long packet over fallback interface.
2022-05-26T10:18:54 Error dhcpd send_packet: Host is down

Hello,

we are using OPNsense OPNsense 22.1.8-amd64 installed on two (former) Sophos SG-310 boxes in a PFSYNC-cluster setup up. At the moment we repeatedly (every minute) observe the following errors in the DHCPv4 log files:

Code Select Expand


2022-05-26T09:05:14 Error dhcpd dhcp.c:4131: Failed to send 306 byte long packet over fallback interface.
2022-05-26T09:05:14 Error dhcpd send_packet: Host is down
2022-05-26T09:05:02 Error dhcpd dhcp.c:4131: Failed to send 306 byte long packet over fallback interface.
2022-05-26T09:05:02 Error dhcpd send_packet: Host is down
...

I have already done some research at google, but at the moment I can't figure out exactly the meaning/source of these error messages. What is the meaning of "fallback interface" in conjunction to the DHCPv4 service?

Can we ignore these messages?

Best regards,
mscd

So ... frischer "Gegentest" mit IPsec-S2S"-Verbindung ... und man siehe ... 500 statt 50 Mbit/s (mit aktiver Verschlüsselung) ... woran es liegt ... kann ich derzeit auch nicht sagen. An der Performance der VMs kann es aber schon mal nicht liegen.

Grüße,
mscd

Ok ... klar mit "virtuell" ... aber durch das gleiche virtuelle Gateway gehen an die VMs dahinter mit nperf getestet 950 MBit/s symmetrisch. Sprich an den Interfaces usw. kann es nicht liegen ... und bei deaktivierter Verschlüsselung im VPN wohl auch nicht an der Virtualisierung von AESni.

Sehr komisch.

Grüße,
mscd

Okay ... besten Dank ... das hat geholfen (nun klappt es auch im SSL/TLS-Modus).

Noch eine kleine Rückfrage ... die OPNsense läuft aktuell auf einem dedizierten Root-Server als VM in Proxmox (mit AESni-Support), welcher mit 1 GBit/s symmetrisch angebunden ist. Die Gegenstelle hängt an einem Kabelmodem mit 1 GBit/s im Downstream auf dedizierter (potenter) Hardware (eine ehemalige Sophos SG310).

Was mich aktuell etwas verwundert ... der maximale OpenVPN-Durchsatz pendelt so bei 40 MBit/s ?! ... und zwar in dem Fall, wenn ich Daten vom Root-Server in Richtung Kabelmodem sende, sprich da müssten (theoretisch) im Idealfall 1000 MBit/s durchgehen.
Gegentest mit deaktivierter Encryption + Authentifizierung hat keinen Unterschied ergeben.
CPU-Last pendelt bei beiden Maschinen auf unter 25%.

Was ist hier zu "erwarten"? Ich finde gerade das Bottelneck nicht.

Danke und Grüße,
mscd

Hallo zusammen,

ich habe aktuell die Problematik, dass ich problemfrei eine Peer-to-Peer-(shared Key)-VPN-Verbindung zwischen zwei OPNsense (21.7.7) am laufen habe. Im Tunnelnetzwerk 10.230.13.0/24 erhält die Client-Firewall die virtuelle IP-Adresse 10.230.13.2 und die Server-Firewall die virtuelle Adresse 10.230.13.1.

Stelle ich lediglich den Servermodus auf "Peer-to-Peer (SSL/TSL)" (CA-Cert und Client-Cert entsprechend vorher angelegt und verteilt) funktioniert der Verbindungsaufbau nach wie vor ... komischer Weise erhält die Client-Firewall dann die virtuelle IP-Adresse 10.230.13.5 und das Routing funktioniert über die VPN-Verbindung nicht mehr sauber.

Kennt jemand diese Problematik? Mich wundert, dass die Client-Firewall nicht (wie üblich) die erste IP-Adresse (nach dem Gateway) in dem Tunnel-Subnetz, sprich 10.230.13.2 (wie bei shared-Key, wo alles geht) erhält.

Schöne Grüße und besten Dank,
mscd

Hallo zusammen,

ich bin gerade dabei freeRadius auf der OPNsense in Betrieb zu nehmen. Ich möchte damit (angebunden an unser Windows AD) WPA2-Enterprise-Authentifizierung (MSCHAPv2, User + AD-Passwort) für unsere Unifi-APs umsetzen.

freeRadius + LDAP funktioniert soweit ... was ich mit "radtest" gegentesten konnte. Aktuell scheitere ich aber noch an einer erfolgreichen Anmeldung an einem Unifi-AP.
Als Fehlermeldung (über "radiusd -X") erhalte ich (im Auszug):

Code Select Expand

(11) ldap: WARNING: No "known good" password added. Ensure the admin user has permission to read the password attribute
(11) ldap: WARNING: PAP authentication will *NOT* work with Active Directory (if that is what you were trying to configure)
rlm_ldap (ldap): Deleting connection (1) - Was referred to a different LDAP server
(11)       [ldap] = ok
(11)       [expiration] = noop
(11)       [logintime] = noop
(11)       [pap] = noop
(11)     } # authorize = updated
(11)   Found Auth-Type = eap
(11)   # Executing group from file /usr/local/etc/raddb/sites-enabled/inner-tunnel
(11)     authenticate {
(11) eap: Expiring EAP session with state 0xa774c857a76dd2cb
(11) eap: Finished EAP session with state 0xa774c857a76dd2cb
(11) eap: Previous EAP request found for state 0xa774c857a76dd2cb, released from the list
(11) eap: Peer sent packet with method EAP MSCHAPv2 (26)
(11) eap: Calling submodule eap_mschapv2 to process data
(11) eap_mschapv2: # Executing group from file /usr/local/etc/raddb/sites-enabled/inner-tunnel
(11) eap_mschapv2:   authenticate {
(11) mschap: WARNING: No Cleartext-Password configured.  Cannot create NT-Password
(11) mschap: Creating challenge hash with username: m.muster
(11) mschap: Client is using MS-CHAPv2
(11) mschap: ERROR: FAILED: No NT-Password.  Cannot perform authentication
(11) mschap: ERROR: MS-CHAP2-Response is incorrect

... sprich der AP kann als Client erfolgreich die Radius-Anfrage stellen ... aber irgendwie hackt es dann.

Kann es sein, dass es im Zusammenspiel mit Unifi + freeRadius (OPNsense) + AD/LDAP hier bekanntermaßen zu Problemen kommt? Hat dieses Setup jemand erfolgreich am laufen?

Schöne Grüße,
mscd

Hallo,

NEIN ... bin z.B. im Subnetz 10.100.0.0/24 (WLAN-Personal) ... und möchte eine VPN-Verbindung aufbauen ... über welche ich dann das Subnetz 10.200.0.0/24 (Verwaltung) erreichen kann. Soooo ungewöhnlich ist das eigentlich (ehrlich gesprochen) nicht.

Exakt diese Konstellation ging früher mit unserer Sophos UTM problemfrei - nur so zur Info.

Grüße,
mscd

Hallo,

... dann gehöre ich wohl evtl. zu den "wenigen Fällen".

Wir nutzen OPNsense an einer Schule ... mehrere VLANS (Lehrer, Verwaltung, Schüler, Drucker, usw.) ... mehrere VPN-User für Heimarbeit (z.B. in der Verwaltung). Config des OpenVPN-Server ist im Prinzip "listen auf any" (UDP-Port 1194) ... da geht alles sauber (von extern kommend). Die Client-VPN-Config löst den Server per DnyDNS-Eintrag (auf eine unserer externen IP-Adressen, Kablemodem) auf.

Nun kommt der (naheliegende) Fall vor, dass ein Mitarbeiter/Lehrer, wenn er sich mit seinem Laptop im Haus befindet im BYOD-VLAN (mit der selben VPN-Client-Config auf seinem Laptop) eine VPN-Verbindung aufbauen will, um damit eine gesicherte Verbindung ins Verwaltung-Netz (wie von zu Hause aus) zu erhalten.

Grüße,
mscd

P.S.: Anbei noch ein Bilder der Server-Config ... wie gesagt ... die UDP-Pakete erhält der Server ... und schmeißt die obige Fehlermeldung.

Hallo zusammen,

ich stehe gerade vor dem Problem, dass ich OpenVPN von extern (z.B. Handy-Netz) problemfrei nutzen kann. Der Server hört auf "any" (UDP-port 1194). Befinde ich mich im eigenen Netzwerk (mit entsprechender Firewall-Regel, dass z.B. UDP 1194 erlaubt ist, was mir auch im Protokoll bestätigt wird), erhalte ich folgende Fehlermeldung auf dem Log des OpenVPN-Servers (-> siehe Bild im Anhang).

"10.129.0.50:53306 write UDPv6: Can't assign requested address (code=49)"

Hat hier jemand einen "Tipp" auf Lager?

Schöne Grüße und Dank,
mscd

Hello together,

I have some problems in configuring OpenVPN in conjunction with Multi-WAN-LoadBalancing (OPNsense 21.7).
Multi-WAN (two gateways A (default) and B) is working properly but a (external) VPN-connection to gateway B fails.

My OpenVPN-Server is configured to listen to "any" interfaces on UDP standard port. During my error analysis, I read also some pfSense-tutorials, cp.

https://docs.netgate.com/pfsense/en/latest/multiwan/openvpn.html

and I can not figure out why I should make a difference to use the configuration "listening-interface to localhost" in conjunction with corresponding WAN-port-forwarding rules in contrast to a OpenVPN-server-instance, which is configured to listen to "any".

Can give me anybody some technical reason, why the port-forwarding setup is the better one?
Could the problem be related to the route of the answer packets, which perhaps traverse not the same way back to the client as in in-direction?

Best regards,
mscd

Hallo zusammen,

ich arbeite gerade an einem ähnlichen Setup ... was mir derzeit unklar ist:

Worin liegt der Unterschied, falls man bei den OpenVPN-Server-Einstellungen beim listen-interface "any" einstellt, oder man stattdessen das interface "nur" auf "localhost" konfiguriert aber dafür pro WAN-interface ein entsprechendes Port-Forwarding auf localhost konfiguriert?

Wirkt Variante B funktional anders im Multi-WAN-Setup? Irgendwie kann ich da gerade keinen Unterschied erkennen, obwohl diese Vorgehensweise in der Situation OpenVPN + Multi-WAN an diversen Stellen empfohlen wird.

Danke und Grüße,
mdcd

Ja ist auf der B-Firewall aktiviert ... aber da gehts ja eigentlich auch immer um das Tupel Source/Target.

... trotzdem sind wir ein wenig von meiner eigentlichen Frage abgekommen, da ich beim MulltiWan-RoundRobin davon ausgegangen bin, dass auch z.B. mehrere Anfragen (zu verschiedenen Zielen) eines EINZIGEN Clients sauber auf die einzelnen Gateways verteilt werden müssten ... der Algorithmus kann doch nicht so "doof" implementiert sein, dass er alle Anfragen einer Quelle immer auf die selbe Leitung raus schickt, oder etwa doch?

Ok Danke ... ich glaub ich lern echt gerade wieder was dazu ... Danke ...

... als doppeltes NAT lässt sich vermeiden nur auf B müssen für die Subnetze (hinter A) entsprechende Routen gesetzt werden.