Messages

Code Select Expand

opnsense-patch -c plugins 6864606
should do it.

Du legst dir einen Alias an, der die anderen Netze enthält und ersetzt "any" in der Destination durch "!mein_alias".

[client]

As far as I understood the documentation, stunnel supports STARTTLS. Unfortunately at the moment the OPNsense UI does not support picking LDAP as the protocol, only IMAP, POP3 and SMTP. I will create a pull request to include more options, since this seems incredibly useful.

What you then do will be:

- install the os-stunnel plugin
- create a service in client mode
- listen address and port: 127.0.0.1, 389
- target hostname and port: your LDAP server, 389
- protocol: LDAP

And you will be able to use 127.0.0.1:389 without encryption (!) as your LDAP server - which is not a problem, because it's local communication and your LDAP authenticator will see all the clear text content, anyway. Stunnel will then relay the connection with STARTTLS over the network.

Kind regards,
Patrick

Schon, aber die Foundation und das verantwortliche Team arbeiten m.W. erst einmal am Client-Support für aktuelle (Laptop-) Hardware. Infrastructure Mode ist noch Zukunftsmusik.

Worked as documented for me. You can compare the strongswan configuration files before and after.

Dazu, dass man personalisierte Admin-Accounts hat?

Aber ja, die dürfen bei uns alle auch sudo root, deshalb bin ich da ganz entspannt.

Nehmen wir an, es gäbe einen User ohne diese Berechtigung, dann müsste dieser zum Ausnutzen der Lücke doch mindestens irgendwelche sudo-Rechte haben. Also selbst bei einem unprivilegierten RCE wäre das unkritisch.

Hast du vor, die OPNsense zum Access Point zu machen? Lass es, funktioniert in FreeBSD nicht gescheit. 🙂

You define the network to be used for the tunnel. A network is a combination of a prefix and a prefix length, e.g. 192.168.42.0/24. That's established terminology.

"given" is referring to the fact that you define the network in that particular field. Could be replaced with "configured" or "entered" but "Tunnel network" does not make much sense in this sentence.

A dynamic routing protocol like OSPF can do that. Check if OpenWRT supports it. For OPNsense see:

https://docs.opnsense.org/manual/how-tos/dynamic_routing_ospf.html

Leg doch mal auf LAN eine Regel an:

Source: LAN net
Destination: die Fritzbox
Gateway: explizit die Fritzbox als Gateway

und schieb die höher als alles andere, was für den Internet-Verkehr zuständig ist.

Ich vermute, dass dir hier einfach die Gateway-Priorisierung reinspuckt. Ich hab aber selbst kein Multi-WAN, daher nur so ungefähres Wissen, wie das funktioniert.

Doch, natürlich. Den public key vom IOS trägst du auf der OPNsense ein, den public key der OPNsense beim IOS.

Es gibt keinen dedizierten Client und Server bei WireGuard, nur Peers.

Klar. Wozu Peer Generator? Einfach im WG-Client auf IOS die Parameter eingeben.

Endpoint: öffentliche IP-Adresse oder FQDN deiner OPNsense
Address: Adresse des IOS-Geräts im Tunnel
AllowedIPs: lokale Netze hinter (von außen betrachtet) der OPNsense, die du über den Tunnel erreichen willst - 0.0.0.0/0 wenn der ganze Verkehr durch den Tunnel soll

So wie jede andere WireGuard-Konfiguration halt auch ;-)

You configured a blocklist with the wrong URL that returns an HTML page instead of a pure ASCII list.

Alternative 3: OPNsense direkt am Internet (Modem), Fritzbox als LAN-Client für die Telefonie hinter der OPNsense.

Läuft seit Jahren super, die Fritzbox ist eine ganz passable kleine Telefonanlage, die DECT-Handapparate sind gut. Eine 7510 reicht dafür völlig.