Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Kompletten Traffic über Site-to-Site VPN routen

Hallo zusammen,

ich habe folgendes vor:

Ich möchte mit einer Sophos UTM 9.204-20 eine Site-to-Site VPN Connection zu einem VPN-Provider (in meinem Fall Hide.me) aufbauen und im Anschluss daran alle Verbindungen ins Internet darüber routen, sodass von meiner Sophos aus lediglich die "anonyme" VPN-Verbindung ins Internet besteht.

Als Bons wäre eine Art Failover mit einer zweiten Site-to-Site VPN Verbindung wünschenswert, sodass bei Verbindungsabbruch zum einen Tunnel, der Traffic über den nächsten geroutet wird. Das wäre allerdings nur optional.

Nun zum Aufbau: 

Den Site-to-Site Tunnel habe ich via IPsec zustande bekommen, dieser kann auch mit folgenden Einstellungen erfolgreich aufgebaut werden:


Einstellungen Remote Gateway:




Einstellungen IPsec Connection:




Wenn die Verbindung aktiv ist, ist momentan kein Zugriff aufs Internet möglich. 

Welche Einstellungen muss ich ändern bzw. evtl. an anderer Stelle vornehmen?


This thread was automatically locked due to age.
  • 'Local networks' in der 'IPsec Connection' sollte nicht "External (WAN) (Network)" enthalten, sondern 'Internal (Network)'.

    MfG - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 'Local networks' in der 'IPsec Connection' sollte nicht "External (WAN) (Network)" enthalten, sondern 'Internal (Network)'.

    MfG - Bob


    Das hatte ich bereits versucht, allerdings kann dann der IPsec Tunnel nicht aufgebaut werden.

    Folgendes steht dazu im Log:

    2014:07:27-10:30:00 jphs pluto[16069]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2014:07:27-10:30:00 jphs pluto[16069]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2014:07:27-10:30:00 jphs pluto[16069]: Changing to directory '/etc/ipsec.d/crls'
    2014:07:27-10:30:00 jphs pluto[16069]: added connection description "S_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:00 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: initiating Main Mode
    2014:07:27-10:30:00 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:00 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: received Vendor ID payload [strongSwan]
    2014:07:27-10:30:00 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: received Vendor ID payload [XAUTH]
    2014:07:27-10:30:00 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: received Vendor ID payload [Dead Peer Detection]
    2014:07:27-10:30:00 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: received Vendor ID payload [RFC 3947]
    2014:07:27-10:30:00 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: enabling possible NAT-traversal with method 3
    2014:07:27-10:30:01 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: NAT-Traversal: Result using RFC 3947: no NAT detected
    2014:07:27-10:30:02 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: Peer ID is ID_IPV4_ADDR: '109.201.143.91'
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: Dead Peer Detection (RFC 3706) enabled
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: ISAKMP SA established
    2014:07:27-10:30:02 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: parsing XAUTH request
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: sending XAUTH reply
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: parsing XAUTH status
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: extended authentication was successful
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: sending XAUTH ack
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: sent XAUTH ack, established
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #9: initiating Quick Mode ENCRYPT+TUNNEL+UP+XAUTHPSK {using isakmp#8}
    2014:07:27-10:30:02 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:02 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: ignoring informational payload, type INVALID_ID_INFORMATION
    2014:07:27-10:30:02 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:03 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:03 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:03 jphs pluto[16069]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:27-10:30:12 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: ignoring informational payload, type INVALID_MESSAGE_ID
    2014:07:27-10:30:32 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: ignoring informational payload, type INVALID_MESSAGE_ID
    2014:07:27-10:31:12 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #9: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
    2014:07:27-10:31:12 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #9: starting keying attempt 2 of an unlimited number
    2014:07:27-10:31:12 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #10: initiating Quick Mode ENCRYPT+TUNNEL+UP+XAUTHPSK to replace #9 {using isakmp#8}
    2014:07:27-10:31:12 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: ignoring informational payload, type INVALID_ID_INFORMATION
    2014:07:27-10:31:22 jphs pluto[16069]: "S_Hide.me VPN NL Roosendaal" #8: ignoring informational payload, type INVALID_MESSAGE_ID 

    Kann damit jemand etwas anfangen?
  • (Sorry, my German-speaking brain seems to be on vacation. [;)] )

    I don't think this can work with the UTM.

    MfG - Bob (Bitte, auf Deutsch weiterhin.)
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Das hatte ich bereits versucht, allerdings kann dann der IPsec Tunnel nicht aufgebaut werden.
    ...
    Kann damit jemand etwas anfangen?

    Ich würd' fast meinen, die Gegenstelle kennt Dein LAN nicht, sondern nur Deine externe Adresse. Da diese dort als remote address eingetragen ist, wird die Verbindung wohl fehlschlagen, sobald Du was anderes hinzufügst.

    Was steht denn so in den Logs, wenn das VPN etabliert ist?
  • Was steht denn so in den Logs, wenn das VPN etabliert ist?


    Wenn die Verbindung mit den ursprünglichen Settings (wie oben im ersten Post beschrieben) hergestellt wird, wird folgendes ins Log geschrieben:

    2014:07:28-17:03:47 jphs pluto[19437]: listening for IKE messages
    2014:07:28-17:03:47 jphs pluto[19437]: forgetting secrets
    2014:07:28-17:03:47 jphs pluto[19437]: loading secrets from "/etc/ipsec.secrets"
    2014:07:28-17:03:47 jphs pluto[19437]: loaded private key from 'Local X509 Cert (regenerated).pem'
    2014:07:28-17:03:47 jphs pluto[19437]: loaded XAUTH secret for ***@sophos 109.201.143.91
    2014:07:28-17:03:47 jphs pluto[19437]: loaded PSK secret for 79.234.103.57 109.201.143.91
    2014:07:28-17:03:47 jphs pluto[19437]: forgetting secrets
    2014:07:28-17:03:47 jphs pluto[19437]: loading secrets from "/etc/ipsec.secrets"
    2014:07:28-17:03:47 jphs pluto[19437]: loaded private key from 'Local X509 Cert (regenerated).pem'
    2014:07:28-17:03:47 jphs pluto[19437]: loaded XAUTH secret for ***@sophos 109.201.143.91
    2014:07:28-17:03:47 jphs pluto[19437]: loaded PSK secret for 79.234.103.57 109.201.143.91
    2014:07:28-17:03:47 jphs pluto[19437]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2014:07:28-17:03:47 jphs pluto[19437]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
    2014:07:28-17:03:47 jphs pluto[19437]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA (Wed Jul 16 22:32:09 2014).pem'
    2014:07:28-17:03:47 jphs pluto[19437]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2014:07:28-17:03:47 jphs pluto[19437]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2014:07:28-17:03:47 jphs pluto[19437]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2014:07:28-17:03:47 jphs pluto[19437]: Changing to directory '/etc/ipsec.d/crls'
    2014:07:28-17:03:47 jphs pluto[19437]: added connection description "S_Hide.me VPN NL Roosendaal"
    2014:07:28-17:03:47 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: initiating Main Mode
    2014:07:28-17:03:47 jphs pluto[19437]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:28-17:03:47 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: received Vendor ID payload [strongSwan]
    2014:07:28-17:03:47 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: received Vendor ID payload [XAUTH]
    2014:07:28-17:03:47 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: received Vendor ID payload [Dead Peer Detection]
    2014:07:28-17:03:47 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: received Vendor ID payload [RFC 3947]
    2014:07:28-17:03:47 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: enabling possible NAT-traversal with method 3
    2014:07:28-17:03:48 jphs pluto[19437]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: NAT-Traversal: Result using RFC 3947: no NAT detected
    2014:07:28-17:03:48 jphs pluto[19437]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: Peer ID is ID_IPV4_ADDR: '109.201.143.91'
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: Dead Peer Detection (RFC 3706) enabled
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: ISAKMP SA established
    2014:07:28-17:03:48 jphs pluto[19437]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: parsing XAUTH request
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: sending XAUTH reply
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: parsing XAUTH status
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: extended authentication was successful
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: sending XAUTH ack
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #1: sent XAUTH ack, established
    2014:07:28-17:03:48 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #2: initiating Quick Mode ENCRYPT+TUNNEL+UP+XAUTHPSK {using isakmp#1}
    2014:07:28-17:03:48 jphs pluto[19437]: added connection description "X_Hide.me VPN NL Roosendaal"
    2014:07:28-17:03:49 jphs pluto[19437]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="Hide.me VPN NL Roosendaal" address="79.234.103.57" local_net="79.234.103.57/32" remote_net="0.0.0.0/0"
    2014:07:28-17:03:49 jphs pluto[19437]: "S_Hide.me VPN NL Roosendaal" #2: sent QI2, IPsec SA established {ESP=>0xcd98359f 
  • Nicht das VPN Logs - Packetfilter, Webproxy, System etc.
    Und Ping und Traceroute?
  • Vielleicht irre ich mich, aber ich glaube, dass du hier zwei Sachen kombinierst, die nicht zusammen gehören.

    Das eine ist die VPN-Verbindung, die dir ein entferntes Netz zur Verfügung stellt und ggf. auch anders herum (was vielleicht ungünstig ist).

    Sofern die Verbindung steht, kannst du über das Routing der Firewall, den Weg deines internen Traffics bestimmen.

    Ich glaube nicht, dass die Astaro automatisch alles über den Tunnel schickt, nur weil du als Remote-Netz des Tunnels "Internet" stehen hast.

    Deine Default-Route ins Internet findest du unter "Network Protection\NAT" und das Default-Gateway steht an deinem WAN-Interface.

    Wenn du deinen Traffic anders routen willst, musst du das der Firewall mitteilen.

    Viele Grüße
    hidden.
  • Hi,

    du must als lokales netz auf jeden Fall dein lokales LAN eintragen. Wenn der Tunnel damit nicht aufgebaut wird stimmen die Tunnel Parameter der Remotesite nicht. Die Netze müssen auf beiden Seiten zusammen passen.

    Eine Anforderung den gesamten Traffic darüber zu routen habe ich auch noch nicht gehabt. Ich denke hier musst du ein wenig rum experimentieren. Vielleicht funktioniert das ja mit policy based Routing. Wäre einen Versuch wert [;)]

    vg
    mod
  • (Sorry, my German-speaking brain seems to be on an extended vacation. [;)] )

    Stephan, are you trying to have web surfing go through the HTTP/S Proxy and then through the VPN tunnel?  The problem is that I don't think it's possible to SNAT traffic leaving the Proxy into an IPsec tunnel.  The only thing I can imagine might be having an Additional Address named "Hide me" on the External interface, having "External [Hide me] (Address)" alone in 'Local networks' in your IPsec Connection definition ('Strict routing' not selected) and using a NAT rule like:

    SNAT : External (Address) -> Web Surfing -> Internet : from External [Hide me] (Address)



    Geht's so, oder immer noch Pech gehabt ?

    MfG - Bob (Bitte, auf Deutsch weiterhin.)
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Remote-Network muss immer die Netzwerke beinhalten, die auf der anderen Seite erreicht werden sollen.
    Local-Network muss die Netze beinhalten, die auf der eigenen Seite erreichbar sein sollten.
    Bei etabliertem Tunnel werden nämlich mit diesen Daten die notwendigen Routingeinträge gesetzt.

    Diese Einstellungen müssen bei beiden IPSec-Partnern gleich sein - also LocalNet Site1 = RemoteNet Site 2 und LocalNet Site2 = RemoteNet Site1.

    Wenn der Tunnel steht dann musst du noch das Routing anpassen.
    Mit einer Richtlinienroute für LAN sollte das eigentlich problemlos machbar sein, indem du dort dann die UTM auf der anderen Seite des Tunnels mit ihrer LAN-Adresse angibst.

    Wird ein Failover gewünscht, dann kann man mit der Bindung der Tunnel an eine Schnittstelle experimentieren. Dazu steht auch etwas in der Hilfe.

    Grüße
    Sebastian
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?