Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Kombination aus Policy-based routing und VPN-Kaskadierung

    Scheduled Pinned Locked Moved Deutsch
    7 Posts 4 Posters 551 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      juergen69
      last edited by

      Hallo zusammen,

      ich betreibe hier bei mir eine pfSense und nutze darauf eine Open-VPN-Verbindung zu einem VPN-Anbieter, die mittels policy-based routing nur für einen Client im LAN greift.

      Die Ausgangssituation für diesen Client sieht demnach wie folgt aus:

      ISP 	->	VPN-Anbieter 	-> pfSense -> Client im LAN
public IP	VPN public IP	 172.17.0.1    172.17.0.8

      Mittels diverser Foreneinträge und Youtube habe ich das obige Setup inklusive Killswitch mittels Floating-Rules (durch tagging des VPN-Traffics) am laufen, so sieht das ganze auf der pfSense aus

      dashboard.PNG
      ovpn.PNG
      status-ovpn.PNG
      lan-rules.PNG
      floating-rule.PNG

      Sobald die VPN-Verbindung PIA_SCHWEIZ down ist, hat der Client 172.17.0.8 kein Internetzugang mehr - so soll es sein!

      Jetzt kommt der Part, wo ich inzwischen wirklich am verzweifeln bin - ich möchte das Setup nun um eine weitere VPN-Verbindung (in diesem Fall PIA_LUXEMBURG) erweitern.

      Das Ganze soll es Kaskade laufen, sprich der eine VPN-Tunnel wird durch den anderen VPN-Tunnel aufgebaut. Dies soll später dazu dienen, dass man zwei verschiedene VPN-Anbieter kombinieren kann.

      Für genau diesen Einsatzzweck scheint das Multi-Hop-Package perfekt zu passen. Also hab ich es installiert und die beiden VPN-Verbindungen ausgewählt.

      multi-hop.PNG

      Es scheint auch alles zu funktionieren. Nach meinem Verständnis sollte dann jedoch, sobald die erste der beiden VPN-Verbindungen abbricht, auch die zweite abbrechen, da die beiden Tunnel kaskadiert sind. Genau das passiert
      jedoch nicht. Der Client hat weiterhin Zugang zum Internet.

      Vielleicht kann man an den Routen etwas erkennen?
      routes.PNG
      Mich würde auch interessieren, wie man hunderprozentig sichergehen kann, dass der Traffic auch wirklich über beide VPNs läuft.

      Anstatt des Multi-Hop-Package könnte man eventuell ja auch dem zweiten VPN-Client das Gateway PIA_SCHWEIZ anstatt WAN zuordnen, um die Kaskadierung zu gewährleisten?

      Womöglich hat es auch etwas mit dem policy-based routing zu tun?

      Ich weiß wirklich nicht mehr weiter und hoffe inständig, dass es jemanden gibt, der sich mit dieser Thematik auskennt und mir weiterhelfen würde.

      Vielen Dank und beste Grüße

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @juergen69
        last edited by

        @juergen69
        Hast du auch das "route-up" Kommando im Client konfiguriert?
        Die Routen lassen vermuten, dass das fehlt.

        Allerdings kenne ich das Paket auch nicht.
        Ich hätte auch einfach in den Client Einstellungen als Interface das der anderen Instanz ausgewählt und wäre davon ausgegangen, dass so diese erst eine Verbindung haben muss, bevor der Client eine Verbindung aufbaut.

        J JeGrJ 2 Replies Last reply Reply Quote 0
        • J
          juergen69 @viragomann
          last edited by

          @viragoman
          Vielen Dank für deine Antwort. Mit diesem Kommando konnte ich nichts anfangen. Ich dachte, dass dort nur der technische Hintergrund erläutert wird und das Paket dies automatisch erledigt.

          Ich bin für weitere Anregungen gerne offen.

          micneuM 1 Reply Last reply Reply Quote 0
          • micneuM
            micneu @juergen69
            last edited by

            @juergen69 ich verstehe dein vorhaben nur bedingt, warum willst du eine vpn verbindung durch eine andere aufbauen, was genau bezweckst du damit.

            Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser |
            Hardware: Netgate 6100
            ALT Intel NUC BNUC11TNHV50L00 (32GB Ram, 512GB M.2 NVME SSD)

            J 1 Reply Last reply Reply Quote 0
            • J
              juergen69 @micneu
              last edited by juergen69

              @micneu
              Ich möchte die Möglichkeit nutzen, zwei verschiedene VPN-Provider zu kombinieren. Sollte ein Anbieter entgegen seiner Werbeversprechen doch Daten loggen und ggf. sogar herausgeben, hat man eine Art Sicherheitsnetz durch den weiteren Provider.

              Ich habe nochmal ein bisschen herum experimentiert und folgende Lösung getestet

              Das Multi-Hop-Package wurde deaktiviert.
              Als Interface bei PIA_SCHWEIZ habe ich nun statt WAN das Interface PIA_LUXEMBURG gewählt. Weitere Änderungen habe ich nicht vorgenommen. Aus meiner Sicht sollte der VPN-Tunnel in die Schweiz somit immer über den VPN-Tunnel nach Luxemburg aufgebaut werden, richtig?

              Der Ping für PIA_SCHWEIZ ist jedenfalls gestiegen, was ja wohl dafür spricht, dass die Kaskadierung funktioniert.

              Zusätzlich habe ich beide VPN-Clients im Service Watchdog hinzugefügt, um die Verbindungen nach der nächtlichen Zwangstrennung wieder aufzubauen. Mal sehen, ob auch das funktioniert, da ja PIA_SCHWEIZ nicht verbunden wird, bevor PIA_LUXEMBURG online ist.

              Im Detail sieht das Ganze jetzt so aus
              ovpn.PNG
              status-ovpn.PNG
              watchdog.PNG

              Aus der Ansicht der Routes werde ich nicht wirklich schlau.
              routes.PNG

              Was meint ihr zu dieser Lösung?

              1 Reply Last reply Reply Quote 0
              • JeGrJ
                JeGr LAYER 8 Moderator @viragomann
                last edited by

                @viragomann said in Kombination aus Policy-based routing und VPN-Kaskadierung:

                Allerdings kenne ich das Paket auch nicht.

                Das Paket ist auch kein offizielles Paket und wurde laut eigenem Readme NUR mit Perfect Privacy getestet und konzipiert. Es kann also schlichtweg sein, dass es nicht so wie gewünscht mit PIA funktioniert oder es eben diverse Seitenprobleme damit gibt. Das kann man schlecht wissen.

                Ansonsten verstehe ich den Sinn der "Lösung" nur bedingt. Gerade wenn es genau EIN Rechner ist, der mit dem ganzen Zirkus bespielt wird, ist es IMHO den ganzen Aufriss nicht wert nur um nicht nen VPN Client auf dem Rechner zu haben. Und verschiedene Provider zu mixen ist ein frommer Wunsch, der so oder so nur begrenzte Erfolgswahrscheinlichkeit hat. Der Grund warum das nur mit PP getestet wurde ist, dass PP das Feature AFAIK anbietet und auch entsprechend konfigurierbar hat. Zwei VPN Anbieter die das NICHT haben scheren sich schlichtweg nicht um MultiHopping und nutzen ggf. die gleichen Transfernetze oder überlappende interne Netzbereiche, so dass man die ganze Spielwiese eh nicht einsetzen kann weil die Routen kollidieren. Ist zwar eine nette theoretische Idee, aber praktisch mit zu vielen Problemen direkt vom Start weg behaftet als das das für mich in irgendeiner Form sinnvoll nutzbar wäre.

                Aber das ist nur mein persönlicher Ausblick darauf. Ich bin eben alt (in Internetzeit) ;)

                Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 1
                • J
                  juergen69
                  last edited by juergen69

                  Ich habe auf dem Client zum Test mal eine etwas größere Datei heruntergeladen und siehe da: Der Traffic erhöht sich in der Folge tatsächlich bei beiden VPN-Verbindungen. Somit scheinen beide Tunnel wohl kaskadiert zu laufen.

                  Mein aktuelles Setup funktioniert allerdings anscheinend nur solange, bis es zur nächtlichen Zwangstrennung kommt. Anschließend werden beide VPN-Tunnel zwar wieder verbunden, aber der Client hat trotzdem keinen Internetzugang.

                  Erst wenn ich beim VPN-Client PIA_SCHWEIZ das Interface einmal manuell von PIA_LUXEMBURG auf WAN und wieder zurück auf PIA_LUXEMBURG stelle, hat der Client im LAN wieder Zugang zum Internet.

                  Hat jemand eine Idee woran dies liegen könnte?

                  In den Logs der pfSense zu Open-VPN sieht es folgendermaßen aus:

                  Feb 10 03:30:01	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:01	openvpn	736	write UDPv4: No route to host (code=65)
