Zugriff z.B. von GREEN auf BLUE funktioniert nicht

Started by opnbnuser, October 15, 2020, 07:33:33 PM

Previous topic - Next topic
Hallo zusammen, bin Anfänger und habe bereits vor einiger Zeit eine OPNSense installiert.

Diese hängt hinter einer Fritzbox (192.168.8.1/24) für den Internetzugang via DSL und funktioniert soweit problemlos mit GREEN (192.168.10.1/24), RED (192.168.8.101) und der Fritzbox (192.168.8.1) als Gateway.

Ich habe nun das Interface BLUE aktiviert und ein Gerät (Laptop) angeschlossen.
Eine IP Adresse habe ich via DHCP bekommen (192.168.20.100). Internet hat nicht automatisch funktioniert. Gelöst habe ich dies momentan durch eine ALLOW ALL Rule auf BLUE (analog zu GREEN). Internet funktioniert, soweit ok.

Allerdings:
Von BLUE auf GREEN funktioniert der Ping nur auf das Interface, nicht auf einen PC aus GREEN, d.h. von 192.168.20.100: PING 192.168.10.2 funktioniert, PING 192.168.10.23 (PC) funktioniert NICHT.
Von GREEN auf BLUE ist es ebenso, von 192.168.10.23: PING 192.168.20.2 funktioniert, PING 192.168.20.100 (Laptop) funktioniert NICHT.

Was fehlt da?

Viele Grüße
Dirk


Netzwerke:
RED   192.168. 8.0/24 OPNSense-IF:192.168. 8.101
GREEN 192.168.10.0/24 OPNSense-IF:192.168.10.2
BLUE  192.168.20.0/24 OPNSense-IF:192.168.20.2



