Peer2Peer Shared Key vs SSL/TLS mit CARP und Multiwan
-
Hi,
ich habe die Tage die Meldung gesehen, dass mit OpenVPN 2.6 net2net Shared Key sehr wahrscheinlich nicht mehr funktioniert.
Um nicht unvorbereitet in irgendwelche Untiefen zu geraten, habe ich meiner Testumgebung einen Carp Culster mit MultiWan installiert und erst mal die VPN Tunnels wie gewohnt als Peer2Peer Shared Key angelegt.Der Test Cluster und meine Pfsense zu Hause sind auf Version 2.6CE und sind auf Esxi7 virtualisiert.
Soweit ich bisher getestet habe funktioniert meine Konfiguration, zumindest was Gateway Failover/Failback und CARP Failover/Failback angeht.Alle Interfaces im Cluster haben zum testen „any to any“ Regeln und die OpenVPN Tunnel sind nicht als Interface eingerichtet.
Meine PfSense zu Hause hat ein WAN Interface und ist mit 2x net2net Shared Key Clients auf die beiden WAN Interface des CARP Clusters verbunden.
Ich kann mich per RDP auf einen Test Server hinter dem Clsuter verbinden und wenn ich den Master runter fahre dauert es ca. 30-60 Sekunden bis die RDP Verbindung wieder steht, der ISP Wechsel geht schneller.
Mit identischer Konfiguration nur eben meine beiden Tunnel auf SSL/TLS umgestellt, kann ich keine Verbindung mit dem Server hinter dem Cluster aufbauen.
Die Tunnel vebinden, Client und Server zeigen grün für die Verbindung, ich sehe den Cluster in meinem OSPF Status, die Routen sehen gut aus, zumindest soweit ich das beurteilen kann, ich meine es funktioniert ja auch mit Shared Key Konfiguration.
Ich habe es mit subnet und net30 Topologie probiert, Don't pull routes und Don't add/remove routes an und aus gemacht, es geht einfach nicht und ich habe keinen Plan warum.
Tunnel Konfiguration ist im Moment
VPN01 = 10.50.57.0/30, Port 5057, Metric 10
VPN02 = 10.50.56.0/30, Port 5056, Metric 20
Topology net30Der Cluster hat Area 0.0.0.0, auf meiner PfSense sind die VPN Tunnel Area 0.0.0.0 zugewisen und meine LAN interface Area 0.0.0.2
Hier meine IPv4 Routen
OSPF Status
OSPF Routing Process, Router ID: 10.14.0.48
Supports only single TOS (TOS0) routes
This implementation conforms to RFC2328
RFC1583Compatibility flag is disabled
OpaqueCapability flag is disabled
Initial SPF scheduling delay 0 millisec(s)
Minimum hold time between consecutive SPFs 50 millisec(s)
Maximum hold time between consecutive SPFs 5000 millisec(s)
Hold time multiplier is currently 1
SPF algorithm last executed 2h20m10s ago
Last SPF duration 71 usecs
SPF timer is inactive
LSA minimum interval 5000 msecs
LSA minimum arrival 1000 msecs
Write Multiplier set to 20
Refresh timer 10 secs
This router is an ABR, ABR type is: Alternative Cisco
This router is an ASBR (injecting external routing information)
Number of external LSA 26. Checksum Sum 0x000c2655
Number of opaque AS LSA 0. Checksum Sum 0x00000000
Number of areas attached to this router: 2
All adjacency changes are logged
Area ID: 0.0.0.0 (Backbone)
Number of interfaces in this area: Total: 2, Active: 2
Number of fully adjacent neighbors in this area: 2
Area has no authentication
SPF algorithm executed 45 times
Number of LSA 6
Number of router LSA 3. Checksum Sum 0x0001bed2
Number of network LSA 0. Checksum Sum 0x00000000
Number of summary LSA 3. Checksum Sum 0x00014c6f
Number of ASBR summary LSA 0. Checksum Sum 0x00000000
Number of NSSA LSA 0. Checksum Sum 0x00000000
Number of opaque link LSA 0. Checksum Sum 0x00000000
Number of opaque area LSA 0. Checksum Sum 0x00000000Area ID: 0.0.0.2
Shortcutting mode: Default, S-bit consensus: ok
Number of interfaces in this area: Total: 2, Active: 2
Number of fully adjacent neighbors in this area: 0
Area has no authentication
Number of full virtual adjacencies going through this area: 0
SPF algorithm executed 3 times
Number of LSA 10
Number of router LSA 1. Checksum Sum 0x00008461
Number of network LSA 0. Checksum Sum 0x00000000
Number of summary LSA 7. Checksum Sum 0x00038bf7
Number of ASBR summary LSA 2. Checksum Sum 0x0000db94
Number of NSSA LSA 0. Checksum Sum 0x00000000
Number of opaque link LSA 0. Checksum Sum 0x00000000
Number of opaque area LSA 0. Checksum Sum 0x00000000Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
10.14.0.50 1 Full/DROther 34.767s 10.50.56.1 ovpnc4:10.50.56.2 0 0 0
10.14.0.50 1 Full/DROther 30.464s 10.50.57.1 ovpnc3:10.50.57.2 0 0 0============ OSPF network routing table ============
N 10.0.0.0/24 [20] area: 0.0.0.0
via 10.50.57.1, ovpnc3
N 10.0.40.0/24 [20] area: 0.0.0.0
via 10.50.57.1, ovpnc3
N 10.0.50.0/24 [20] area: 0.0.0.0
via 10.50.57.1, ovpnc3
N 10.0.60.0/24 [20] area: 0.0.0.0
via 10.50.57.1, ovpnc3
N 10.0.70.0/24 [20] area: 0.0.0.0
via 10.50.57.1, ovpnc3
N 172.20.20.0/24 [10] area: 0.0.0.2
directly attached to vmx3
N 172.22.22.0/24 [10] area: 0.0.0.2
directly attached to vmx5
N IA 192.168.50.0/24 [30] area: 0.0.0.0
via 10.50.57.1, ovpnc3
N 192.168.70.0/24 [20] area: 0.0.0.0
via 10.50.57.1, ovpnc3============ OSPF router routing table =============
R 10.14.0.47 [20] area: 0.0.0.0, ABR, ASBR
via 10.50.57.1, ovpnc3
R 10.14.0.50 [10] area: 0.0.0.0, ASBR
via 10.50.57.1, ovpnc3============ OSPF external routing table ===========
N E2 10.0.214.0/24 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.0.226.0/24 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.0.245.2/32 [20/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.0.246.2/32 [20/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.10.10.1/32 [20/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.10.90.0/30 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.50.1/32 [20/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.50.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.51.1/32 [20/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.51.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.52.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.53.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.54.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.55.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.56.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 10.50.57.2/32 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 109.xx.xx.176/28 [10/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 192.168.0.0/24 [20/20] tag: 0
via 10.50.57.1, ovpnc3
N E2 192.168.100.0/24 [10/20] tag: 0
via 10.50.57.1, ovpnc3Der Editor ist ja mal recht brauchbar, was ist das für eine Forum Software?
VG
-
OpenVPN CSO gesetzt?
-Rico
-
Hi,
nein, ich war der Meinung mit OSPF fällt das weg, was verstehe ich da jetzt nicht?
Muss ich da jetzt die ganzen Netze defienieren die mit dem jeweiligen Client benutzt werden können?
Ich meine für was mache ich dann OSFP und leg die Regeln im OpenVPN Tap an?VG
-
Ich habe weder von OSPF noch von SSL/TLS Setups Ahnung, aber wenn ich mir die Doku dazu ansehe, scheint mir das doch eher optional zu sein...?
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-overrides.html
Purpose
Depending on the use cases, overrides may be a required part of a deployment, such as a site-to-site VPN with multiple clients connecting to a single server.
This is functionally identical to the same fields on the OpenVPN server configuration. There is no need to duplicate those values here. Only exceptions or differences from the default entries should be in these fields.
Und da ich ja mit OSPF weder local nocht remote Netzte im Server eingebe, war ich der Meinung das CSO damit auch weg fällt.
Ich habe es auch gerade getestet, es geht auch mit CSO nicht
-
@janos66 said in Peer2Peer Shared Key vs SSL/TLS mit CARP und Multiwan:
Ich habe weder von OSPF noch von SSL/TLS Setups Ahnung, aber wenn ich mir die Doku dazu ansehe, scheint mir das doch eher optional zu sein...?
Kurze Frage: wenn du doch eh schon das Problem per se angehen möchtest mit VPN und mit TLS schon nicht so sehr bewandert bist, warum dann dir noch den zusätzlichen Zementschuh anziehen und dann noch mit einem highlevel routing protokoll basteln, wenn du damit noch nie in Kontakt gekommen bist? OSPF hat nochmal ganz eigene Kanten und Ecken und Unartigkeiten, so dass ich persönlich das jetzt im Moment erstmal ganz rauslassen würde, bevor ich mir da mehrfache Fußangeln einbaue und über alle gleichzeitig falle. Ich würde empfehlen erst einmal die Tunnel sauber mit TLS+CSO hin zu bekommen mit ganz normalem Routing statt schon OSPF, Multicast, Dijkstra Algorithmen und den ganzen Kram mit reinzuwerfen die alle Terz machen können :)
Und im Normalfall sind die CSOs nicht optional. Grund: VPN Server mit TLS können theoretisch mehrere Clients terminieren und nicht nur einen. Ist im Server jetzt ein oder mehrere "Remote Network"s hinterlegt, weiß der Server zwar, dass er Pakete dahin annehmen soll aber nicht wohin er sie schicken soll da theoretisch jeder eingewählte Client das sein könnte. Daher also CSO via TLS CN Zuweisung, dort dann als remote network das IP Netz ran und dann weiß der Server: "OK ich muss es annehmen (Server config) und ich muss es an Client XY rausgeben (CSO)".
Ich hoffe das bringt dich im Setup ein Stück weiter :)
Cheers
-
Die OSFP Konfig funktioniert mit Shared Key Tunnel, ich habe jetzt vier Clients mit je zwei Tunnel verbunden und keine Probleme damit.
SSL/TLS hat noch Zeit, ich habe jetzt erstmal wieder andere Baustellen
