Wireguad Regel hat keinen Einfluss

[bforpc]

Moin,

ich habe den Wireguad Server anhand dieser Anleitung

Code: [Select]

https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_VPN_f%C3%BCr_Road_Warrior_einrichten eingerichtet.

Ich habe eine WAN Regel, welche den Port für die Wireguad erlaubt (laut Anleitung).
Aber die Firewall Regeln in Rules/Wireguard haben scheinbar keine Wirkung. Egal ob "erlaube" oder "verbiete" Regeln aktiv sind, der Zugriff ist immer vollständig erlaubt - was nicht gewünscht ist.

Ich möchte einen Client nicht vollen Zugriff auf das gesamte Netz geben.
Wie kann ich das bewerkstelligen?

Bfo

[mimugmail]

Floating rules?

[Scanline]

Kannst du deine Regeln posten, am Besten floating, WireGuard und falls vorhanden die fuer das wireguard interface.

[bforpc]

Hallo,

bei Floating existiert nur  eine

Code: [Select]

IPv4 * * * * * * * und 14 auto addierte:

Code: [Select]

  IPv4+6 * * * * * * * Default deny rule
  IPv6 IPV6-ICMP * * * * * * IPv6 requirements (ICMP)
  IPv6 IPV6-ICMP (self) * fe80::/10,ff02::/16 * * * IPv6 requirements (ICMP)
  IPv6 IPV6-ICMP fe80::/10 * fe80::/10,ff02::/16 * * * IPv6 requirements (ICMP)
  IPv6 IPV6-ICMP ff02::/16 * fe80::/10 * * * IPv6 requirements (ICMP)
  IPv6 IPV6-ICMP :: * ff02::/16 * * * IPv6 requirements (ICMP)
  IPv4+6 TCP/UDP * * * * * * block all targetting port 0
  IPv4+6 TCP/UDP * * * * * * block all targetting port 0
  IPv4+6 CARP * * * * * * CARP defaults
  IPv4+6 TCP <sshlockout> * (self) 22 * * sshlockout
  IPv4+6 TCP <sshlockout> * (self) 443 * * sshlockout
  IPv4+6 * <virusprot> * * * * * virusprot overload table
  IPv4+6 * * * * * * * let out anything from firewall host itself
  IPv4+6 * vtnet1 * * * GW_WAN * let out anything from firewall host itself (force gw)
  IPv4 * * * * * * *

Die wg Rules sieht so aus:

Code: [Select]

          IPv4 * 10.10.10.15 * 192.168.1.5 * * * wireguard


Bfo

[Scanline]

Code: [Select]

          IPv4 * 10.10.10.15 * 192.168.1.5 * * * wireguard


Ich sehe nicht viel, aber ich sehe hier keine Regel, die den Verkehr aus dem 10.10.10.0/24 (Wireguard Netz?) Netz in das 192.168.1.0/24 (LAN?) Netz regelt.

Hast du mal unter Firewall: {wireguard interface} hinzugefügt:

Action: REJECT
Interface: {wireguard interface}
Destination: {LAN interface}

?

[mimugmail]

Flaoting Rules stehen über ALLEN .. wenn du da any any accept hast ist der Rest egal ..

[bforpc]

Moin,

Ich denke ich habe das Problem gefunden - aber nicht die Lösung.

Zugriffe aus allen Netzen auf Dienste im LAN haben immer die IP des Proxmox Hostes als Absender.
Beispiel:
Ich bin Ausserhalb per Wireguard mit dem Home Netz verbunden, habe eine WG Adresse 10.10.10.15 und greife auf einen Webserver (keine VM auf dem Proxmox Host) im Intranet zu: Der Webserver sieht dann als Absender in seinem Log die 192.168.1.1 (das ist der Proxmox Host) - die opnsense hat die 192.168.1.101.
Logischerweise greifen die FW Rules dann nicht, nur: wie kommt das denn zustande?

Vielleicht noch eine Info: Ich habe

