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

#1
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:


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
#2
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
#3
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):

(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
#4
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
#5
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
#6
Hallo zusammen,

ich nutze (Gründe vorhanden ;-)) eine OPNsense 21.7 (A) hinter einer weiteren 21.7er (B) ... sozusagen "Router A an Router B". Die zweite OPNsense (B) macht LoadBalacing im Multi-WAN auf zwei 1 GBit/s Kabelmodems. Nun beobachte ich leider, dass eigentlich nur eines der beiden Modems tatsächlich genutzt wird, obwohl eine entsprechende Gateway-Gruppe im gleichen Tier (und identischer Gewichtung) von mir eingerichtet wurde, und es eine entsprechende Firewall-Regel mit Policy-Einstellung auf die Gateway-Gruppe gibt.

Für mich stellt sich gerade die Frage, wie das RoundRobin-Verfahren hier bei der OPNsense im Detail funktioniert? Könnte es evtl. ein Problem sein, dass mein LoadBalancer (die zweite OPNsense (B) in der obigen Konstruktion) "nur" als Quelladresse diverser Clientanfrage, welche sich hinter der ersten OPNsense (A) befinden, immer nur die (gleiche) IP von der A-Kiste sieht (wegen der NAT)?
Ich dachte eigentlich, dass dies kein Problem sein dürfte, da im RoundRobin doch alle neuen Anfragen (egal welche Quell-IP) gleichmäßig auf die verschiedenen Gateways verteilt werden ... oder sehe ich das gerade falsch?

Besten Dank und schöne Grüße,
mscd
#7
German - Deutsch / Filter-LOG-History
July 13, 2021, 12:49:22 PM
Hallo zusammen,

unter /var/log/filter.log findet man (meiner Kenntnis nach) die raw-Log-Einträge des Paketfilters ... mich wundert hier nur gerade, dass diese Datei in meinem Fall nur Einträge der letzten Minuten beinhaltet ... lässt sich (zumindest per Shell) ein längerfristiges Filter-Log der Firewall einsehen/durchsuchen?

Schöne Grüße,
mscd
#8
Hallo zusammen,

ich betreibe zwei OPNsense-Appliances im HA-Verbund über CARP. Die PFSYNC-Leitung ist hierbei eine direkte Verbindung zwischen Firewall A und Firewall B, wobei auf dem zugehörigen Interface eine "allow-ANY-Regel" im Firewall-Ruleset hinterlegt ist.
Mir ist gerade unklar, ob ich hierbei noch zusätzlich für jedes weitere Interface, welches ich per CARP (und virtueller IP) hochverfügbar machen will, noch eine ALLOW-ANY-Regel für das CARP-Protokoll hinterlegen muss. Da ich mit mehreren VLANS arbeite, habe ich derzeit eine Interface-Gruppe angelegt ... darauf dann im Firewall-Ruleset "Allow CARP from ANY to ANY".
Da ich gerne unnötige Regeln vermeiden möchte, stellt sich für mich die Frage, ob bei eigenständiger/dedizierter PFSYNC-Leitung überhaupt noch CARP-Traffic auf den anderen Interfaces läuft und welche Regeln hier entsprechend zu pflegen sind.
In der HA-Doku der pfSense kann ich - komischer Weise - nämlich keinen Hinweise auf entsprechende Firewall-Regeln für die CARP-Interfaces finden.

Schöne Grüße und Dank,
mscd
#9
Hello folks,

is it possible to get the (transparent) squid web-proxy working with multi-wan-load-balancing? I am used to that behavior from a Sophos SG230 and now I am wondering that this doesn't seem to work (without special hacks) on the OPNsense 21.x.

Best regards,
mscd
#10
Hallo zusammen,

an meiner OPNsense hängen derzeit zwei DSL-Router. Gemäß folgender Anleitung

https://www.thomas-krenn.com/de/wiki/OPNsense_Multi_WAN

