Messages

Was ist was? Wenn du mir die Felder nicht drüber schreibst ...

Sorry, dachte da alles ein Stern ist ergeben sich die Felder :-). Hier mit feldern:

Code Select Expand

Protocol   Source  Port       Destination  Port.   Gateway  Schedule  Description
IPv4       *    VPNWG net  *            *       *        *         *


Haben die Server, auf denen die Dienste laufen, denn die OPNsense als Default-Gateway?

Ja, opnsense ist der Standardgateway überall.

Habe gerade mal nachgeschaut. Der Reverse-Proxy hatte mehrere Schnittstellen. Ich hatte die Schnittstelle, die ins alte WAN geht noch als default gesetzt. Nachdem ich die Schnittstelle, die im Client-Netz hängt auf default gesetzt hatte hat es geklappt!

Danke für den Tipp!

Jetzt sind zumindest die Zeilen mit dem UDP-Port 443 auch grün, komme aber trotzdem nicht auf die Dienste drauf.

Die Regel ist: IPv4 *   VPNWG net   *   *   *   *   *   

Danke für den Hinweis. Habs das Gateway mal rausgeschmissen. Allerdings habe ich nachwievor das Problem. Was mich stuzig macht ist, dass ich im Log die erste Zeile sehe (grün) VPNWG in, 10.8.0.x -> 192.168.5.2 (Caddy) TCP443. Und danach kommt die Zeile (grün) Clients out, 10.8.0.x -> 192.168.5.2 (Caddy) TCP443. So als ob da irgendwo eine Route fehlen würde?

Hallo Zusammen,

ich habe auf meinem OPNSense eine Wireguard-Instanz aufgesetzt und zwei peers angelegt (iPhone, Laptop). Ich versuche Alles so einzurichten, dass ich von Unterwegs auf lokale Dienste zugreifen kann, die über einen Reverse-Proxy (Caddy) nur intern erreichbar sind.

Der Handshake scheint zu funkionieren und ich sehe auch einen grünen Haken am Peer wenn ich über die Weboberfläche reinschaue. Wenn ich allerdings versuche einen Dienst über den Revproxy zuerreichen, dann baut sich dieser nicht auf.

Wenn ich in das Live-log von OPNSense reinschaue, dann sehe eine grüne Zeile, die scheinbar auf Port 443 funktioniert. Die Zeilen danach finde ich aber Merkwürdig. Zumal sehe ich, dass der Peer scheinbar versucht über den UDP-Port 443 auf den Reverse-Proxy zu gehen (siehe Screenshot)??

Hier meine Peer-Konfiguration:

Code Select Expand

[Interface]
PrivateKey = ***
Address = 10.10.0.11/32
DNS = 10.10.0.1

[Peer]
PublicKey = vbhuQBxaP0Sh+LoboRlIUyE72TQ3FaPzO1ybd4tywX8=
PresharedKey = ***
Endpoint = meinedomaine.com:57444
AllowedIPs = 0.0.0.0/0


