Topics

1

German - Deutsch / Routing von OpenVPN traffic durch route-based IPsec S2S-Tunnel

« on: June 11, 2021, 01:24:12 am »

Hallo allerseits,

folgendes ist gegeben:

1. Office A <---> Office B verbunden mit einem route-based IPsec Tunnel gemäss:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html

2. Diverse statische Routen auf der OPNsense in Office A mit Zielen in Office B via Gateway des obigen IPsec Tunnels.

3. OpenVPN-Server für Road Warrior in Office A.

Office A kann auf die Ziele in Office B zugreifen. Zumindest kann ich von der OPNsense aus Ziele in Office B anpingen.

Frage: Was muss ich wie konfigurieren, damit auch Road Warrior die sich mit Office A verbinden auf Ziele in Office B zugreifen können?

Ich habe es bereits versucht indem ich die Routen gemäss obigem Punkt 2 an die OpenVPN-Clients gepushed habe, das alleine scheint aber nicht zu reichen.

Unter Firewall: Rules: OpenVPN ist vorerst nur eine allow any to any Regel eingerichtet.

Was fehlt noch?

2

German - Deutsch / [Solved] Suricata will nicht mit URLhaus?

« on: April 08, 2019, 07:08:17 pm »

Hallo Leute,
ich beschäftige mich gerade zum ersten Mal mit Suricata auf einer APU2 von PC Engines mit OPNsense 19.1.5_1 drauf.

Der Test mit dem Regelset OPNsense-App-detect/test funktioniert (WAN, Hyperscan, IPS, Alert und Drop). Die Eicar-Signatur wird erkannt, blockiert und unter Alarms erscheint ein entsprechender Eintrag.

