Public IPv4/IPv6 via VPN Tunnel

JeGr

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

@jegr

Kannst du mal beizeiten die konfig beider Seiten zeigen ohne Zertifikate?
Den VPS als OVPN Server und die Sense als Client, da prasseln laufend Standardfehlermeldungen in die Syslog.

Anders herum ist der Verbindungsaufbau soweit in Ordnung.

Läuft nicht mit Zertifikaten momentan, reines Shared Key Setup, dafür kein GCM, ja. War faul.

@bob-dig said in Public IPv4/IPv6 via VPN Tunnel:

@jegr Meintest Du nicht seinerzeit, dass es dafür zwei /64er bedarf oder bringe ich da was durcheinander?

Hab ich oben auch beschrieben: Entweder man kann per NPt einzelne IP6 durchreichen oder man bräuchte ggf. geroutet ein zweites IPv6 Prefix und kanns dann weiterrouten.

Bob.Dig

@jegr Got it! Aber wer will einen (zweiten) VPS anmieten, nur um eine weitere pfSense laufen zu lassen, das bleibt halt die Crux für Sparfüchse.

mike69

@bob-dig

Eine pfsense Instanz ist auf dem VPS echt nicht nötig. Wenn OpenVPN schon looft auf der Sense, den clienten exportieren und die ovpn datei auf den VPS kopieren. Mit "openvpn /pfad/zur/conf_datei" als Client starten, fettisch, quick ’n dirty :)

Mit den Iptables und den routes, das kriegen wir schon hin. :)

JeGr

@bob-dig said in Public IPv4/IPv6 via VPN Tunnel:

@jegr Got it! Aber wer will einen (zweiten) VPS anmieten, nur um eine weitere pfSense laufen zu lassen, das bleibt halt die Crux für Sparfüchse.

Warum ne zweite? Ich hab ne zweite Laufen weil ich eh nen externen Server habe. Aber wer das alles bei sich zu Hause laufen lassen will und nur ne externe IP4/IP6 sucht, die statisch ist, find ich das keinen Overhead. Wenn ich eh "nur" VPN laufen lassen will - ist es mir doch egal was auf der Tüte läuft. Ob das "nötig" ist oder nicht, ist doch dann sekundär. Es lüppt was lüppt. Und was für mich einfacher und weniger Streß erzeugt ist mir garantiert mehr wert als Rumbasteln in einer Linux VPS Instanz um rumsuchen, was für IP Forwarding Optionen, Sysctl Calls und Firewall Settings ich da brauche wenn ich in ner halben Stunde die Sense Installation durchgetippt hab

mike69

@jegr said in Public IPv4/IPv6 via VPN Tunnel:

@jegr
Kannst du mal beizeiten die konfig beider Seiten zeigen ohne Zertifikate?
Den VPS als OVPN Server und die Sense als Client, da prasseln laufend Standardfehlermeldungen in die Syslog.
Anders herum ist der Verbindungsaufbau soweit in Ordnung.

Läuft nicht mit Zertifikaten momentan, reines Shared Key Setup, dafür kein GCM, ja. War faul.

Oke.

VPN Server: VPS, client: Sense, folgende Fehlermeldung im Sekundentakt:

Jan 20 09:37:41 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:41 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:44 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:45 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:45 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:47 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:47 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:48 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:48 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen
Jan 20 09:37:48 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen

Tante Google spuckt Unterschiede bei der Komprimierungeinstellung zwischen Server und Client raus. Egal was in der Konfig steht, laufend diese Fehlermeldung. Deswegen die Frage nach deiner *.conf für Server und Client.

Hast ja auf beide Seiten pfSense laufen, die Meldungen wirst Du nicht haben, oder?

edit:

Server/Client Konfig ist Blödsinn, Peer to Peer ist der richtige Weg oder? :)

Pippin

Vielleicht hilft dir das;
https://www.toofishes.net/blog/openvpn-and-aoe-interaction/

JeGr

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Server/Client Konfig ist Blödsinn, Peer to Peer ist der richtige Weg oder? :)

Poste doch mal deine Konfigs auf beiden Seiten. Ich such gern meine raus, aber für nen Tunnel bei dem Geschwindigkeit jetzt nicht der primäre Aspekt ist (wegen CBC vs GCM was bei SharedKey nicht geht), ist Shared Key eben so viel einfacher.