Reflection for port forwards   
Reflection for 1:1   
Automatic outbound NAT for Reflection

aktiv, weil ich im Intranet Dienste Nutze, welche nur aus dem Internet sichtbar sind (web Zugriff auf einen öffentliche erreichbaren Webserver) und ich diesen Web Server auch aus dem Intranet brauche.

Bfo

[micneu]

leider kann ich deinen schilderungen nicht ganz Folgen, kannst du mal einen grafische3n netzwerkplan posten, das würde mir zum verständnis helfen.

[bforpc]

Netzwerkplan?  Ist total basic ;-)

Internet -> opnsense -> Intranet
Das Intranet besteht aus Clienten und VM's  mit Diensten, zb. Apache  Server und Anderen
opnsense läuft auch in einer VM auf dem Proxmox Host.

Intranet 192.168.1.x
Proxmox Host 192.168.1.1
opnsense 192.168.1.101
Wireguard Netz 10.10.10.x

Das Problem: Zugriff von * (egal ob extern, intern, vpn): der betreffende Dienst (z.B. der Apache Webserver) sieht als Absender der Anfrage immer 192.168.1.1 - was natürlich falsch ist. Da müsste die IP des Absenders stehen.

Bfo

[Roger2k]

Ich denke, dass dieses Verhalten normal ist. Das sind halt unterschiedliche Netze und die OPNsense arbeitet halt mit NAT. Ein Webserver im Internet sieht ja auch nicht die IP deines PC, sondern die WAN-IP des Routers.

[bforpc]

Moin,

@Roger2k: Wie bitte? Sorry, aber da redest du Blödsinn - das ist überhaupt nicht normal. Entweder hast du nicht alles durchgelesen oder nicht verstanden. Innerhalb des Intranets sehen alle Beteiligten immer nur einen Zugriff vom Proxmox Host - dieser hat doch nichts mit der Firewall zu tun. Sobald irgendein Paket über die Firewall läuft, wird es mit einem falschen Absender versehen, nämlich 192.168.1.1.

NOCHMAL:
PC VPN  -> (internet) -> opnsense (192.168.1.101, welche als VM auf dem Host 192.168.1.1 läuft) -> [an irgendeinen Dienst hinter der FW]   << dieser Dienst sieht als Absender 192.168.1.1. Wieso denn die .1? Er müsste streng genommen die öIP des Absenders, die VPN Tunneladresse oder wenigstens die der Firewall sehen, aber doch nicht die IP vom Host, auf welchem die VM läuft.

bfo

[micneu]

ich frage nochmal, bitte einen GRAFISCHEN NETZWERKPLAN. warscheinlich hast du noch irgend einen router oder irgendwas mit dem du ins internet kommst. schau dir auch gerne nochmal unsere tipps an.
https://forum.opnsense.org/index.php?topic=12697.0

PS: den wirst du noch öfter hier im forum brauchen, also mach dir ruhig einmal die arbeit. hilft allen

[bforpc]

Moin,
Ich weiss doch ob ich "irgendwo" noch einen Router oder whatever habe... den ich nicht habe.
Ein Netzwerkplan ändert nichts .
Es ist doch ganz einfach:
Sobald Pakete über die opnsense gehen, bekommenSie eine falsche Absenderkennung.

Bfo

[Gauss23]

Da wird am ProxMox Host etwas falsch für die OPNsense eingestellt sein.

Laut https://pve.proxmox.com/wiki/Network_Configuration#_masquerading_nat_with_tt_span_class_monospaced_iptables_span_tt

gibt es die Möglichkeit den Gast auf NAT laufen zu lassen. Ist dies zufällig der Fall?

[bforpc]

Was hat denn der Proxmox host mit dem generellen routing zu tun?
Das ist ausschliesslich eine Einstellung der Firewall. Völlig falscher Ansatz.
Ich denke, es ist eher - ich schrieb es bereits - mit dem 1:1 NAT von der FW zu tun.

bfo