Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 38 subscribers
  • Views 7053 views
  • Users 0 members are here
Options
Suggested
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

Statische (Gateway-)Route funktioniert nicht...?

tobias.d
Hallo zusammen,

kurz und knapp:
Ich habe eine statische Gateway-Route in unserem ASG V7 eingetragen, damit die Server dort im lokalen Netz wissen, wie sie durch den VPN-Tunnel auf ein anderes Subnet kommen. Also Netz (das Netz auf der anderen Seite des Tunnels) und Gateway (das VPN-Gateway im lokalen Netz). Soweit hoffentlich verständlich.

Das Problem:
Trage ich diese Route im ASG ein, kann ich keine Rechner durch den Tunnel erreichen.
Trage ich diese Route in einem Server (getestet mit Windows Server 2k8) im Netz des ASG direkt ein, funktioniert es.

Wenn die Route im ASG steht, kommt der Trace nach dem zweiten Hop nicht weiter. Steht die Route im Windows Server, kommt der Trace bis zum Ziel.

Versteht das jemand? [:S]
Für Hilfe wäre ich sehr dankbar.

Trace mit Route im ASG
  1    


Trace mit Route im Windows Server
  1    


This thread was automatically locked due to age.
  • 0
    (Sorry that I can't get my German-speaking brain to work! [:(])

    Static routing won't work.  You must add the subnet to the VPN tunnel: to the equivalent of 'Local networks' in your location, and to 'Remote networks' in the Astaro in the other location.

    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
  • 0 in reply to BAlfson
    Sorry, das versteh ich jetzt nicht ganz (also jetzt nicht wegen englisch... [;)]).

    Die andere Seite ist das Büro, dort befindet sich kein ASG, sondern nur eine normalsterbliche Router-Firewall. Dort habe ich auch eine statische Route eingetragen, die ohne Probleme funktioniert.

    Die statische Route soll ja nur dem ASG sagen, wo es die Clients hinleiten soll, wenn jemand auf die andere Seite des VPN möchte.

    Hier mal eine Übersicht:
  • 0
    I think your VPN Gateway or VPN is misconfigured.  Your traceroute shows that the Astaro correctly sends packets to the VPN gateway, but that the VPN gateway doesn't know where to send the traffic.  Have you checked the route table in that machine?

    I did not look closely enough at your traceroutes.  I had assumed the ASG was a part of the VPN, and that you had an additional subnet with another router on the other side.  That situation is similar to Routing mehrere VPN-tunnel.

    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
  • 0 in reply to BAlfson
    The thing is: if i add the route not in the ASG but in windows, the trace goes through (as you see in my first post). Why isn't it working when i add the route to the ASG? It's the same route.
    The VPN should be configured correctly as far as i know (it's openVPN, not IPSec). When the route is added to windows (a server behind the VPN-Gateway, not the VPN-Gateway itself!), everything works fine (remote desktop, ping, etc.). The VPN-Gateway has all routes, otherwise it should never work.

    Somehow it feels like as if the ASG has something to do with this, but i am not sure how or what... [:(]
    Do i need a packet filter or something else? For me this makes no sense at all.

    Thanks!
    Tobias
  • 0
    Watch with a protocol analyzer between the ASG and the VPN Gateway (or tcpdump on the VPN Gateway) - does it show that packets are forwarded successfully from the ASG to the VPN Gateway?

    MfG - Bob (Bitte, auf Deutsch weiterhin!) 
    PS I don't think this is the issue, but, remember that ping behavior in the Astaro is regulated on the 'ICMP' tab in 'Firewall'.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Why would the ICMP settings do anything in this case? Isn't the ASG only supposed to give the route to the client?

    I'm workling with tcpdump now, will post results later.


    Here are the results of tcpdump.

    When the route is in Windows, everything seems fine (192.168.36.232 beeing the client where i ping from, and the tcpdump is obviously from the VPN-gateway):

    14:22:47.014787 IP 192.168.36.232 > 192.168.1.11: ICMP echo request, id 1, seq 1041, length 40
    14:22:47.059780 IP 192.168.1.11 > 192.168.36.232: ICMP echo reply, id 1, seq 1041, length 40
    14:22:48.025625 IP 192.168.36.232 > 192.168.1.11: ICMP echo request, id 1, seq 1042, length 40
    14:22:48.069536 IP 192.168.1.11 > 192.168.36.232: ICMP echo reply, id 1, seq 1042, length 40
    14:22:49.024898 IP 192.168.36.232 > 192.168.1.11: ICMP echo request, id 1, seq 1043, length 40
    14:22:49.069267 IP 192.168.1.11 > 192.168.36.232: ICMP echo reply, id 1, seq 1043, length 40
    14:22:50.038772 IP 192.168.36.232 > 192.168.1.11: ICMP echo request, id 1, seq 1044, length 40
    14:22:50.083506 IP 192.168.1.11 > 192.168.36.232: ICMP echo reply, id 1, seq 1044, length 40


    Now with route in the ASG:

    14:20:21.638574 IP external.domain.net > 192.168.1.11: ICMP echo request, id 1, seq 1037, length 40
    14:20:26.427416 IP external.domain.net > 192.168.1.11: ICMP echo request, id 1, seq 1038, length 40
    14:20:31.061473 IP external.domain.net > 192.168.1.11: ICMP echo request, id 1, seq 1039, length 40
    14:20:35.695576 IP external.domain.net > 192.168.1.11: ICMP echo request, id 1, seq 1040, length 40


    For some reason, the ping request here seems to come from the external domain bound to the external IP (external interface) of the ASG, and not from the original client (192.168.36.232). I don't understand how this is happening, it should only route on the internal network to another machine... why would it switch (or hop) to another interface? [:(]
    I set both network definitions used in the static route to "internal interface", with no effect.
  • 0
    Why would the ICMP settings do anything in this case? Isn't the ASG only supposed to give the route to the client?

    Any block on the 'ICMP' tab takes precence over any other rule, but I think this isn't the problem here.

    I don't understand why this is happening. Try a test: in the ASG, set the Network definiton for 192.168.1.0/24 to 'Interface: Internal'.  If that doesn't solve the problem, then I think you must have a NAT rule that's handling the traffic.  If it does fix the problem, then I'd appreciate it if someone would tell me why!

    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
  • 0 in reply to tobias.d
    For some reason, the ping request here seems to come from the external domain bound to the external IP (external interface) of the ASG, and not from the original client (192.168.36.232). I don't understand how this is happening, it should only route on the internal network to another machine... why would it switch (or hop) to another interface? [:(]


    Der einzige Grund, warum die ASG das machen sollte, wäre wenn es eine NAT Regel gäbe auf die der Traffic matched. 
    Dass so damit keine Antwort zurück kommen kann ist klar, da der OpenVPN-Gateway mit der öffentlichen IP der ASG nicht anfangen kann oder besser gesagt will. 

    Überprüfe noch mal folgende Einstellungen:

    - kein NAT das auf die Verbindung matched
    - Paketfilter Regel für den Verkehr vom Netz 192.168.36.0/24 ins Netz 192.168.1.0/24 
    - Gateway-Route für das Netz 192.168.1.0/24 mit Gateway 192.168.36.243 (aber das passt ja, sieht man aus dem Trace)
    - keine Richtlinienroute vorhanden, die deine Einstellungen überschreiben würde
    - "Strikte TCP-Sitzungsverwaltung verwenden" unter Network Securtiy-Advanced deaktiviert (fürs ICMP irrelevant, aber für späteren TCP Verkehr wichtig, da die ASG den "Rückverkehr" nie sehen wird.

    Gruß,
    Matthias
  • 0 in reply to matthias.schmidt
    I set both network definitions used in the static route to "internal interface", with no effect.

    @BAlfson
    Hatte ich schon versucht. [:(]

    Der einzige Grund, warum die ASG das machen sollte, wäre wenn es eine NAT Regel gäbe auf die der Traffic matched. 
    Dass so damit keine Antwort zurück kommen kann ist klar, da der OpenVPN-Gateway mit der öffentlichen IP der ASG nicht anfangen kann oder besser gesagt will. 

    Überprüfe noch mal folgende Einstellungen:

    - kein NAT das auf die Verbindung matched
    - Paketfilter Regel für den Verkehr vom Netz 192.168.36.0/24 ins Netz 192.168.1.0/24 
    - Gateway-Route für das Netz 192.168.1.0/24 mit Gateway 192.168.36.243 (aber das passt ja, sieht man aus dem Trace)
    - keine Richtlinienroute vorhanden, die deine Einstellungen überschreiben würde
    - "Strikte TCP-Sitzungsverwaltung verwenden" unter Network Securtiy-Advanced deaktiviert (fürs ICMP irrelevant, aber für späteren TCP Verkehr wichtig, da die ASG den "Rückverkehr" nie sehen wird.

    Gruß,
    Matthias

    @BAlfson&Matthias
    Denn werde ich die NAT-Regeln mal durchkämmen, sind über 150.

    Danke für Eure Hilfe!
  • 0 in reply to matthias.schmidt
    Ich mach das mal als Checkliste

    - kein NAT das auf die Verbindung matched

    Hier bin ich mir nicht 100% sicher, was genau darauf Einfluss nehmen würde.
    192.168.1.0 wird an zwei Stellen verwendet
    - als destination im packet filter
    - als network in der static route für das VPN
    192.168.36.0 (internal network des ASG) wird an vielen Stellen verwendet
    - eMail security smtp relaying
    - intrusion prevention
    - in einer "standard static route" (?)
    - diverse packet filter von internal (address) nach internal (network)
    - im packet filter vom internal network (192.168.36.0) zum lokalen netz am anderen Ende des VPN (192.168.1.0)
    External (Address) bzw. external.domain.net wird in vielen NAT-Regeln benutzt... ich versuch mal die relevanten zu nennen
    - SNAT für die ausgehende VPN-Verbindung (VPN-Gateway -> OpenVPN-Port -> Büro dyndns ausgehend von external address)
    - DNAT für die eingehende VPN-Verbindung (Büro dyndns -> OpenVPN-Port -> external address weiterleitung zum VPN-Gateway)
    - SNAT für den Client, von dem aus ich die Pingtests gemacht habe bzw. den ich von der anderen Seite des VPN erreichen möchte (Client -> any -> any ausgehend von external address) - diese Regel habe ich testweise deaktiviert (allerdings sollte der client ins Internet kommen...)

    - Paketfilter Regel für den Verkehr vom Netz 192.168.36.0/24 ins Netz 192.168.1.0/24 - erledigt

    - Gateway-Route für das Netz 192.168.1.0/24 mit Gateway 192.168.36.243 (aber das passt ja, sieht man aus dem Trace) - vorhanden

    - keine Richtlinienroute vorhanden, die deine Einstellungen überschreiben würde - ok

    - "Strikte TCP-Sitzungsverwaltung verwenden" unter Network Securtiy-Advanced deaktiviert (fürs ICMP irrelevant, aber für späteren TCP Verkehr wichtig, da die ASG den "Rückverkehr" nie sehen wird. - hier hab ich (englisch) "Generic Proxy" (nichts), "SOCKS Proxy (disabled) und IDENT Reverse Proxy (disabled)

    Ich muss schon sagen, dass ich das alles für eine simple Route, die in der gammeligen Büro-Fritzbox problemlos funktioniert, sehr aufwendig finde. Zumal die Bedingung der Route ja der Verkehr mit dem Ziel 192.168.1.0 ist, was sonst nirgendwo verwendet wird...

    Ich habe gestern die oben erwähnten NAT-Regeln überarbeitet und überhautp viele Sachen durcheinander versucht. Aber erst heute (wahrscheinlich waren heute Nacht die Konfigurations-Kobolde wieder unterwegs) funktionierte es, so wie es soll. Ich werde das nun weiter beobachten, vielleicht hab ich auch nur was übersehen, und es funktioniert gar nicht wirklich. [;)]


    Von einem anderen Client, der die selbe NAT-Regel hat (Client -> any -> any ausgehend von external address), funktioniert wieder nichts. Dort wird mir wieder als Ping-Quelle das externe interface genannt... *seufz*
    Also entweder braucht es mehrere Stunden, bis das Aktivieren/Deaktivieren dieser Regel greift, oder ich weiss langsam auch nicht mehr... hab Kopfschmerzen. Vielleicht ein VPN-Restart? Beim ersten Client hab ich die Regel inzwischen wieder testweise aktiviert, und er pingt fröhlich weiter.
Unfiltered HTML