VLAN, Routing funktioniert nicht mehr?!

[Bytechanger]

Hallo,

ich habe bei mir 2 VLANs eingerichtet.
Eins ist für meine Kameras, eins für das Gastnetzwerk.
Vom "Standard"-LAN konnte ich auf eine Kamera im Kameranetz zugreifen (routing).

Das will aber nun nicht mehr, keine Ahnung warum.
Für den Datenverkehr vom LAN ins VLAN ist doch die Firewallregel des LAN zuständig.
Diese hat u.a. die Pass any Regel...

Meine Vermutung ist, dass aus welchen Gründen auch immer, das Routing "defekt" ist.
Nach meiner Erfahrung, wird das Routing für bestehende VLANs doch automatisch erstellt?!

Im System->Routes->Configuration habe ich keine Route, die auf die 10.1.3.0/24 oder das Gastnetz passt.

   10.8.0.0/24   Raspberry_Pi - 172.30.90.115   VPN   
   192.168.177.0/24   Raspberry_Pi - 172.30.90.115   177er   
   192.168.1.0/24           Raspberry_Pi - 172.30.90.115   fern1   
   192.168.178.0/24   Raspberry_Pi - 172.30.90.115   178er

Unter Gateways->Single habe ich den WAN IPv4 als  Upstream Gateway definiert.
    WAN_PPPOE (active)    WAN    XX.XXX.XXX.XXX    ~    ~    ~    Online
   Interface WAN_PPPOE Gateway    

      WAN_GW (active)    WAN    XXXX::XXX:XXX:XXX:XXXX       ~    ~    ~    Online
   Interface WAN_GW Gateway    

        Raspberry_Pi    LAN    172.30.90.115       ~    ~    ~    Online         OpenVPN Server    


----------------------------------------------------------------------------------
Unter Routes->Status steht für das 10.1.3.0 Netz:
ipv4   10.1.3.1   link#8   UHS   0   16384   lo0

--------------------------------------------------------------------------------

Muss ich die Routen für die VLANs manuell noch eintragen?

Auf diese Weise?
   172.16.0.1/16   Null4 - 127.0.0.1   Gastnetz   
   10.1.3.0/24   Null4 - 127.0.0.1   KameraNetz   


Die Komunikation innerhalb der Netze scheinen zu funktionieren.


Ich benötige Hilfe....


Greets

Byte

[Bytechanger]

Hallo,

aktuell kann ich die VLANs aus meinem LAN nicht erreichen.
Leider weiß ich derzeit nicht, wie ich das Problem analysieren und beheben kann.

Ich benötige etwas unterstützung.

Greets

Byte

[JeGr]

Dann musst du schon Details posten. Switch Konfiguration, Interface Konfiguration, Regeln, Routing Tabelle etc.

Prinzipiell: Es wird gar kein Routing "eingerichtet" für VLANs. Jedes lokal angebundene Netz (egal ob LAN oder VLAN) wird direkt zugestellt/erkannt, wenn es auf der Sense aufgelegt ist. Wenn plötzlich von jetzt auf gleich dein Routing nicht mehr geht und du wirklich(!) nichts an der Konfig geändert hast, würde ich mir den Switch anschauen, wo du deine VLANs definiert hast. Denn wenn einfach nichts mehr ankommt, kann die Sense auch nix mehr routen.

Ansonsten einfach mal mit tcpdump / packet capture auf der Sense schauen: einmal am LAN, einmal an dem VLAN wo du hingehst, ob überhaupt Pakete da rauskommen. Hört sich aber eher nach verkonfigurierten Interfaces oder zerbasteltem Switch an.

[Bytechanger]

Hallo,

vielen Dank für die Hilfe.

Ich gehe von einer verkorksten Konfiguration aus.
Ich bin OPNsense newbie und konfiguriere noch, daher meine Vermutung.


Fraglich ist, wie ich sie erkennen kann.
Was soll ich Posten oder nennen?

Am Switch habe ich keine VLAN-Konfig geändert.
Die VLANS kommen Taged an, der DHCP verteilt ja auch IPs.

Sitze aktuell nicht zu Hause, werde etwas nachreichen.


Greets

Byte

[JeGr]

> Was soll ich Posten oder nennen?

Habe ich in meinem Post geschrieben:
>> Dann musst du schon Details posten. Switch Konfiguration, Interface Konfiguration, Regeln, Routing Tabelle etc.

> Die VLANS kommen Taged an, der DHCP verteilt ja auch IPs.

Soweit so gut, wenn die Sense hier DHCP noch sauber spricht/sprechen kann(?) dann könnte das passen. Trotzdem mal in den Switch schauen, wie was wo konfiguriert ist.

[Bytechanger]

Guten Morgen,

da ich derzeit keinen physischen Zugriff auf die Hardware habe, kann ich die Tests erst später durchführen.

Aber ein Blick in das DHCP Log bestätigt meine Annahme, dass die Verbindung grundsätzlich OK sein muss, denn der DHCP verteilt Adressen, ...

Code: [Select]

