Guten Tag,
ich bin neu bei OpnSense, stehe vor einem für mich scheinbar nicht lösbaren Problem und hoffe darauf, dass sich hier jemand finden lässt, der mir freundlicherweise behilflich sein möchte. Um die Funktion/Eignung von OpnSense zu testen, betreibe ich dieses aktuell testweise in einer virtuellen Maschine und der Einfachheit halber aktuell über nur eine einzelne Netzwerkschnittstelle. Im späteren Produktivbetrieb wird das sicherlich abweichen. Ich hoffe, ich kann die Problemstellung hierzu ausreichend beschreiben.
Anforderung (auf die Problemstellung beschränkt):
- OpnSense wird als Gateway/Router und Firewall im lokalen Netzwerk eingesetzt.
- OpnSense verbindet sich mit einem externen Firmennetzwerk via L2TP over IPsec (mobiler Client an Watchguard).
- OpnSense ermöglicht den Zugriff aus dem lokalen Netzwerk auf ein oder mehrere festgelegte Subnetze im externen Firmennetzwerk.
- OpnSense verhindert Zugriffe aus dem externen Firmennetzwerk in das lokale Netzwerk.
Ist-Zustand:
- LAN interface (lan, vtnet0), Subnetz 192.168.178.0/24, Gateway: 192.168.178.1
- WAN interface (wan, vtnet1), no carrier, down
- VPN/IPsec (type: IPv4 IKE, remote host: 12.34.56.78, local subnets: 192.168.178.66/32, remote subnets: 12.34.56.78/32), State: installed & routed
- Point-to-Point (type: l2tp, link interface: LAN, local ip: none, gateway: 12.34.56.78), Status: up, Interface: l2tp0
- Interface "ext" (assigned device: l2tp0)
- Gateway "EXT_L2TP" (gateway: 10.0.50.101)
- Route (network: 10.0.23.0/24, gateway: EXT_L2TP - 10.0.50.101)
Zwischenstand:
- ICMP echo requests in externes Firmennetz an 10.0.23.141 über Konsole des OpnSense antworten erfolgreich.
Problem:
- ICMP echo requests über einen Rechner (192.168.178.2) aus dem lokalen Netzwerk gegen 10.0.23.141 erhalten keine Antwort ("Request timed out").
- Remote Desktop-Verbindung gegen 10.0.23.141:3389 schlägt fehl.
Bisherige Diagnose / Versuche:- NAT outbound rule (interface: ext, source: "LAN net", destination: "10.0.23.0/24", NAT address: interface address) hinzugefügt.
- Log Files/Live View: Zeigt erfolgreichen Eintrag (interface: ext, source: 10.0.50.174:29768, destination: 10.0.23.141:3389, proto: tcp, label: "let out anything from firewall host itself (force gw)")
- Diagnostics/pfInfo/Nat: Zeigt erfolgreiche Verbindung (keine Block-Einträge zu sehen)
@1 nat log on l2tp0 inet from (vtnet0:network:1) to 10.0.23.0/24 -> (l2tp0:0) port 1024:65535
[ Evaluations: 235 Packets: 13 Bytes: 664 States: 2 ]
[ Inserted: uid 0 pid 79222 State Creations: 2 ]
- Interfaces/Diagnostics/Packet Capture (interface "ext") zeigt, dass die Pakete erfolgreich über die VPN-Verbindung ausgehend geroutet und "genattet" werden. Eine Antwort wird ebenfalls empfangen, aber scheinbar dann nicht zurück an den Absender geroutet:
No. Time Source Destination Proto. Len Info
1 0.000000 10.0.50.161 10.0.23.141 ICMP 64 Echo (ping) request id=0x1118, seq=686/44546, ttl=127 (reply in 2)
2 0.015610 10.0.23.141 10.0.50.161 ICMP 64 Echo (ping) reply id=0x1118, seq=686/44546, ttl=127 (request in 1)
3 0.077754 10.0.50.161 10.0.23.141 TCP 56 46777 → 3389 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
4 0.093838 10.0.23.141 10.0.50.161 TCP 56 3389 → 46777 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1360 WS=1 SACK_PERM=1
5 1.106391 10.0.23.141 10.0.50.161 TCP 56 [TCP Retransmission] 3389 → 46777 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1360 WS=1 SACK_PERM=1
6 3.120018 10.0.23.141 10.0.50.161 TCP 56 [TCP Retransmission] 3389 → 46777 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1360 WS=1 SACK_PERM=1
7 3.401663 10.0.50.161 10.0.23.141 TCP 56 24492 → 3389 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
8 3.417707 10.0.23.141 10.0.50.161 TCP 56 3389 → 24492 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1360 WS=1 SACK_PERM=1
9 4.430111 10.0.23.141 10.0.50.161 TCP 56 [TCP Retransmission] 3389 → 24492 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1360 WS=1 SACK_PERM=1
10 5.001119 10.0.50.161 10.0.23.141 ICMP 64 Echo (ping) request id=0x1118, seq=687/44802, ttl=127 (reply in 11)
11 5.017070 10.0.23.141 10.0.50.161 ICMP 64 Echo (ping) reply id=0x1118, seq=687/44802, ttl=127 (request in 10)
12 6.402551 10.0.50.161 10.0.23.141 TCP 56 [TCP Retransmission] 24492 → 3389 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
13 6.441014 10.0.23.141 10.0.50.161 TCP 56 [TCP Retransmission] 3389 → 24492 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1360 WS=1 SACK_PERM=1
14 7.125663 10.0.23.141 10.0.50.161 TCP 56 [TCP Retransmission] 3389 → 46777 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1360 WS=1 SACK_PERM=1
- Gebe ich OpnSense nicht nur für das Subnetz 10.0.23.0/24 auf meinem lokalen Rechner (192.168.178.2) an, sondern direkt als Standard-Gateway, wird zumindest der Traffic über den ISP korrekt geroutet (Web Browser funktionieren).
- Das testweise Deaktivieren der Firewall-Funktionalität in OpnSense hat an dem Problem nichts geändert.
Ich hoffe, mir kann hier jemand weiterhelfen. Ich nehme an, bzw. hoffe, dass ich nur irgendeine Kleinigkeit übersehe. Falls weitere Informationen benötigt werden, gerne einfach fragen.
Vielen Dank
Ich konnte das Problem nun ausfindig machen. Ein typisches OSI Layer 8 Problem - der Benutzer war zu dumm. Ich habe die Tatsache ignoriert, dass die Reihenfolge der Firewall Regeln durchaus relevant ist. Im Ergebnis griff die Subnetz-Route nicht, da diese durch die Standard-Route überlagert wurde. Der einzige Grund, warum überhaupt Pakete raus gingen, war die lokale Subnetzroute der OpnSense.
Vielen Dank dennoch an diejenigen, die zumindest mitgelesen haben. :-)
@svvenni2k bitte screenshot von den betreffenden firewallregeln.
und schau dir das howto von thomas kren an, da ist alles erklärt.
Gesendet von iPad mit Tapatalk Pro