VPN-Subnutz nicht aus dem LAN erreichbar

[guest27848]

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)

Code Select Expand


@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:

Code Select Expand


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

[guest27848]

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]

Moin,

super das Du es lösen konntest! Ich bin leider auch ein "dummer" Benutzer und habe das "gleiche" Problem, kriege es aber nicht gelöst.
Ich hänge mich hier ran, weil ich denke, wer das löst löst auch mein Problem  ;)

Ich denke das auch bei mir das Problem mit den Firewall Regeln herrscht, da die pings an das VPN Netz ein Time out bekommen. Habe nur Deine Lösung nicht verstanden.
Welche Regeln hast du verändert/hinzugefügt?
Weiß leider gerade auch nicht wie ich es besser beschreiben soll, ausser ich schreibe alles so detailliert auf wie Du?

Danke für jede Hilfe

Grüße Swen

[micneu]

@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