May 28 09:17:26 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:17:26 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:16:54 dhcpd: DHCPACK on 172.30.90.81 to XX:XX:XX:XX:XX:XX via re1
May 28 09:16:54 dhcpd: DHCPREQUEST for 172.30.90.81 from XX:XX:XX:XX:XX:XX via re1
May 28 09:16:54 dhcpd: from the dynamic address pool for 172.30.90.0/24
May 28 09:16:54 dhcpd: Remove host declaration s_lan_12 or remove 172.30.90.81
May 28 09:16:54 dhcpd: Dynamic and static leases present for 172.30.90.81.
May 28 09:16:22 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:16:22 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:15:18 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:15:18 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:14:14 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:14:14 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:13:10 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:13:10 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:12:39 dhcpd: DHCPACK on 172.30.90.75 to XX:XX:XX:XX:XX:XX via re1
May 28 09:12:39 dhcpd: DHCPREQUEST for 172.30.90.75 from XX:XX:XX:XX:XX:XX via re1
May 28 09:12:39 dhcpd: from the dynamic address pool for 172.30.90.0/24
May 28 09:12:39 dhcpd: Remove host declaration s_lan_8 or remove 172.30.90.75
May 28 09:12:39 dhcpd: Dynamic and static leases present for 172.30.90.75.
May 28 09:12:06 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:12:06 dhcpd: DHCPREQUEST for 10.1.3.3 fromXX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:11:03 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:11:03 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:09:59 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:09:59 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:08:55 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:08:55 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:07:52 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:07:52 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XXvia re1_vlan50
May 28 09:06:48 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:06:48 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:05:45 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XXvia re1_vlan50
May 28 09:05:45 dhcpd: DHCPREQUEST for 10.1.3.3 fromXX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:04:41 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:04:41 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:03:38 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:03:38 dhcpd: DHCPREQUEST for 10.1.3.3 from 74:da:38:e2:e7:07 via re1_vlan50
May 28 09:02:34 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:02:34 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:01:29 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:01:29 dhcpd: DHCPREQUEST for 10.1.3.3 fromXX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:01:13 dhcpd: DHCPACK on 172.30.90.69 to XX:XX:XX:XX:XX:XX via re1
May 28 09:01:13 dhcpd: DHCPREQUEST for 172.30.90.69 from XX:XX:XX:XX:XX:XX via re1
May 28 09:01:13 dhcpd: from the dynamic address pool for 172.30.90.0/24
May 28 09:01:13 dhcpd: Remove host declaration s_lan_2 or remove 172.30.90.69
May 28 09:01:13 dhcpd: Dynamic and static leases present for 172.30.90.69.
May 28 09:00:24 dhcpd: DHCPACK on 10.1.3.3 to XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 09:00:24 dhcpd: DHCPREQUEST for 10.1.3.3 from XX:XX:XX:XX:XX:XX via re1_vlan50
May 28 08:59:21 dhcpd: DHCPACK on 10.1.3.3 to 74:da:38:e2:e7:07 via re1_vlan50
Also findet nach meiner Vermutung eine Verbindung statt. Es scheint irgendwo anders der Wurm drin zu sein...

PING von OPNsense auf 10.1.3.1 (OPNsense selber) läuft sowohl im VLAN selber, als auch aus dem LAN.
PING auf 10.1.3.3 geht komplett verloren, auch im VLAN selber....

Code: [Select]

# /sbin/ping -S '10.1.3.1' -c '3' '10.1.3.3'
PING 10.1.3.3 (10.1.3.3) from 10.1.3.1: 56 data bytes
36 bytes from 62.vvv.xxx.yyy: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 c7a4   0 0000  40  01 98ff 10.1.3.1  10.1.3.3

36 bytes from 62.vvv.xxx.yyy: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 23b1   0 0000  40  01 3cf3 10.1.3.1  10.1.3.3

36 bytes from 62.vvv.xxx.yyy: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 1e47   0 0000  40  01 425d 10.1.3.1  10.1.3.3


--- 10.1.3.3 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Was mir auffällt ist, bei diesem Ping wird die

Gateway IPv4    62.vvv.xxx.yyy vom WAN Nicht meine InternetIP,
aufgeführt!

Stimmt hier etwas mit der Gatewayconfig nicht??
Was ist die IPv4 Adresse des WAN Interfaces?
Es wird auch der falsche Gateway genutzt....


Packet Capture

Code: [Select]

11:54:07.565066 XX:XX:XX:XX:XX:XX > XX:XX:XX:XX:XX:XX, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.3.1 tell 10.1.3.8, length 46
11:54:07.565073 XX:XX:XX:XX:XX:XX > XX:XX:XX:XX:XX:XX, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.3.1 is-at XX:XX:XX:XX:XX:XX, length 28
11:54:09.829381 XX:XX:XX:XX:XX:XX > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 374: (tos 0x0, ttl 64, id 22405, offset 0, flags [none], proto UDP (17), length 360)
    10.1.3.3.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX, length 332, xid 0xa40bdfbc, secs 65535, Flags [none] (0x0000)
  Client-IP 10.1.3.3
  Client-Ethernet-Address XX:XX:XX:XX:XX:XX
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Request
    Client-ID Option 61, length 7: ether XX:XX:XX:XX:XX:XX
    MSZ Option 57, length 2: 1500
    Vendor-Class Option 60, length 41: "dhcpcd-6.7.1:Linux-4.9.35+:armv6l:BCM2835"
    Hostname Option 12, length 11: "raspberrypi"
    T145 Option 145, length 1: 1
    Parameter-Request Option 55, length 14:
      Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway
      Domain-Name-Server, Hostname, Domain-Name, BR
      NTP, Lease-Time, Server-ID, RN
      RB, Option 119
