Messages

 Habe jetzt mal alles auf Screenshots dokumentiert.


was mir auffält sind die deny Sachen der Firewal.

192.168.178.249:50169   185.33.223.203:443   tcp   Default deny rule

Müsste das dann nicht pass und force GW sein?

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.178.1      UGS         em0
127.0.0.1          link#3             UH          lo0
172.16.1.0/28      wg0                US          wg0
172.16.1.6         link#6             UH          wg0
192.168.178.0/24   link#1             U           em0
192.168.178.252    link#1             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::1                               link#3                        UH          lo0
fe80::%em0/64                     link#1                        U           em0
fe80::20c:29ff:fec3:7f5d%em0      link#1                        UHS         lo0
fe80::%lo0/64                     link#3                        U           lo0
fe80::1%lo0                       link#3                        UHS         lo0

  Ping ich vom Client die 172.16.1.1 an kommt der reply:

  14:47:02.754293 IP 172.16.1.6 > 172.16.1.1: ICMP echo request, id 59199, seq 21, length 40
  14:47:02.779317 IP 172.16.1.1 > 172.16.1.6: ICMP echo reply, id 59199, seq 21, length 40


  Ping ich zb 8.8.8.8 an geht er nicht in den Tunnel sondern über das normale Interface:

    14:49:50.973632 IP (tos 0x0, ttl 127, id 48911, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.178.249 > 8.8.8.8: ICMP echo request, id 1, seq 32, length 40
    14:49:50.998196 IP (tos 0x0, ttl 52, id 0, offset 0, flags [none], proto ICMP (1), length 60)
    8.8.8.8 > 192.168.178.249: ICMP echo reply, id 1, seq 32, length 40


 

Das sind die Route wenn beim wg interface disable drin ist damit er nicht die default überschreibt:

default            192.168.178.1      UGS         em0
localhost          link#3                   UH          lo0
172.16.1.6       link#6                   UH          wg0
192.168.178.0/24   link#1             U           em0
r1                         link#1             UHS         lo0


Die Regel auf der WAN (habe ja kein LAN) Schnittstelle habe ich dann so gesetzt:

IPv4 *   192.168.178.249   *   *   *   WireCloud_DHCP

Ich muss doch noch eine Route für das wg setzten oder verstehe ich das falsch?

Beim Test hatte ich :

172.16.1.0/28      wg0                US          wg0 gesetzt

und mal eine feste ip nach draußen, die gingen dann auch durch den Tunnel.

Dank Euch beiden, bin ich schon sehr nah dran und habe einen kleinen Durchbruch.

Ich habe das Gateway einstellen können und habe für die Schnittstelle wg0 einen manuelle Route gesetzt. Dem client habe ich das Gateway der Sense mitgegegeben.

im WAN habe ich die Regel gesetzt das alles vom Client kommt 192.168.178.249 zu dem wg0_Gateway geht.

Wie kann ich jetzt eine route erstellen das auch wg0 0.0.0.0/0 darf ? die Default Route ist ja 0.0.0.0/0

Momentan kann ich vom Client in das Wireguard Netz und hatte einmal eine statische Route für eine ip gesetzt. Da geht er auch durch den Tunnel.

Ich möchte ja das er alles dann durch den Tunnel gibt , was von der Client IP kommt.

@micneu habe dir eine pm geschrieben.


@mimugmail Danke dir für den Tipp, hatte ich mir auch schon durchgelesen, hat mir aber nicht das resultat gebracht. Aber mir schon mal aufgezeigt wie ich zb Leitungen für Ausfälle konfiguriere. Danke dir!

schaue mir generell auxh Videos usw zur opnsense an, damit ich einfach dazulerne.

ich werde am Ende für alle eine ordentliche Dokumentation schreiben, wenn ich es zum laufen bekomme.

 
   Hallo,

dank der Hilfe der Community konnte ich mein Wireguard Setup zum laufen bringen. Direkt danach ist es zu einer neuen Idee gekommen wie ich es am besten benutze. Ich bräuchte aber einen Denkanstoß bzw Umsetzungs Idee.

Ich möchte das nur bestimmte Clients über einen bestimmten VPN rausgehen und der Rest über das normale Internet Leitung.

Wenn ich mir die Anleitungen anschaue, soll man dieses per hinzufügen von Gateways lösen und diese dann per Rules anbinden.

Ich habe jetzt schon ein paar Sachen probiert aber es kommt einfach nicht soweit das es nur Ansatzweise klappt.

  1. Wireguard disable Routes  (damit keine neue default route erstellt wird)
  2. ich habe ein neues Gateway mit dem Namen WIREGATEWAY erstellt. Nur Namen vergeben , rest so    belassen.

 
Wie würde ich jetzt dieses Gateway einbinden bzw warum hilft mir das ,weild as Gateway doch keine Adresse  besitzt. Muss ich mir das wie ein Alias bzw ein virtuelles Interface vorstellen?

Wenn ich den haken von disable routes heruasnheme , kommt ja die 0.0.0.0/1 wg0 und 128.0.0.0/1 wg0 zu der Routing Tabelle hinzu. Also muss ich jetzt wo die Routen nicht gesetzt werden doch diese dierekt über das WAN interface anbinden?

  Ich hoffe das es halbwegs verständlich ist. Am Ende möchte ich das 3 Wireguard VPN laufen die bestimmte interne PCs durchleiten und der Rest die normale Leitung benutzt.

Danke
 

 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!

 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.

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.

@mimugmail


soll ich einfach alles noch mal vom Scratch installieren und jeweils screenshots machen? Langsam verzweifel ich wirklich.

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.

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.

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

 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.