Übersicht Netzwerk:
                  :
                  : DSL
                  :
            .-----+------.
            |  FritzBox  |------------+- WLAN Clients 192.168.8.0/24 via Fritzbox
            '-----+------'            |
                  | 192.168.8.1       +- DHCP via Fritzbox
                  | WANGW on OPNSense
              WAN |
        RED (em0) |
    192.168.8.101 |
            .-----:----------.
            |  OPNSense      +------- ORANGE (em1) inaktiv
            |  4 x LAN       |
            |  + LAN Onboard +------- OPT3   (re0) inaktiv
            '-----:------:---'
  192.168.10.2/24 |      | 192.168.20.2/24   
      GREEN (em3) |      | BLUE   (em2)   
              LAN |      | (WLAN 
                  |      |
   ...-----+------+      +-----+------...
      LAN Clients    Clients
192.168.10.23 etc.        192.168.20.100 etc.

October 15, 2020, 07:44:22 PM #1 Last Edit: October 15, 2020, 07:49:02 PM by micneu
kurz mal für mich zum verständnis:
- RED = WAN?
- GREEN = LAN?
- BLUE????

PS: habe mir deine Text Netzwerkplan angeschaut, jetzt habe ich es verstanden.
TIPP: Du kannst diese komischen bezeichnung in der sense zu aussage krätigen namen ändern z. B.
LAN, WAN, WLAN.

das ist dann eindeutig
Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser  |
Router/Firewall: pfSense+ 23.09  |
Hardware: Netgate 6100

October 15, 2020, 07:48:20 PM #2 Last Edit: October 15, 2020, 07:50:40 PM by opnbnuser
- RED = WAN
- GREEN = LAN
- BLUE = WLAN

Zur Zeit ist WLAN an der Firtzbox aktiv und das möchte ich ändern.
Wenn der Zugriff funktioniert, nur bestimmte WLAN Geräte auf das LAN zugreifen lassen.

Wenn man sich mit dem Grundprinzip von Firewalls und in diesem Falle insbesondere mit OPNsense beschäftigt hätte, wüsstest du woran es liegt.

Üblicherweise erstellt man die Regeln auf dem Interface, wo die Pakete an der OPNsense eintreffen.

D.h. Wenn du von einem ins Netz A in ein Netz B möchtest, erstellst du eine Regel auf Interface A mit Destination Netz B mit entsprechenden Protokoll/Port oder eben any. Dann dürfen Pakete von Netz A nach Netz B und die Antwortpakete dürfen auch wieder zurück.
,,The S in IoT stands for Security!" :)

October 15, 2020, 08:03:47 PM #4 Last Edit: October 15, 2020, 08:16:38 PM by opnbnuser
Genau das verstehe ich nicht. Auf GREEN gibt es die automatisch erstellte "Default allow LAN to any rule". Damit sollte ich laut deiner Aussage bzw. dem Grundprinzip der Firewalls doch überall hin kommen, einschliesslich BLUE, oder? Funktioniert aber nicht. Und das war die Frage.

Anbei die Rules auf GREEN. Reicht das aus, um auf ein Gerät in BLUE zu kommen?


Die Regel sollte jeglichen Verkehr von Green erlauben. Bist du sicher, dass das Laptop pingbar ist? Windows spielt einem da gerne Streiche.

Sonst einfach unter Firewall in die Live View schauen und überprüfen, ob da ICMP Requests geblockt werden. Dürfte aber nicht. Denke es liegt am Laptop.
,,The S in IoT stands for Security!" :)

October 15, 2020, 08:49:32 PM #6 Last Edit: October 15, 2020, 08:55:28 PM by opnbnuser
Ja, der Laptop ist pingbar, wenn ich ihn z.B. an der Fritzbox verbinde. Dort bekommt er die *.8.135, diese kann ich von meinem PC/Workstation *.10.178 in GREEN pingen. Deaktiviere ich die Verbindung des Laptops zur Fritzbox, dann geht der Ping nicht mehr. Also ist es der Laptop, der auf den Ping antwortet, und kein anderes Gerät.

Die gleiche ALLOW ANY Rule wie auf GREEN habe ich dann auch auf BLUE erstellt, und es ist dort das gleiche: Ich kann den PC/Server in GREEN (.10.23) nicht anpingen, das Interface aber schon (.10.2).
Deaktiviere ich die ALLOW ANY Rule in BLUE, dann kann ich von BLUE aus auch das Interface (.10.2) nicht mehr anpingen.

Anbei der Liveview mit einem Ping von GREEN PC .10.178 auf BLUE Laptop .20.100. Das sieht für mich so aus, als ob alles ok ist. Trotzdem funktioniert der Ping nicht.

Ich bin ratlos.

Ich bleibe dabei, dass der Laptop die Ursache sein könnte. Beim Netzwerk drauf geachtet, dass Windows das neue Green Netz als privates Netz seiht und nicht als öffentliches? Das passiert gerne mal.
Dann lässt Windows keine Pings durch.
Im Log wird ja nix geblockt.
,,The S in IoT stands for Security!" :)

October 15, 2020, 09:14:39 PM #8 Last Edit: October 15, 2020, 09:22:04 PM by opnbnuser
Der Laptop ist nicht die Ursache. Habe gerade den Laptop an BLUE angeschlossen (.20.100) und ihn von der OPNSense aus der Shell angepingt: Funktioniert einwandfrei.

Es ist ja auch von BLUE=>GREEN das Gleiche wie von GREEN=>BLUE:
Das Interface im anderen Netz ist bei aktiver FW Rule pingbar, aber die Netzwerkgeräte sind es nicht.

64 bytes from 192.168.20.100: icmp_seq=63 ttl=128 time=0.582 ms
64 bytes from 192.168.20.100: icmp_seq=64 ttl=128 time=0.481 ms
^C
--- 192.168.20.100 ping statistics ---
65 packets transmitted, 65 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.440/0.535/0.603/0.040 ms
root@OPNsense:~ # ping 192.168.20.100
PING 192.168.20.100 (192.168.20.100): 56 data bytes
64 bytes from 192.168.20.100: icmp_seq=0 ttl=128 time=0.578 ms
64 bytes from 192.168.20.100: icmp_seq=1 ttl=128 time=0.511 ms
64 bytes from 192.168.20.100: icmp_seq=2 ttl=128 time=0.490 ms
^C
--- 192.168.20.100 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.490/0.526/0.578/0.037 ms
root@OPNsense:~ #

Hast du bei Outbound NAT was eingestellt? Mich wundert der Name der Regel, die da beim ICMP angewandt wird.
,,The S in IoT stands for Security!" :)

Tatsächlich war das was drin, habe ich dann deaktiviert, ändert aber auch nichts.

Bevor ich jetzt weitersuche, mache ich besser mal ein
4) Reset to factory defaults   

Irgendwas ist hier nicht geheuer mit dem Ding.

Hoffe trotzdem auf Rückmeldung, ob es nun funktioniert wie gewünscht  :)
,,The S in IoT stands for Security!" :)

October 16, 2020, 12:15:40 PM #12 Last Edit: October 16, 2020, 12:59:49 PM by opnbnuser
So, OPNSense zurückgesetzt und die Interfaces in der Konfig getauscht und die Verkabelung umgesteckt, sieht jetzt so aus:


*** OPNsense.workgroup: OPNsense 20.7.3 (amd64/OpenSSL) ***

LAN (em0)       -> v4: 192.168.10.2/24          <--- LAN
OPT1 (em1)      -> v4: 192.168.20.2/24          <--- WLAN
OPT2 (em2)      -> v4: 192.168.30.2/24
OPT3 (re0)      -> v4: 192.168.40.2/24
WAN (em3)       -> v4: 192.168.8.101/24         <--- WAN mit Fritzbox 192.168.8.1