habe ich eine WAN-LoadBalancing-Gruppe erstellt, welche auch soweit scheinbar funktioniert.
Da der gesamte HTTP(S)-Verkehr diverser lokaler Subnetze per NAT-Regel auf der OPNsense transparent durch den dortigen squid-WebProxy geleitet wird, ist mir aktuell unklar, ob der squid-proxy ebenfalls das WAN-LoadBalancing-Gateway benutzt oder den gesamten Traffic "nur" über das aktuelle Standard-Gateway anfrägt.

Ich benötige den transparenten squid-Proxy für einen kategorisierten WebFilter (blacklisting). Seitens einer mir bekannten Sophos UTM läuft dort auch jeglicher WebProxy-Traffic sauber über das Load-Balacing ... ist das bei der OPNsense auch so möglich?

Schöne Grüße und besten Dank für jegliche Hinweise,
mscd
#11
Hallo zusammen,

gibt es einen eleganten "Hack" um das Firewall-Log von den ganzen, gedroppten Broadcast-Einträgen (an x.x.x.255er Adressen, bzw. mDNS 224.0.0.251/252/253, usw.) zu befreien?

Besten Dank,
mscd
#12
Hallo zusammen,

ist es möglich den Web-Proxy so zu konfigurieren, dass "volle" (man-in-the-middle) SSL inspection (inkl. clam AV) nur für Clients ausgewählter Subnetze durchgeführt wird.
Problem ist, dass ich generell auf allen Subnetzen bei http und https einen Kategorieren-Filter (z.B. per shallalist) einsetzen würde, nur aber bei einigen Subnetzen zusätzlich die SSL inspection, da ich nicht bei allen Clients für die Bereitstellung des entsprechenden CA-Zertifikats sorgen kann.

Schöne Grüße,
mscd
#13
Hallo zusammen,

ich setze derzeit ein Testsetup mit zwei OPNsense-Appliances (Master/Backup-HA) auf, was soweit ganz gut klappt. Bei der Inbetriebnahme von OpenVPN bin ich nun auf das Problem gestoßen, dass ich per externer VPN-Verbindung (VPN-Netz 10.200.2.0/24) zwar die Master-Firewall (im Netz 10.12.0.0/24) erreiche, aber nicht die Backup-Firewall (auch im Netz 10.12.0.0/24).
Grund hierfür wird wohl meiner Einschätzung nach die Tatsache sein, dass die Backup-Firewall nicht "weiß" wo es die Anfragen der VPN-Clients (aus 10.200.2.0/24) zurücksenden soll, so dass dort dann einfach das Standardgateway (des WAN-Interface) genommen wird, was natürlich nicht klappen kann.

Kann mir hier jemand einen Tipp geben, wie man in einem HA-Setup eine "saubere Erreichbarkeit" von Master- und Backup-Appliance per VPN konfigurieren kann.

Schöne Grüße und besten Dank,
mscd
#14
Hallo zusammen,

ich arbeite mich gerade seit einigen Tagen intensiver in die Möglichkeiten der OPNsense ein. Aktuell nutze ich noch zwei Sophos SG310 in einem active/active-cluster ... die XG geht meiner meiner Meinung nach alleine von der usability des Interfaces her (aus Sicht der SG) gar nicht ... aber eh egal ... da mich das OPNsense-Projekt mehr und mehr überzeugt.

Aktuell beschäftige ich mich mit dem IDS/IPS. Ähnlich der Sophos UTM würde ich gerne (für ausgehwählte) Threads ein Mail-Notify erhalten. Die Anleitung, wie man den monit-service hinsichtlich IPS-alterts konfiguriert, habe ich schon erfolgreich durchlaufen. Was mir aktuell noch nicht gefällt, ist das Verhalten von monit, dass für jeden IPS-alert über die monit-Bedingung

content = "blocked"

ein Notify erzeugt wird. IPS-Regeln wie dshield erzeugen hierbei aber dann natürlich fast minütlich eine Warnmeldung, wesshalb ich gerne wüsste, ob man die monit-Bedingung um logische Bedingungen erweitern kann.

Also in der Art ... notify NUR bei ,,blocked" aber (beispielweise) NICHT bei ,,dshield"

Ich hoffe man versteht mein Problem/Anfrage.

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