Was die Firewall angeht, habe ich das Wireguard-Interface (VPNWG), dass ich vorher über Assignments erstellt habe, in eine Gruppe "TrustedClients" gesteckt. In der Gruppe ist auch das normale Client-Interface drin (Laptops, PC's, Handys). Für das Client-Netz habe ich eine recht ausführliche Firewall-Tabelle gemacht und würde diese gerne einfach auf das VPNWG-Netz anwenden wollen - da ich im Prinzip über das VPN die gleichen Dienste erreichen möchte.
Ja, es ist der Reverse-Proxy als Firewall-Regel enthalten (TCP80, TCP443).

Was ich mich Frage, ob das richtig ist, dass ich das VPNWG-Interface in die Gruppe gesteckt habe, oder ob ich nochmal alle Regeln für das VPN kopieren muss?

Meine Fragen:
- Muss ich irgendwas beachten, wenn der Reverse-Proxy in einem anderen VLAN als Wireguard läuft?
- Muss ich die Wiregard-Schnittstelle in ein VLAN stecken? Und müsste ich an meinem Switch noch was anpassen, oder reicht dafür die die Konfig in OPNSense?
- Brauche ich ggf. eine statische Route?

Was ich sonst noch eingetellt habe:
- Outbound-NAT (hybrider Modus): VPNWG -> NAT Address (Interface Address)
- Unter System->Gateways->Configuration habe ich für Wireguard ein Gateway eingetragen (IPV4, Prio: 255, IP-Adress: 10.8.0.1)

Danke und grüße,
Michael;

Kleiner Nachtrag. Ich hab mich gewundert, warum ich trotz einer ICMP-Regel den Drucker vom Clientnetz nicht anpingen konnte. Dann habe ich noch zwei Dinge entdeckt, die ich reinkonfiguriert aber dann wieder vergessen hatte. Das eine war eine statische Route. Das viel interessantere war eine Gruppenregel, die für das Clientnetz zwar angewendet wurde, ich diese aber nicht gesehen habe, da sie ausgeblendet war.

Die Regel war im Prinip wie folgt:

Code Select Expand

IPv4 * Trusted net * !PrivateNetworks * * *

PrivateNetworks ist ein Alias für die bekannten privaten Netze (192..,172..,10.).
Da die Regel ein ,,First Match" war, hat diese immer zuerst gegriffen und den PING (und anderes) blockiert.

Nachdem ich eine ,,Last Match" daraus gemacht habe, konnte ich auch wieder ,,pingen" und die Konfigurationsoberfläche vom Drucker erreichen :-)

Genau das ist der Punkt, den ich am wenigsten verstehe ... Drucker, Scanner, Lautsprecher ... kommt bei mir alles ins vertrauenswürdige Familiennetz. Ich kauf da halt keinen China-Kram, sondern Geräte mit Doku, was sie tun. Lautsprecher z.B. ist eine Airport Express an der Stereoanlage. Drucker Brother mit Ethernet und SNMP ... was tun denn moderne Drucker so? Ich hatte noch nie einen, der nachhause telefoniert hätte. Meiner braucht sogar fürs Firmware-Update ein externes Tool.

Isolieren tue ich ganz anderen Kram 🙂

Ja tatsächlich ist wahrscheinlich der Aufwand zu groß, als das man dieses "Business-Gerät" in ein seperates VLAN steckt. Ich hatte hier noch einen Medion WLAN Lautsprecher, den ich gerne weiternutzen würde. Allerdings wird der über eine Fragwürdige App konfiguriert. Für solche Fälle wollte ich lernen, wie man die Geräte separiert. Und grundsätzlich bin ich der Meinung, dass wenn es keinen guten Grund gibt, dann dürfen die Geräte in ihrem eigenen VLAN/WLAN sich tummeln.

Ich schließe dann den Fall für mich ab und werfe den Drucker in das Client-Netz.

Ich hab auf dem Laptop das Avahi-Discovery Tool verwendet. Damit kann ich den Drucker finden und bekomme diverse Dienste mit der IP aus dem Drucker-VLAN angezeigt. Unter anderem finde ich den UNIX-Print Dienst auf der IP-Adresse.

Und dann kann es natürlich noch sein, dass da noch Regeln im Clients-Net fehlen. Pakettrace hilft.

Hab's mal getraced, kann da aber nicht wirklich was sehen. Was mir auffällt ist, dass ich bei der gesamten Kommunikation nicht einmal die IP-Adresse vom Drucker sehe. Im pcap sehe ich kein mDNS. Ich sehe aber (reproduzierbar) im OPNsense Firewall log mehrere mDNS-Requests, die aber von IP's (Source) im WAN Netz kommen und dementsprechend von der Firewall geblockt werden.

Kann es sein, dass die mDNS query irgendwie im WAN-Netz landet und dann die Geräte im WAN-Netz versuchen darauf zu antworten?

Und abschließend ganz pragmatisch: weshalb den Drucker nicht in das Netz, in dem auch die Clients sind, die ihn benutzen? So hab ich das. Sehe keinen Grund, so ein Gerät zu isolieren.

Drucker sind halt böse :-). Ja ich vermute, dass ich langfristig auch auf diese Lösung umsteigen werden. Ich wollte mich aber generell mal mit der Materie verraut machen, da ich noch andere Geräte habe (WLAN-Lautsprecher) die ich dann doch gerne in einem seperaten VLAN hätte.

Hallo Zusammen,

