OPNsense Forum
International Forums => German - Deutsch => Topic started by: Bytechanger on May 26, 2019, 06:02:44 pm
-
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
-
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
-
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.
-
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
-
> 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.
-
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, ...
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....
# /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
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
-
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
-
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
-
> 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
-
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
-
> 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.