Messages

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



Hallo Zusammen,

Das ist mein erster Post hier. Ich habe versucht einen passenden Beitrag zu finden, aber nichts, was zu 100% passt. Daher mein Post. Ich bin noch kompletter OPNsense Neuling, betreibe aber schon seit Jahren ein Homelab mit einer Fritz!Box. Nun wollte ich mein Homelab mit einem managed Switch und OPNSense auf das nächste Level heben.

Ich versuche seit Tagen mein OPNSense mit meinem managed Switch zum laufen zu bekommen. Leider habe ich ein Problem mit der DNS-Auflösung. Ich erhalte zwar innerhalb der VLANs eine IP-Adresse via DHCP, aber die Namensauflösung klappt leider nicht. Ich kann die VLAN-Adresse des OPNSense anpingen, aber ein nslookup schlägt fehl. Ebenfalls ein `nc -vzw 4 <ip-des-opnsense> 53` läuft in einen timeout. Ich nutze für das Debugging ein Arch-Linux Laptop, der sowohl via WLAN (via Port 5), als auch via LAN (Port 3) an den Switch angebunden werden kann. Beim AP handelt es sich um einen TP-Link EAP653, der auch VLAN-Fähig ist und die passenden VLANs konfiguriert hat.

Ich habe ein Zyxel XGS1935 und eine OPNSense in einer VM auf einem Proxmox-Server installiert. Anbei eine kleine Skizze des Netzwerks


Ich habe die folgenden VLANs im Switch konfiguriert:

VLAN1  Management
VLAN20 Heimautomation
VLAN50 Clients

Im folgenden gebe ich nur die Konfigurationsdetails für das VLAN50 aus. Die anderen VLANs identisch konfiguriert und zeigen gleiche Symptome.

In OPNSense habe ich die folgenden VLANs eingerichtet:

Code Select Expand

vlan0.01 [MGMT] vtnet1 (mac-adresse) [LAN] 1 Best Effort (0, default)
vlan0.50 [Clients] vtnet1 (mac-adresse) [LAN] 50 Best Effort (0, default) Internet
vlan01.20 [Heimautomation] vtnet1 (mac-adresse) [LAN] 20 Best Effort (0, default) Heimautomation



Hier beispielhaft die Konfiguration für das Client-Interface (VLAN50) in OPN-Sense.

Code Select Expand

## Basic Configuration
Enable [x] Enable Interface
Lock [x] Prevent interface removal
Identifier opt3
Device vlan0.50
Description Clients

## Generic configuration
Block private networks [ ]
Block bogon networks [ ]
IPv4 Configuration Type Static IPv4
IPv6 Configuration Type None
MAC address [...]
Promiscuous mode [ ]
MTU [...]
MSS [...]
Dynamic gateway policy [ ] This interface does not require an intermediate system to act as a gateway

## Static IPv4 configuration
IPv4 address 172.17.50.253
IPv4 gateway rules Disabled

Hier die Firewall-Regeln für das Client-VLAN50:

Code Select Expand

IPv4 TCP Clients net * Clients address 443 (HTTPS) * * Allow OPNSense HTTPS-Webfrontend from Clients-Net (debugging)
IPv4 * Clients net * * * * * -
IPv4 TCP Clients net * WAN net 443 (HTTPS) * * -
IPv4 TCP/UDP Clients net * WAN net 53 (DNS) * * -
IPv4 TCP/UDP Clients net * Clients address 53 (DNS) * * Allow access to DNS-Servers on the Internet
IPv4 * Clients net * ! PrivateNetworks  * * * Default allow LAN to any rule

Zum Schluss noch die Switch-Konfiguration

VLAN-Setup für VLAN50

Code Select Expand

| Port | VLAN-Member | Tagging    |
| ---- | ----------- | ---------- |
| 1    | 50          | Tx Tagging |
| 2    | -           | -          |
| 3    | 50          | -          |
| 4    | 50          | -          |
| 5    | 50          | Tx Tagging |

Port-Belegungen für VLAN50

Code Select Expand

VLAN50
---
Ports: 2 4 6
Ports: 1 3 5
T/U: - U T
T/U: T U T

Habt ihr eine Idee, was das Problem sein könnte, oder wo ich suchen kann?

Ich habe das Gefühl, dass der Switch korrekt konfiguriert ist. Immerhin kommt ein Ping zum OPNSense durch.

Danke und Grüße,
Michael;