Lasse gerade den VPS nochmal updaten.

mike69

@jegr said in Public IPv4/IPv6 via VPN Tunnel:

Poste doch mal deine Konfigs auf beiden Seiten.

Hier sie Sense als Server:

dev ovpns2
verb 1
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-128-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 87.168.50.208
ifconfig 10.1.2.1 10.1.2.2
lport 1195
management /var/etc/openvpn/server2.sock unix
secret /var/etc/openvpn/server2.secret 
compress

Der VPS als Client, quasi der Shared Key Export:

dev tun
persist-tun
persist-key
cipher AES-128-CBC
auth SHA256
#pull
resolv-retry infinite
proto udp
remote home.example.com 1195 udp4
ifconfig 10.1.2.2 10.1.2.1
keepalive 10 60
ping-timer-rem
compress

<secret>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
x
x
-----END OpenVPN Static key V1-----
</secret>

Verbindung wird aufgebaut. ein Teil von "ip a"

8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.1.2.2 peer 10.1.2.1/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::49ea:1dc6:176:6f28/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

mike69

@pippin

Danke für den Link. Leider nicht. :)

JeGr

@mike69 Ich würde mal beide Seiten auf "verb 3" setzen und schauen was das Log spricht beim Verbindungsaufbau :)

mike69

@jegr said in Public IPv4/IPv6 via VPN Tunnel:

@mike69 Ich würde mal beide Seiten auf "verb 3" setzen und schauen was das Log spricht beim Verbindungsaufbau :)

Kann ich gerne uppen, dies ist aber die Konfig die looft. :)
Anders herum, VPS als OVPN Server und pfSense als Client, da hakt es ungemein.

Wenn ich es schaffe, werde ich das morgen Abend umbauen und die Konfigs, bzw. Logs rein stellen.

JeGr

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Wenn ich es schaffe, werde ich das morgen Abend umbauen und die Konfigs, bzw. Logs rein stellen.

Okay, oder je nach Teilnahme morgen beim Usergroup Meet können wirs ggf. auch einfach mal durchspielen.

mike69

@jegr said in Public IPv4/IPv6 via VPN Tunnel:

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Wenn ich es schaffe, werde ich das morgen Abend umbauen und die Konfigs, bzw. Logs rein stellen.

Okay, oder je nach Teilnahme morgen beim Usergroup Meet können wirs ggf. auch einfach mal durchspielen.

Ja, hört sich gut an.

Anderes Scenario, VPS als OVPN Server, pfSense als Client looft jetzt. Habe die konfiguration neu erstellt und die Cipher von AES-256-GCM auf AES-256-CBC geändert.

Server Config:

local 212.227.xxx.yyy
port 1195
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
server-ipv6 fddd:1194:1194:1194::/64
push "redirect-gateway def1 ipv6 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 5
crl-verify crl.pem
explicit-exit-notify
compress

.
pfsense als Client:

dev ovpnc4
verb 3
dev-type tun
dev-node /dev/tun4
writepid /var/run/openvpn_client4.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA512
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 87.168.xxx.yyy
tls-client
client
lport 0
management /var/etc/openvpn/client4.sock unix
remote 212.227.xxx.yyy 1195 udp4
ca /var/etc/openvpn/client4.ca 
cert /var/etc/openvpn/client4.cert 
key /var/etc/openvpn/client4.key 
tls-crypt /var/etc/openvpn/client4.tls-crypt 
ncp-disable
compress 
resolv-retry infinite

Logs zu dieser Verbindung kann bei Bedarf nachgereicht werden.

JeGr

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Anderes Scenario, VPS als OVPN Server, pfSense als Client looft jetzt. Habe die konfiguration neu erstellt und die Cipher von AES-256-GCM auf AES-256-CBC geändert.

Und das ist alles gewesen? Seltsam. Da du CA-based machst, müsste GCM problemlos laufen. Naja vielleicht ham wir heut Abend ja ne ruhige Kugel und können das mal testweise nachbauen :)

mike69

@jegr