ich habe das gleiche Problem mit meinem aktuellen Setup. Ich habe zwei VLANs (VLAN50 und VLAN68). Im VLAN68 soll der Drucker sein und im VLAN50 alle Drahtlosen clients.
Ich habe bereits das multicast-Plugin installiert und für die beiden VLANs aktiviert. Ich habe die Firewallregeln für Multicast DNS im Client und Drucket-VLAN eingetragen. Ich sehe im Firewall log, dass das Multicast beim Drucker ankommt. Ich kann auch den Drucker via Handy und auch am Laptop via Bonjour Discovery finden.

Allerdings habe ich das Problem, dass auf meinem iPhone bei einem Druckversuch nach dem Auswählen des Druckers nach kurzer Zeit der Drucker wieder aus der Auswahl verschwindet.

Auf meinem Arch-Laptop kann ich zwar den Drucker einrichten, aber die Druckeinstellungen reagieren sehr träge, und wenn ich was Drucken will, dann wird kein Drucker angegeben.

Habt ihr eine Idee, was das Problem sein könnte? Ich habe die Vermutung, dass noch irgendwelche Firewallregeln fehlen.

Hier die relevanten Firewallregeln im Clients-Netz

Code Select Expand

IPv4 TCP/UDP     Clients net     *     DruckerScanner net     631     *     *             
IPv4 TCP/UDP     Clients net     *     DruckerScanner net     515     *     *       
IPv4 TCP/UDP     Clients net     *     MulticastDNS      5353 - 5354     *     *             
IPv4 TCP     Clients net     *     DruckerScanner net     80 (HTTP)     *     *     
IPv4 TCP     Clients net     *     DruckerScanner net     443 (HTTPS)     *     *

Die Firewallregeln im DruckerScanner net

Code Select Expand

IPv4 ICMP     Clients net     *     DruckerScanner net     *     *     *             
IPv4 TCP     Clients net     *     DruckerScanner net     631     *     *             
IPv4 TCP     Clients net     *     DruckerScanner net     80 (HTTP)     *     *     
IPv4 TCP     Clients net     *     DruckerScanner net     443 (HTTPS)     *     *

PS: Ich habe zwar regeln in den Tabellen für das Erlauben von PINGs/ICMP und den Zugriff auf das Drucker-Webfrontend, aber ich kann weder den Drucker anpingen, noch komme ich aus dem Clientnetz auf das Webfrontend des Druckers.

Danke und Grüße

PS: Ich hoffe, dass es ok ist wenn ich diesen alten Thread recycle.

Kann man Posts in dem Forum als gelöst markieren?

...
Jupp, der wars. Anscheinend war der Wireguard-VPN irgendwie falsch konfiguriert, sodass der den kompletten Traffic geblockt hat - uff.

Ich hab als Tunneladresse die 10.10.0.0/24 angegeben. Ich vermute, dass das der Fehler war.

Moment, mir fällt gerade ein, dass ich den Wireguard-VPN abgeschaltet habe, da ich den immer in den Firewall-Logs gesehen hatte. Ich schalte den mal wieder ein und versuche es dann nochmal.

Jupp, der wars. Anscheinend war der Wireguard-VPN irgendwie falsch konfiguriert, sodass der den kompletten Traffic geblockt hat - uff.

Am Client Gerät, nehm ich an?

Ja genau.

Ich hab jetzt mal einen trace über Diagnostics und Packet Capture gemacht. Ich sehe im prinzip das gleiche Bild. Eine menge TCP SYN in Richtung Internet. Nach einiger Zeit kommen dann ganz viele TCP Retransmissions.


Ich habe jetzt mal den curl auf heise im Terminal einige Zeit mal laufen lassen. Plötzlich hat curl am Terminal was ausgegeben. Ich hab danach mal im Browser heise.de versucht und plötzklich komme ich ins Internet??
Ich bin ein wenig irritiert, da ich meines Wissens nichts verändert habe.

Der Speedtest gibt mir auch mehr oder weniger die Bandbreite meines DSLs zurück - ich verstehe das nicht.

Moment, mir fällt gerade ein, dass ich den Wireguard-VPN abgeschaltet habe, da ich den immer in den Firewall-Logs gesehen hatte. Ich schalte den mal wieder ein und versuche es dann nochmal.