LAN funktioniert mit PC/WS 192.168.10.178 und PC/Server 192.168.10.23.
Internetzugriff automatisch vorhanden nach der Installation aus LAN.

Firewallrules LAN:
      IPv4 *    LAN net    *    *    *    *    *    Default allow LAN to any rule    
      IPv6 *    LAN net    *    *    *    *    *    Default allow LAN IPv6 to any rule

Ping von OPNSense via SSH gegen den Laptop auf OPT1 funktioniert:

Enter a host name or IP address: 192.168.20.100

PING 192.168.20.100 (192.168.20.100): 56 data bytes
64 bytes from 192.168.20.100: icmp_seq=0 ttl=128 time=0.534 ms
64 bytes from 192.168.20.100: icmp_seq=1 ttl=128 time=0.504 ms
64 bytes from 192.168.20.100: icmp_seq=2 ttl=128 time=0.498 ms

--- 192.168.20.100 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.498/0.512/0.534/0.016 ms

Press ENTER to continue.


Tja, was soll ich sagen, wie vermutet: Es hat sich nichts geändert.

@192.168.10.178: PING 192.168.20.100 liefert NIX:
C:\Users\Donnie>ping 192.168.20.100

Ping wird ausgeführt für 192.168.20.100 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 192.168.20.100:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),


@192.168.10.178: PING 192.168.20.2 also gegen das OPT1 Interface funktioniert aber:
C:\Users\Donnie>ping 192.168.20.2

Ping wird ausgeführt für 192.168.20.2 mit 32 Bytes Daten:
Antwort von 192.168.20.2: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.20.2: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.20.2: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.20.2: Bytes=32 Zeit=4ms TTL=64

Ping-Statistik für 192.168.20.2:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 4ms, Maximum = 4ms, Mittelwert = 4ms


@192.168.10.178: ipconfig /all liefert auf ethernet:
Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Connection (2) I218-V
   Physische Adresse . . . . . . . . : D0-50-99-45-FE-11
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.10.178(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.10.2
   DNS-Server  . . . . . . . . . . . : 192.168.10.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert


@192.168.20.100: Ping gegen die Schnittstelle 192.168.20.2 liefert per default auch NIX, das ist aber klar, denn es ist keine FW Rule definiert. Das soll auch gar nicht funktionieren. Woanders hin natürlich auch nicht.

Füge ich die ALLOW ALL rule auf OPT1 hinzu,
Protocol Source Port Destination Port Gateway Schedule Description
Automatically generated rules
IPv4 * * * * * * * OPT1/WLAN allow ALL

dann:
@192.168.20.100: PING 192.168.20.2 gegen das lokale Interface funktioniert.
@192.168.20.100: PING 192.168.8.1 gegen die Fritzbox funktioniert.
@192.168.20.100: PING 8.8.8.8 gegen WAN funktioniert.
@192.168.20.100: PING 192.168.10.23 gegen LAN/Server funktioniert NICHT

Somit zurück zu meiner ursprünglichen Frage:
Was fehlt hier? Bzw. was mache ich falsch?


Siehst Du denn die Pakete in der Live View an der OPNsense? Dazu musst Du die entsprechenden Regeln für das Logging aktivieren.

Ist der Client im OPT1 per WLAN oder direkt per LAN im Netz?
Wenn per WLAN was für ein Access Point ist das?

Hast Du in den Interface-Einstellungen die Option "Block private networks" aktiviert?
,,The S in IoT stands for Security!" :)

October 16, 2020, 12:58:29 PM #14 Last Edit: October 16, 2020, 01:02:17 PM by opnbnuser
Quote from: Gauss23 on October 16, 2020, 12:25:41 PM
a) Siehst Du denn die Pakete in der Live View an der OPNsense? Dazu musst Du die entsprechenden Regeln für das Logging aktivieren.

b) Ist der Client im OPT1 per WLAN oder direkt per LAN im Netz?
c) Wenn per WLAN was für ein Access Point ist das?

d) Hast Du in den Interface-Einstellungen die Option "Block private networks" aktiviert?

a) muss ich schauen: Was muss ich aktivieren? Gibts da einen Link zum Manual?
b) Momentan Direktverbindung Netzwerkkabel
c) tut momentan nix zur Sache, da Netzwerkkabel
d) Nein, nicht aktiviert. Auf keinem Interface, auch nicht auf WAN, da dies ja nicht das echte WAN ist, sondern das lokale Netz der Fritzbox.

Ich probiere später mal alternativ OPT3, das ist die Onboard Karte, der Rest ist eine 4Port Intel/HP. Kann mir aber nicht vorstellen, dass es daran liegt.