Jetzt, wo Du es erwähnst. :)
Funzt auch mit AES-256-GCM, wer weiss, wo es damals geklemmt hat.

Ok, Tunnel steht, jetzt den v4 Traffic durchleiten... :)

Bei den ganzen HowTos der VPN Anbieter wird einen VPN Interface erstellt, wird das hier auch benötigt? Gehe mal von einem "Ja" aus, brauchtst ja ein Gateway, oder?
Werde auf alle Fälle ein Testnetz erstellen, welches komplett durch das VPN geleitet werden soll.
Boah, das ganze Routingkram ist für mich Hexenwerk. :) Da sitze ich wie ein Schwein vorm Uhrwerk.

JeGr

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Bei den ganzen HowTos der VPN Anbieter wird einen VPN Interface erstellt, wird das hier auch benötigt? Gehe mal von einem "Ja" aus, brauchtst ja ein Gateway, oder?

Jap genau deshalb :) Und weil @viragomann es eigentlich schön zusammengefasst hat "man brauchts eigentlich nicht immer, es schadet aber nicht, darum mach ich es einfach jedes Mal". :) Denn dann muss man in der laufenden Konfig nicht mehr rumschrauben und Tunnel neu starten etc. (Nach der Zuweisung des ovpnX IFs muss man den Tunnel neu starten, damit das IF sauber läuft).

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Boah, das ganze Routingkram ist für mich Hexenwerk. :) Da sitze ich wie ein Schwein vorm Uhrwerk.

Ganz ehrlich? So sitz ich grad vor dem WireGuard Kram. Super einfach und so... Mhmm...

viragomann

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Bei den ganzen HowTos der VPN Anbieter wird einen VPN Interface erstellt, wird das hier auch benötigt? Gehe mal von einem "Ja" aus, brauchtst ja ein Gateway, oder?
Werde auf alle Fälle ein Testnetz erstellen, welches komplett durch das VPN geleitet werden soll.

Das heißt, du musst mit Policy Routing Regeln arbeiten. Ja, in diesem Fall ist das Interface Voraussetzung, ansonsten hättest du kein Gateway zum Routen.

Eine Falle, in die viele bei erstmaligem Einrichten hineintappen, ist dabei, dass die Leute einfach eine Regel ganz oben am Interface setzen, die allen Trafft auf das VPN -Gateway routet. Damit haben die Geräte allerdings keinen Zugriff mehr auf interne Resourcen, auch nicht auf die pfSnese selbst, falls diese bspw. zur DNS-Auflösung verwendet wird. Das hat dann zur Folge, dass gar nichts mehr geht, intern wie extern.

mike69

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Jo, soweit im Schädel angekommen. :)
Reicht aber aus, dem Testsubnet nur das VPN Gateway einzustellen? Oder brauch ich noch ne Rule unter"NAT/Outbound"?

Was jetzt schon zu tätigen ist, die WAN Gateways in den Rules einzutragen, damit nicht alles über VPN läuft. Kann man das anders lösen irgendwie?

viragomann

@mike69
Die Outbound NAT Regel am OpenVPN Interface wird immer benötigt, wenn da ein Traffic ins Internet soll. Dann ist es ja quasi ein WAN-Gateway. Ohne NAT kämen die Pakete nicht zurück.

Es sollte reichen, den Traffic fürs VPN zu routen, WAN sollte das Default Gateway bleiben, dann musst du es nicht in den Regeln angeben.
Damit das so ist, muss im Client "Don't pull routes" angehakt sein, denn die Provider pushen üb(lich)erweise die Default-Route.

Solltes du das WAN-GW in den Regel angeben, gilt wieder oben gesagtes: Die Regel erlaubt dann nur noch Traffic über das WAN-GW und damit keinen internen.

mike69

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Solltes du das WAN-GW in den Regel angeben, gilt wieder oben gesagtes: Die Regel erlaubt dann nur noch Traffic über das WAN-GW und damit keinen internen.

Ja, stimmt.

Der "Provider" ist eigentlich ein gemieteter VPS, OVPN ist somit komplett konfigurierbar.

Oke, "Don't pull routes" gesetzt, das Testsubnet den VPN Gateway vorgesetzt und die Rule unter Outbound erstellt so wie hier:

Soweit in Ordnung?