11:54:38.661520 XX:XX:XX:XX:XX:XX > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 60)
    10.1.3.8.42501 > 10.1.3.1.53: [udp sum ok] 56907+ AAAA? 2.pool.ntp.org. (32)
11:54:43.654508 XX:XX:XX:XX:XX:XX > XX:XX:XX:XX:XX:XX, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.3.1 tell 10.1.3.8, length 46
11:54:43.654514 XX:XX:XX:XX:XX:XX > XX:XX:XX:XX:XX:XX, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.3.1 is-at XX:XX:XX:XX:XX:XX, length 28
11:54:48.656222 XX:XX:XX:XX:XX:XX > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 60)
    10.1.3.8.45285 > 10.1.3.1.53: [udp sum ok] 1551+ AAAA? 2.pool.ntp.org. (32)


Greets

Byte

[Bytechanger]

und, was mich wundert, unter Routes->-Status

----------------------------------------------------------------------------------
Unter Routes->Status steht für das 10.1.3.0 Netz:
ipv4   10.1.3.1   link#8   UHS   0   16384   lo0

--------------------------------------------------------------------------------

Es gibt keine 10.1.3.0/24 Route!

Greets

Byte

[Bytechanger]

OK, das Problem scheint gelöst zu sein.

Unter Routes->Status war keine für die VLANs mit .0/24 eingetragen (was das System ja automatisch macht).
Nachdem ich die VLANs gelöscht und komplett neu eingerichtet habe, waren die Routen vorhanden und nun gehts.

Ich hoffe es bleibt dabei und die Routen verschwinden nicht wieder...


Greets

Byte

[JeGr]

> Nachdem ich die VLANs gelöscht und komplett neu eingerichtet habe, waren die Routen vorhanden und nun gehts.
> Ich hoffe es bleibt dabei und die Routen verschwinden nicht wieder...

Dann mutmaße ich, dass du ggf. beim Einrichten und Umbauen der VLANs vielleicht mal die virtuellen IFs an und aus gemacht hattest bis das System ggf. etwas verwirrt war Eine Systemroute zu einem aufliegenden Interface (auch wenns ein virtuelles ist), sollte eigentlich nie gelöscht werden.

> Gateway IPv4    62.vvv.xxx.yyy vom WAN Nicht meine InternetIP,

Das hattest du korrekt analysiert. Wenn der Ping plötzlich zum WAN rausläuft, dann hat man entweder sehr ... abenteuerliche ... Regeln gebaut oder irgendwas auf System-Routen Ebene läuft schief. Ich hatte nach dem Post erst daran gedacht, dass ggf. auf dem VLAN IF ein Tippfehler mit reingespielt haben könnte, aber nun egal, es läuft und sollte so etwas nochmals vorkommen hast du damit hoffentlich auch ein wenig "Munition" um besser zu debuggen

Grüße

[Bytechanger]

Hallo,

irgendwo scheint in der GUI noch ein Fehler zu liegen, der zu dem dauerhaften Entfernen der VLAN-Routen führt.
Nun waren die Routen wieder weg!

Sie waren noch da.
Dann habe ich einen OpenVPN Client eingerichtet.
Dann habe ich den OpenVPN-Adapter als Interface hinzugewiesen.
Ich war in Outbound-Regeln und habe als Interface Wireguard und OpenVPN hinzugefügt.

Später habe ich das Interface wieder gelöscht.
Dann waren die Routen zu den VLANs weg!

Könnte es etwas bringen, wenn ich die Konfig sichere und wieder einspiele?
Ich habe keinen Bock wieder alle VLANs samt Firewallregeln neu einzurichten...
Muss ich etwas beachten?

EDIT: OK, wenn ich in die VLAN-Interfaces gehe und einfach SAVE klicke, werden die Routen wieder angelegt ?! Sehr komisch


Greets

Byte

[JeGr]

> Ich war in Outbound-Regeln und habe als Interface Wireguard und OpenVPN hinzugefügt.

Evtl. mal Wireguard sein lassen und schauen ob sonst alles funktioniert? Auch wenn WG gerade der letzte Schrei und mega hipp ist, ist WG auf FreeBSD immer noch highly unstable und alpha Status (und zudem anders implementiert als im Linux Kernel). Verstehe auch nicht warum da jetzt alle steil gehen wie nix Gutes bevor man das erstmal ordentlich wachsen und stabil werden lässt. Läuft ja nicht weg.