Hi,

ich weiß nicht, wo man in OPNSense Packet Capture machen kann. Ich hab mal einfach meinen Wireshark angeworfen, auf die dst-adresse gefiltert und mal einen curl auf heise.de gemacht.

Ich sehe ganz viele TCP-Retransmissions. Ich vermute, dass die Rückpakete irgendwie nicht durchkommen.

 

Ich habe sowohl den OPNSense als auch den Switch neu gestartet (damit implizit auch die AP's).

Der DNS, den ich in OPNSense eingetragen habe ist die Fritz!Box. Im Fritz!Box-LAN habe ich auch noch einen Pi-hole laufen, der eigentlich keine Probleme machen sollte.

Edit: Der Outbound-NAT steht auf "Hybrid". Hatte aber auch mal automatic probiert.

Edit2: Die automatischen outbound-Regeln sind:

Code Select Expand


WAN Clients networks, Heimautomation networks, LAN networks, Loopback networks, 127.0.0.0/8 Auto created rule for ISAKMP
 
WAN Clients networks, Heimautomation networks, LAN networks, Loopback networks, MGMT networks, 127.0.0.0/8 Auto created rule



[Ping-Tests]

Ping-Tests
Ping auf die Switch-IP geht

Code Select Expand

PING 172.17.50.254 (172.17.50.254) 56(84) Bytes an Daten.
64 Bytes von 172.17.50.254: icmp_seq=1 ttl=254 Zeit=6.30 ms
64 Bytes von 172.17.50.254: icmp_seq=2 ttl=254 Zeit=11.1 ms
64 Bytes von 172.17.50.254: icmp_seq=3 ttl=254 Zeit=6.43 ms
64 Bytes von 172.17.50.254: icmp_seq=4 ttl=254 Zeit=4.74 ms

Ping auf die OPNSense-Client-IP geht (mit pfctl -d)

Code Select Expand

PING 172.17.50.253 (172.17.50.253) 56(84) Bytes an Daten.
64 Bytes von 172.17.50.253: icmp_seq=1 ttl=64 Zeit=2.54 ms
64 Bytes von 172.17.50.253: icmp_seq=2 ttl=64 Zeit=2.34 ms
64 Bytes von 172.17.50.253: icmp_seq=3 ttl=64 Zeit=1.91 ms

Ping auf OPNSense-WAN Adresse geht (mit pfctl -d)

Code Select Expand

PING 192.168.127.9 (192.168.127.9) 56(84) Bytes an Daten.
64 Bytes von 192.168.127.9: icmp_seq=1 ttl=64 Zeit=35.9 ms
64 Bytes von 192.168.127.9: icmp_seq=2 ttl=64 Zeit=5.31 ms
64 Bytes von 192.168.127.9: icmp_seq=3 ttl=64 Zeit=5.87 ms

Ping auf Fritz!Box geht (mit pfctl -d)

Code Select Expand

PING 192.168.127.1 (192.168.127.1) 56(84) Bytes an Daten.
64 Bytes von 192.168.127.1: icmp_seq=1 ttl=63 Zeit=5.41 ms
64 Bytes von 192.168.127.1: icmp_seq=2 ttl=63 Zeit=5.03 ms
64 Bytes von 192.168.127.1: icmp_seq=3 ttl=63 Zeit=5.21 ms

Ping auf 1.1.1.1 geht scheinbar nicht

Code Select Expand

PING 1.1.1.1 (1.1.1.1) 56(84) Bytes an Daten.
^C
--- 1.1.1.1 Ping-Statistiken ---
62 Pakete übertragen, 0 empfangen, 100% packet loss, time 62493ms

Diverse nslookup's
Der Client verwendet den OPNSense-DNS 172.17.50.253 (wird via DHCP bereitgestellt)

Code Select Expand

nslookup heise.de
;; Got SERVFAIL reply from 127.0.0.53
Server: 127.0.0.53
Address: 127.0.0.53#53

---

nslookup heise.de 172.17.50.253
;; Got SERVFAIL reply from 172.17.50.253
Server: 172.17.50.253
Address: 172.17.50.253#53

** server can't find heise.de: SERVFAIL

---

nslookup heise.de 1.1.1.1     
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; no servers could be reached