Wenn ich das Regelset abuse.ch/URLhaus aktiviere und nach dem rule reload complete eine verseuchte Datei herunterlade (z. B. https://urlhaus.abuse.ch/url/1227/), dann wird diese URL vom IPS durchgelassen und es erscheint kein Eintrag unter Alarms.

Ich habe es auch mal nur im IDS-Modus und mit der LAN-Schnittstelle (IGB1) im promiscuous mode (wegen VLANs) versucht. Verhält sich auch nicht anders.

Funktioniert bei euch Suricata mit URLhaus?

Nach einem Reboot steht folgendes im Log:

Code: [Select]

suricata: [100237] <Notice> -- all 5 packet processing threads, 4 management threads initialized, engine started.
suricata: [100237] <Warning> -- [ERRCODE: SC_WARN_DEFAULT_WILL_CHANGE(317)] - in 5.0 the default for decoder event stats will go from 'decoder.<proto>.<event>' to 'decoder.event.<proto>.<event>'. See ticket #2225. To suppress this message, set stats.decoder-events-prefix in the yaml.
suricata: [100135] <Notice> -- This is Suricata version 4.1.3 RELEASE

3

German - Deutsch / Firewall "härten"

« on: March 14, 2019, 01:58:20 pm »

Ich strähle gerade meine Firewall-Regeln durch und gleichzeitig bin ich das eine oder andere Gelesene betreffend "Härtung" umzusetzen. Dabei merke ich, dass ich Verständnisschwierigkeiten bezüglich den Floating Rules habe. Vor allem dann, wenn "Direction out" im Spiel ist. Dabei geht es mir ungefähr wie in diesem Thread hier: https://forum.netgate.com/topic/123029/solved-curious-floating-rules-behavior
Die Verunsicherung bleibt auch nach dem Lesen von: https://docs.netgate.com/pfsense/en/latest/book/firewall/floating-rules.html,
weil ich bei eigenen Tests das Verhalten nicht so recht nachvollziehen konnte. Irgendwie scheine ich es nicht so ganz kapiert zu haben.
Wie auch immer, könntet ihr bitte mal meine Konfiguration gemäss Anhang prüfen betreffend:

1. Verhindern, dass RFC 1918 Verkehr das WAN-Interface verlässt, Umsetzung gemäss:
https://docs.netgate.com/pfsense/en/latest/firewall/preventing-rfc1918-traffic-from-exiting-a-wan-interface.html

2. ICMP-Regeln, Umsetzung gemäss:
https://de.wikipedia.org/wiki/Firewall-Regelwerk#ICMP-Regeln

Und dann noch in die Runde gefragt: Habt ihr noch weitere solcher "Härtungs-Tipps" zum Teilen?

4

18.7 Legacy Series / IGMP proxy cannot load VLAN interfaces?

« on: September 06, 2018, 08:20:47 pm »

Hi folks
In the German part of the forum nobody has reacted yet, maybe it will work here. 

Problem: The IGMP proxy doesn't seem to load VLAN interfaces, see second outputs here:
https://forum.opnsense.org/index.php?PHPSESSID=f5ok07kdd6hojtmpahcjloeti7&topic=9570.msg43701#msg43701
Normal interfaces (not VLAN) are loaded normally, as can be seen in the first outputs.

Can someone reproduce this? Is this a known problem? Or is it just on my box?

Thanks.
Stefan

5

German - Deutsch / Multicast IPTV will nicht über VLAN-Switch

« on: August 30, 2018, 06:50:26 pm »

Hallo Leute,
ich versuche vergeblich Multicast IPTV über einen Smart-managed-Switch via VLAN-Trunk zu transportieren. Folgende Konstellationen habe ich getestet:
OPNsense --> Notebook: funktioniert
OPNsense --> "dummer" Switch --> Notebook: funktioniert
OPNsense --> Fritzbox (im IP-Client-Modus) --> Notebook: funktioniert
OPNsense <-- VLAN-Trunk --> ZyXEL-Switch (mit oder ohne IGMP-Snooping) --> Notebook: funktioniert nicht
OPNsense <-- VLAN-Trunk --> MikroTik-Switch (mit oder ohne IGMP-Snooping) --> Notebook: funktioniert nicht

Die VLAN-Konfiguration auf den Smart-managed-Switches funktioniert normal, nur Multicast scheint irgendwo auf der Strecke liegen zu bleiben.
Muss man bei einem VLAN-Setting bezüglich Multicast noch irgendwas Zusätzliches beachten?

Damit hier hat das nichts zu tun, oder? https://github.com/opnsense/plugins/issues/590

Danke für jegliche Inputs.

Gruss, Stefan

6

German - Deutsch / Erfahrungen mit Multicast IPTV (TV7) von Init7?

« on: August 24, 2018, 05:22:11 pm »

Hallo Leute,
seit geraumer Zeit ist TV7 ohne Mehrkosten in den Internetabos von Init7 enthalten. Guter Zeitpunkt um sich mit IPTV, Multicast und IGMP-Proxy zu beschäftigen.

Ich habe gemäss folgenden Anleitungen rumprobiert:
https://www.init7.net/de/support/faq/TV-andere-Geraete/
https://blog.pilif.me/2018/05/22/fiber7-tv-behind-pfsense/

Einfaches Testsetting: OPNsense 18.7.1_3 mit os-igmp-proxy, Notebook mit VLC media player direkt an der Sense angeschlossen. --> Funktioniert nicht, ich bekomme nicht mal ein Bild.

Bevor ich unter die Motorhaube schaue: Hat jemand von euch TV7 von Init7 via OPNsense erfolgreich am Laufen?

Grüsse, Stefan

7

German - Deutsch / Google SafeSearch & Co.

« on: September 04, 2017, 04:09:31 pm »

Hallo allerseits

Ich wollte auf meiner OPNSense zu Hause mal kurz (ha, ha) Google SafeSearch & Co. wegen den Kidz in Betrieb nehmen.

Zuerst dachte ich, mach erst mal auf die Schnelle was mit Unbound so im Stil von:
https://support.opendns.com/hc/en-us/articles/227986807-How-to-Enforcing-Google-SafeSearch-YouTube-and-Bing
https://forum.opnsense.org/index.php?topic=3423.msg11265#msg11265
http://www.iamasuperuser.com/enforce-google-safe-search-using-pfsense/

Sobald ich aber via GUI --> Unbound DNS --> General --> Custom options --> include: /var/unbound/safesearch.conf z. B. zum Testen nur diese eine Zeile local-data: "www.google.ch A 216.239.38.120" hinzufüge, lässt sich anschliessend Unbound nicht mehr starten.

Via GUI --> Host overrides hat es glaub ich geklappt, aber gemäss den diversen Anleitungen müsste man ja für alle möglichen Google-Domains (https://www.google.com/supported_domains) einen Eintrag erstellen.

Fragen:

• Wie kann ich die Ursache für den nicht startenden Dienst eingrenzen?
• Gibt es direkt mit OPNsense eine elegantere Lösung als mit Unbound, z. B. mit Squid? Ansätze wie hier beschrieben haben bei mir auf die Schnelle nicht funktioniert: https://stackoverflow.com/questions/6592727/how-to-make-an-squid-cache-internal-url-rewrite
• Hat jemand von euch Google SafeSearch & Co. auf einer OPNsense am Laufen und möchte seine Erfahrungen hier bereitstellen?

Gruss, Stefan

8

German - Deutsch / [GELÖST] Speicherort für customized Squid-Konfig.-Dateien?

« on: September 04, 2017, 03:36:41 pm »

Hi Leute,
ich verwende eine customized Squid-Konfig. und habe bis jetzt die Konfig.-Dateien so abgelegt:
/usr/local/opnsense/service/templates/OPNsense/Proxy/squid.user.pre_auth.conf
/usr/local/opnsense/service/templates/OPNsense/Proxy/squid.user.post_auth.conf
Das zusammengefügte Ergebnis konnte man dann jeweils in der /usr/local/etc/squid/squid.conf betrachten.

Ich glaube das geht nicht mehr, oder? Ich habe die eine relevante Datei jetzt so abgelegt:
/usr/local/etc/squid/pre-auth/squid.user.pre_auth.conf
Funktioniert und überlebt einen Reboot.

Frage: Ist das so gedacht und wird die Datei auch ein Update überleben? Ist das Thema irgendwo dokumentiert?

Gruss, Stefan

9

German - Deutsch / Erfahrungen mit Swisscom? TV, IGMP, DHCP Option 60, VLAN 10, IPv6 usw.

« on: August 29, 2017, 12:49:57 pm »

Hallo Schweizer/-innen

Jetzt wo die Swisscom die SIP Credentials herausgibt
https://www.swisscom.ch/de/privatkunden/hilfe/festnetz/sip-credentials.html
werden langsam aber sicher Lösungen ohne Swisscom-Router interessant.

Neben dem nun behobenen "SIP-Problem" müssen ja aber auch noch Dinge wie Swisscom TV (IGMP), DHCP Option 60, VLAN10, IPv6 und vielleicht noch mehr berücksichtigt werden. Beim Querlesen durchs Internet habe ich zwar diverse, aber eher ältere Anleitungen und Tipps gefunden, meist im Zusammenhang mit pfSense.

Darum meine Frage hier im Forum: Hat jemand Erfahrungen mit OPNsense ohne vorgeschaltetem Swisscom-Router die er/sie hier teilen möchte? Ist die Konfiguration und der laufende Betrieb stressfrei oder ein ewiges gefrickel? Gibt es Einschränkungen gegenüber dem Betrieb mit Swisscom-Hardware?

Gruss, Stefan

10

German - Deutsch / PPPoE-Einwahl funktioniert nur mit Standard-Interface-Zuordnung

« on: January 06, 2017, 12:52:02 pm »

Hallo Leute

Ich hatte gestern mit einem sonderbaren Verhalten betreffend PPPoE-Einwahl zu kämpfen.

Ausgangslage: OPNsense 16.7.12 auf einer PC Engines APU2C4 hinter einem Swisscom Centro Business 2 mit aktiviertem PPPoE-Passthrough:
http://documents.swisscom.com/product/1000260-Connectivity_Geraete_/Documents/Spezifikationen/Centro_Business2_PPPoE_Passthrough-de.pdf

Nach der Installation von OPNsense habe ich auf der Konsole die Schnittstellen Zugewiesen: igb0 = WAN, igb1 = LAN, igb2 = OPT.
Anschliessend im GUI das WAN-Interface von DHCP auf PPPoE umgestellt und entsprechende Zugangsdaten hinterlegt. Die Einwahl hat darauf nie funktioniert.
Nach langer Fehlersuche bin ich dann auf diesen Thread hier gestossen:
https://forum.opnsense.org/index.php?topic=3666.msg12534#msg12534
Und tatsächlich, nach einem Reset to factory defaults (via GUI) hat die Einwahl sofort geklappt.
Die Interfaces waren nach dem Reset wie folgt belegt: igb0 = LAN, igb1 = WAN und igb2 = OPT.
Sobald ich die Reihenfolge der Interfaces anders zuwies, funktionierte die PPPoE-Einwahl nicht mehr. Egal ob die Neuzuordnung vor oder nach dem Wechsel von DHCP auf PPPoE oder via Konsole oder GUI erfolgte.
Dummerweise habe ich die LOGs nicht rauskopiert. :-(

Scheint mir ein Bug zu sein. Falls ich etwas übersehen haben sollte bin ich froh um Aufklärung.

Gruss, Stefan

11

German - Deutsch / VLAN

« on: October 24, 2016, 11:51:25 pm »

Hallo zusammen

Ausgehend von einer OPNsense mit drei Netzwerkschnittstellen (WAN, LAN1, LAN2) und vier VLANS an LAN1 (Trunk). Angenommen ich will einen zusätzlichen VLAN-Trunk mit einem Teil der bestehenden VLANs auch noch an LAN2 haben, wie gehe ich da am besten vor?
Gewünschte VLANS auch noch an LAN2 anlegen und mit den entsprechenden VLANS an LAN1 bridgen wäre konfigurierbar (Funktion noch nicht getestet) aber das scheint mir eine komische Konfiguration zu sein. Da gibt es sicher eine schlauere Lösung, oder?

Gruss, Stefan

12

German - Deutsch / [GELÖST] Proxy: Probleme mit "SSL Domain/IP only"

« on: September 07, 2016, 09:46:13 pm »

Hallo allerseits

Ich mache gerade meine ersten Gehversuche mit dem Proxy im transparenten Modus.

1. Enable Transparent HTTP proxy: sieht gut aus.
2. Enable SSL mode: sieht gut aus.
3. SSL Domain/IP only: will irgendwie nicht so.

Gewisse Seiten funktionieren normal, andere gar nicht. Beim Aufruf von heise.de und google.ch erscheint allenfalls noch ein Titel im Tab, aber es wird kein Inhalt geladen. Die Seite lädt unendlich lange, kein Timeout, nichts.
Im Log erscheint folgendes beim Aufruf von google.ch:

Code: [Select]

2016/09/07 21:15:05 kid1|   SECURITY ALERT: on URL: www.youtube.com:443
2016/09/07 21:15:05 kid1|   SECURITY ALERT: Host header forgery detected on local=216.58.210.14:443 remote=192.168.200.122:59133 FD 103 flags=33 (local IP does not match any domain IP)
2016/09/07 21:15:02 kid1|   SECURITY ALERT: on URL: accounts.google.com:443
2016/09/07 21:15:02 kid1|   SECURITY ALERT: Host header forgery detected on local=216.58.210.13:443 remote=192.168.200.122:59130 FD 88 flags=33 (local IP does not match any domain IP)
2016/09/07 21:14:57 kid1|   SECURITY ALERT: on URL: www.google.ch:443
2016/09/07 21:14:57 kid1|   SECURITY ALERT: Host header forgery detected on local=172.217.16.195:443 remote=192.168.200.100:33773 FD 22 flags=33 (local IP does not match any domain IP)
2016/09/07 21:14:42 kid1|   SECURITY ALERT: on URL: www.google.ch:443
2016/09/07 21:14:42 kid1|   SECURITY ALERT: Host header forgery detected on local=172.217.16.195:443 remote=192.168.200.100:23512 FD 14 flags=33 (local IP does not match any domain IP)
2016/09/07 21:14:23 kid1|   Error negotiating SSL connection on FD 25: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown (1/0)
Liegt das an meiner Konfiguration oder ist das ein Bug? Hat jemand "SSL Domain/IP only" erfolgreich am Laufen?

LG, Stefan

13

German - Deutsch / Webfilterprofile

« on: August 29, 2016, 01:03:57 pm »

Hallo allerseits,
ich versuche gerade die "Kindersicherung" der FRITZ!Box auf der OPNSense umzusetzen.

Das Ziel sieht so aus:
1. Geräte der Kategorie "Kleinkinder" dürfen nur zu bestimmten Zeiten auf Webseiten gemäss Whitelist (Webfilter) zugreifen.
2. Geräte der Kategorie "Teens" dürfen nur zu bestimmten Zeiten auf Webseiten mit Einschränkungen (Webfilter) zugreifen.
3. Geräte der Kategorie "Erwachsene" dürfen zu jederzeit unbeschränkt ins Netz. Wobei eine minimale Webfilterung wie z. B. Malware und Werbung natürlich ganz praktisch wäre.

Ich kann den Geräten per DHCP eine fixe IP-Adresse zuweisen, diese in Aliasse zusammenfassen und Zeitpläne verwenden. Soweit so gut, aber ich scheitere beim filtern. Ich bringe nur zwei Kategorien hin: 1. Proxy mit den festgelegten ACLs und 2. Kein Proxy verwenden. Übersehe ich etwas?