Feb 10 03:30:01	openvpn	736	write UDPv4: No route to host (code=65)
Feb 10 03:30:01	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:02	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:02	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:03	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:03	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:04	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:04	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:05	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:05	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:05	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:05	openvpn	736	write UDPv4: No route to host (code=65)
Feb 10 03:30:06	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:06	openvpn	736	write UDPv4: No route to host (code=65)
Feb 10 03:30:06	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:06	openvpn	736	write UDPv4: No route to host (code=65)
Feb 10 03:30:07	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:07	openvpn	736	write UDPv4: No route to host (code=65)
Feb 10 03:30:07	openvpn	52072	write UDPv4: No route to host (code=65)
Feb 10 03:30:07	openvpn	736	write UDPv4: No route to host (code=65)
Feb 10 03:30:18	openvpn	736	event_wait : Interrupted system call (code=4)
Feb 10 03:30:18	openvpn	736	SIGTERM received, sending exit notification to peer
Feb 10 03:30:19	openvpn	736	/usr/local/sbin/ovpn-linkdown ovpnc2 1500 1552 10.2.112.73 255.255.255.0 init
Feb 10 03:30:19	openvpn	736	SIGTERM[soft,exit-with-notification] received, process exiting
Feb 10 03:30:19	openvpn	74448	WARNING: file '/var/etc/openvpn/client2/up' is group or others accessible
Feb 10 03:30:19	openvpn	74448	OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Nov 15 2021
Feb 10 03:30:19	openvpn	74448	library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10
Feb 10 03:30:19	openvpn	75337	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 10 03:30:19	openvpn	75337	WARNING: experimental option --capath /var/etc/openvpn/client2/ca
Feb 10 03:30:19	openvpn	75337	TCP/UDP: Preserving recently used remote address: [AF_INET]5.253.204.107:1198
Feb 10 03:30:19	openvpn	75337	UDPv4 link local (bound): [AF_INET]217.xxx.xxx.xxx:0
Feb 10 03:30:19	openvpn	75337	UDPv4 link remote: [AF_INET]5.253.204.107:1198
Feb 10 03:30:19	openvpn	75337	WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1542'
Feb 10 03:30:19	openvpn	75337	WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'
Feb 10 03:30:19	openvpn	75337	WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Feb 10 03:30:19	openvpn	75337	WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Feb 10 03:30:19	openvpn	75337	[luxembourg404] Peer Connection Initiated with [AF_INET]5.253.204.107:1198
Feb 10 03:30:19	openvpn	75337	Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Feb 10 03:30:19	openvpn	75337	Options error: option 'route-ipv6' cannot be used in this context ([PUSH-OPTIONS])
Feb 10 03:30:19	openvpn	75337	Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Feb 10 03:30:19	openvpn	75337	TUN/TAP device ovpnc2 exists previously, keep at program end
Feb 10 03:30:19	openvpn	75337	TUN/TAP device /dev/tun2 opened
Feb 10 03:30:19	openvpn	75337	/sbin/ifconfig ovpnc2 10.9.112.52 10.9.112.1 mtu 1500 netmask 255.255.255.0 up
Feb 10 03:30:19	openvpn	75337	/usr/local/sbin/ovpn-linkup ovpnc2 1500 1552 10.9.112.52 255.255.255.0 init
Feb 10 03:30:19	openvpn	75337	WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Feb 10 03:30:19	openvpn	75337	Initialization Sequence Completed
Feb 10 03:31:00	openvpn	52072	[zurich402] Inactivity timeout (--ping-restart), restarting
Feb 10 03:31:00	openvpn	52072	SIGUSR1[soft,ping-restart] received, process restarting
Feb 10 03:31:05	openvpn	52072	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 10 03:31:05	openvpn	52072	TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.37.200:1198
Feb 10 03:31:05	openvpn	52072	TCP/UDP: Socket bind failed on local address [AF_INET]10.2.112.73:0: Can't assign requested address (errno=49)
Feb 10 03:31:05	openvpn	52072	Exiting due to fatal error
Feb 10 03:31:05	openvpn	52072	/usr/local/sbin/ovpn-linkdown ovpnc1 1500 1622 10.23.112.116 255.255.255.0 init
Feb 10 03:32:00	openvpn	76840	WARNING: file '/var/etc/openvpn/client1/up' is group or others accessible
Feb 10 03:32:00	openvpn	76840	OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Nov 15 2021
Feb 10 03:32:00	openvpn	76840	library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10
Feb 10 03:32:00	openvpn	77162	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 10 03:32:00	openvpn	77162	WARNING: experimental option --capath /var/etc/openvpn/client1/ca
Feb 10 03:32:00	openvpn	77162	TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.37.60:1198
Feb 10 03:32:00	openvpn	77162	UDPv4 link local (bound): [AF_INET]10.9.112.52:0
Feb 10 03:32:00	openvpn	77162	UDPv4 link remote: [AF_INET]212.102.37.60:1198
Feb 10 03:32:00	openvpn	77162	WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1542'
Feb 10 03:32:00	openvpn	77162	WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'
Feb 10 03:32:00	openvpn	77162	WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Feb 10 03:32:00	openvpn	77162	WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Feb 10 03:32:00	openvpn	77162	[zurich404] Peer Connection Initiated with [AF_INET]212.102.37.60:1198
Feb 10 03:32:00	openvpn	77162	Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Feb 10 03:32:00	openvpn	77162	Options error: option 'route-ipv6' cannot be used in this context ([PUSH-OPTIONS])
Feb 10 03:32:00	openvpn	77162	Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Feb 10 03:32:00	openvpn	77162	TUN/TAP device ovpnc1 exists previously, keep at program end
Feb 10 03:32:00	openvpn	77162	TUN/TAP device /dev/tun1 opened
Feb 10 03:32:00	openvpn	77162	/sbin/ifconfig ovpnc1 10.17.112.127 10.17.112.1 mtu 1500 netmask 255.255.255.0 up
Feb 10 03:32:00	openvpn	77162	/usr/local/sbin/ovpn-linkup ovpnc1 1500 1552 10.17.112.127 255.255.255.0 init
Feb 10 03:32:00	openvpn	77162	WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Feb 10 03:32:00	openvpn	77162	Initialization Sequence Completed
                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.