OPNsense Forum
International Forums => German - Deutsch => Topic started by: wirehire on May 04, 2019, 03:31:56 pm
-
Hallo,
ich Danke erstmal dem Forum das mir geholfen hat am Anfang die Probleme von Wireguard bei mir zu lösen.
Ich nutze Wireguard jetzt einige Zeit mit Opnsense und bin sehr glücklich damit. Nun wollte ich mich meinem nächsten Projekt stellen und bräuchte etwas Hilfe.
VPS OPNSENSE Wireguard (läuft )
Nun wollte ich zu hause eine direkt Verbindung mit opnsense herstellen. Die OPnsense zu Hause ist hinter einer Fritzbox geschaltet und hat ein Interface LAN. Ich habe dem Lan Interface die Fritzbox als Gateway gegeben. Nach draußen kann ich alles anpingen.
Opnsense Plugin installiert:
WireguardServer
Publickey erstellt
Privatekey erstellt
Port 51820
Tunnel Adress 172.16.1.10/28
Peer: OPNSENSEVPS
Endpoint:
OPNSENSEVPS
Publickey vom wireguard Interface des VPS
Tunnel Address 0.0.0.0/0
Endpoint Address ip des VPS
Endpoint Port 51820
Auf dem Opnsense im VPS habe ich den Peer hinzugefügt:
Publickey vom Home opnsese wireguard Interface
Tunneladdress 172.16.1.6/32
Die Verbindung wird nicht aufgebaut. Ich muss bestimmt eine NAT Ausgehende Reegle machen oder? Jetzt stellt sich mir die Frage wie kann ich das Wireguard Interface per Nat Rule über das LAN Interface anbinden , da es ja keine WAN Schnittstelle benutzt?
Vielen Dank für Vorschläge und wer sich überhaupt die Zeit nimmt und den Beitrag durchliest.
Schönes Wochenende
-
Ich habe jetzt den Handshake hinbekommen durch die NAt Rule auf dem ersten Screenshot. Leider kann ich nichts anpingen. Muss ich noch per NAT den Rückkanal machen wegen LAN? Habe das auf dem 2 Screenshot ausprobiert aber keinen Erfolg damit erreicht.
-
ich mache es seit neuestem, wenn ich was teste und noch nicht final ist das ich gerne unter Floating eine
regel für ICMP anlege die erstmal auf allen schnittstellen erlaubt. so kann ich erstmal sagen ok, das geht.
danach kann man es wieder einschränken.
-
Den Ping machst du von der OPNsense daheim oder?
-
Danke micneu, das ist eine sehr gute Idee. Werde ich sofort Testen.
-
@mimugmail den Ping machen ich von der Opnsense daheim.
ich glaube das mein Routing oder mein NAt falsch sind.
zum Verständnis :
internet ----FB/wan----FBLAn
|
|
Opsense-Lan (192.168.178.253) (Gateway 192.168.178.1)
|
|
Opsense Wireguard wg0 (per NAT outbound an das LAN gebunden)
Destination Gateway Flags Netif Expire
0.0.0.0/1 wg0 US wg0
default 192.168.178.1 UGS em0
localhost link#3 UH lo0
128.0.0.0/1 wg0 US wg0
172.17.0.1 link#6 UH wg0
185.162.251.108 192.168.178.1 UGHS em0
192.168.178.0/24 link#1 U em0
OPNsense link#1 UHS lo0
Muss ich auf der FB eine Rückroute einstellen?
-
Ich verstehe deine Zeichnung nicht. Kannst du mit der Hand zeichnen mit Richtungspfeil, IPs und Internet Wolke, Foto dann hier rein
Das Howto mit central Internet breakout hast du gelesen?
-
Hallo @Migmugmail
ich habe das mal schnell aufgezeichnet.
Im endeffekt möchte ich ein vpn Gateway haben durch die opnsense im Lan. Wan macht die Fritzbox. Opnsense soll im Lan hängen eine verbindung per wireguard zu meinem wireguard server öffnen und halten. Und wenn ich dann clients den Gateway mitgebe dann direkt alles durch den Tunnel schicken, sodass nicht jeder client extra ein vpn aufmachen muss. Mit openvpn in einer anderen konstalleation hatte ich das auch hinbekommen. Aber hier glaube ich das schon broken by design von mir ist.
Im Anhang der Netzplan.
Danke für deine Hilfe.
-
Sind deine PCs hinter der OPNsense oder in 178?
-
Die Pcs sind auch im 192.168.178.0/24 Netz. Die opnsense ist ja auch nur per Lan am Router im gleichen Netz.
-
Hm, das ist nicht das beste Netzdesign, schwer von extern da den Fehler zu finden
-
Ich lerne gerne dazu.
wie würdest du spontan es aufbauen wenn du eine fritzbox als Router hast und dahinter mit opnsense einen wireguard (vpn) gateway realisieren würdest wollen?
-
So ich habe noch einmal von vorne angefangen und diesmal die opnsense als wan statt lan anschluß eingestellt und von jedem einen ordentlichen Scrennshot gemacht.
Ich denke das etwas mit dem Rückkanal nicht stimmt. In der Firewall Liveansicht sehe ich ja das die Wireguard Schnittstelle nach außen komminzieren möchte.
Anbei Netzplan, Fritzbox, WAN,NAT,Firewall Rules, Wireguard und Firewall Beispiel.
Eventuell erkennt dann jemand wo mein Fehler liegt.
-
der Rest.
-
Rest2
-
ich würde die fritzbox am wan deiner opnsense anschließen und ein exposethost (oder wie auch immer das sich nennt) auf die opnsense machen, danach dein restliches lan hinter die sense.
ich packe dir mal ein bild meines netzes rein (das ist nur ein beispiel, ich will nicht damit sagen das ist das optimum).
da wo ich das vigor165 habe musst du dir deine fb vorstellen
-
warum nimmst du hier nicht einfach ein 24er netzt
Tunnel Adress 172.16.1.10/28
Tunneladdress 172.16.1.6/32
soll das wirklich so sein?
-
ich hatte das 28 genommen weil ich nicht viele Clients habe. Soll ich das auf ein 24 Netz umstellen?
Vps OPnsense : wireguard 172.16.1.0/28 Netz
Home OPNsense : wireguard 172.17.0.0/28 Netz
Der Endpoint mit der 172.16.1.6/32 ist für die Einwahl zum VPS Wireguard und dort als PEER hinterlegt.
-
Wenn ich einen Mitschnitt auf von der FB mache, sehe ich auch das die Verbindung mit wireshark steht und der keepalive ab und an kommt. Trotzdem geht kein Ping und datenfluss.
Aber es kommt halt nur der Handshake zustanden:
allowed ips: 172.16.1.6/32
latest handshake: 1 minute, 4 seconds ago
transfer: 0 B received, 160 B sent
aber kein Datenvekehr. Mit einem anderen Client läuft die Verbindung, sodass ich den Server ausschließen kann.
-
Dann musst du auf die Console und tcpdump auf das wg interface machen, dann siehst du bestimmt was los ist.
-
ich habe mal probiert 2 ips anzupingen, 1 8.8.8.8 und 1x das wireguard interface des Servers.
20:31:52.944706 IP 172.17.0.1 > google-public-dns-a.google.com: ICMP echo request, id 12357, seq 0, length 64
20:31:52.946371 IP 172.17.0.1.61012 > l.root-servers.net.domain: 19801% [1au] A? arpa. (33)
20:31:53.977412 IP 172.17.0.1 > google-public-dns-a.google.com: ICMP echo request, id 12357, seq 1, length 64
20:31:54.996002 IP 172.17.0.1 > google-public-dns-a.google.com: ICMP echo request, id 12357, seq 2, length 64
20:31:56.069570 IP 172.17.0.1 > google-public-dns-a.google.com: ICMP echo request, id 12357, seq 3, length 64
20:31:57.096978 IP 172.17.0.1 > google-public-dns-a.google.com: ICMP echo request, id 12357, seq 4, length 64
20:35:00.199689 IP 172.17.0.1 > 172.16.1.1: ICMP echo request, id 33905, seq 3, length 64
20:35:01.235931 IP 172.17.0.1 > 172.16.1.1: ICMP echo request, id 33905, seq 4, length 64
20:35:02.285918 IP 172.17.0.1 > 172.16.1.1: ICMP echo request, id 33905, seq 5, length 64
20:35:03.336701 IP 172.17.0.1 > 172.16.1.1: ICMP echo request, id 33905, seq 6, length 64
-
@migmugmail
ich hatte dein tutorial gelesen auf der Webseite und dadurch geht es jetzt das der Tunnel Stabil ist und Datenvekehr stattfindet. Ip wird auf der HOME OPNSENSE mit der IP vom CLOUD VPS angezeigt.
Ich komme jetzt zum nächsten Problem :), wenn ich einen Client die route 0.0.0.0 über 192.168.178.253 ( home opnsense) anlege müsste doch alles durch den Tunnel gehen oder?
habe auch die IP vom Tunnel angegeben ,gleiche Problem.
Zum verständnis für mich:
mein client hat die 192.168.178.20/24 mit dem gateway 192.168.178.1 -- dadurch kann er die 192.168.178.253 erreichen.
wenn ich jetzt eine route mache:
route add 172.16.1.0 mask 255.255.255.240 192.168.178.253
und dann die route für alles auf den Tunnel gateway der opnsense lege müsste es doch richtig sein oder?
route add 0.0.0.0 mask 0.0.0.0 172.16.1.1
er soll alles was ins Internet geht über das VPn Gateway realisieren.
-
Ne, du musst auf dem Windows einfach dein Standardgateway auf die 253 legen. So routest du ja 172.16 auf die OPN und dann 0.0.0.0. auf 172.16 (was glaub ich einen Fehler werfen müsste)
-
Das dachte ich mir auch.
Muss ich in opnsense noch eine Route für das Forwarding machen?
also das der Lan Traffic immer durch den tunnel geht?
-
Wenn du dir die routen auf der OPN anschaust müssten da 2 sein ... 0.0.0.0/1 und 128.0.0.0/1
-
die /1 bedeutet das er auch die default überschreibt bzw höher ist oder?
0.0.0.0/1 wg0 US wg0
default 192.168.178.1 UGS vtnet0
localhost link#3 UH lo0
128.0.0.0/1 wg0 US wg0
172.16.1.0/28 wg0 US wg0
172.16.1.6 link#6 UH wg0
vps.host.m 192.168.178.1 UGHS vtnet0
192.168.178.0/24 link#1 U vtnet0
OPNsense link#1 UHS lo0
Ich habe auf jeden Fall die beiden drin.
-
auf dem client habe ich jetzt die 192.168.178.253 als gateway eingetragen:
0.0.0.0 0.0.0.0 192.168.178.253
In der firewall Live Ansicht sehe ich auch das der client seine Anfrage stellt
192.168.178.14 8.8.8.8 icmp let out anything from firewall host itself
aber es kommt nicht zurück bzw eventuell dann nicht in den Tunnel.
-
Ist das oben die ganze Tabelle oder gibt's ne zweite Seite?
-
Internet:
Destination Gateway Flags Netif Expire
0.0.0.0/1 wg0 US wg0
default 192.168.178.1 UGS vtnet0
localhost link#3 UH lo0
128.0.0.0/1 wg0 US wg0
172.16.1.0/28 wg0 US wg0
172.16.1.6 link#6 UH wg0
vps.host.m 192.168.178.1 UGHS vtnet0
192.168.178.0/24 link#1 U vtnet0
OPNsense link#1 UHS lo0
Internet6:
Destination Gateway Flags Netif Expire
localhost link#3 UH lo0
fe80::%vtnet0/64 link#1 U vtnet0
fe80::a00:27ff:fef link#1 UHS lo0
fe80::%lo0/64 link#3 U lo0
fe80::1%lo0 link#3 UHS lo0
-
Ich habe einfach mal aus Testzwecken ein debian Rechner benutzt für diese Idee.
1. Debian installiert
2. ip 192.168.178.253
3. Wireguard installiert
4. Verbindung hergestellt
Ping auf wireguard Interface und zb 8.8.8.8 geht
Client PC Gateway auf 192.168.178.253 eingetragen
1. Ping 192.168.178.253 geht
2. ping 8.8.8.8 geht nicht
Auf dem Debian PC
1. IP Fowarding aktiviert.
2. iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE (lan zum vpn leiten per masquerade)
Client PC
1. ping 8.8.8.8 geht
2. Webseiten gehen
3. check der Ip usw ist richtig
Und genau da liegt mein problem mit der OPNSENSE, wie bekomme ich das Forwarding und Masquerade vom LAn zum VPN hin. Der Tunnel steht ja auf der Sense, aber der ankommenden Traffic vom Lan muss ja irgendwie in den "Tunnel" geschoben werden.
-
https://docs.opnsense.org/manual/how-tos/wireguard-client-azire.html?highlight=wireguard
Step 3 ...
-
Bei mir ist ja dann das Problem das ich kein Lan habe ,sondern nur Wan (mit der internen IP )
wenn ich jetzt:
WireGuard 192.168.178.0/24 * * * Schnittstellenadresse * NEIN
als NAT OUTBOUND mache , geht es immer noch nicht.
-
@mimugmail
soll ich einfach alles noch mal vom Scratch installieren und jeweils screenshots machen? Langsam verzweifel ich wirklich.
-
Du musst doch nur ein Interface assignen, das heisst dann z.B. WG .. darauf bauend dann das NAT.
Liess mal alle Artikel in der Doku über Wireguard, dann machts bestimmt Klick :)
-
ich probiere es immer in Kontext zum Linux Server zu sehen.
WireGuard 192.168.178.0/24 * * * Schnittstellenadresse * NEIN
Die Schnittstelle wireguard (wg0) ist doch assign, un der gebe ich mit das alles was aus dem Lan Netz kommt darüber genattet wird.
okay ich lese es noch mal in Ruhe alles durch.
-
Ansonsten morgen gerne per Teamviewer
-
Ich habe noch mal die NAt Regeln ausgelesen:
nat on vtnet0 inet from 172.16.1.0/28 to any -> (vtnet0:0) port 1024:65535
nat on wireguard inet from 192.168.178.0/24 to any -> (wireguard:0) port 1024:65535 round-robin
nat on vtnet0 inet from (wg0:network) to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from 127.0.0.0/8 to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from (wg0:network) to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet from 127.0.0.0/8 to any -> (vtnet0:0) port 1024:65535
no rdr proto carp all
no rdr on wg0 proto tcp from any to (wg0) port = ssh
no rdr on wg0 proto tcp from any to (wg0) port = http
no rdr on wg0 proto tcp from any to (wg0) port = https
Bei den firewall Rules sehe ich blocks, ist da eventuell der Fehler:
block drop in log on ! vtnet0 inet from 192.168.178.0/24 to any
block drop in log inet from 192.168.1.253 to any
block drop in log on ! wg0 inet from 172.16.1.0/28 to any
block drop in log inet from 172.16.1.6 to any
block drop in log on vtnet0 inet6 from fe80::a00:27ff:feb0:a182 to any
block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
block drop in log inet6 all label "02f4bab031b57d1e30553ce08e0ec131"
Danke für dein Angebot der Hilfe. würde ich sehr gerne in Anspruch nehmen.
-
Komm mal ins IRC dann machen wir das schnell ...
-
Danke an alle , besonders mimugmail für euren Support!
Am Ende hat mimugmail heruasgefunden das es an Virtualbox lief, ich habe es jetzt mit einer anderen Virtualisierung getestet und da läuft es sofort. Am Wochenende werde ich es dann Nativ umsetzten.
Vielen Dank an die Community!