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 7050 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.
Parents
  • 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 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.
Reply
  • 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.
Children
  • 0 in reply to tobias.d

    - 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...)


    Damit er ins Internet kommt wäre evtl. eine Masquerading-Regel geschickter, die greift nämlich nur wenn das Paket auch wirklich die Firewall zum Externen Interface verlässt. 
    Alternativ als Destination in der SNAT Regel "Internet IPv4" angeben, damit nur Internetverkehr betroffen ist.
    Aber genau solche Any/Any-Nat-Regeln sind es wohl, die dir hier in die Quere kommen.


    - "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)

    Mein Fehler. Ich meinte Network-Security - Firewall und dann den Tab "Advanced". Dort dann die Checkbox "Use strict TCP session handling". Aber wie gesagt, für ICMP eh erstmal uninteressant und so auch Standardeinstellung.




    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.


    Es dauert in der Tat etwas, bis er Änderungen auch für ICMP-Verbindungen übernimmt, da er beim ersten ICMP Paket eine "virtuelle Session" erstellt. 
    D.h. du solltest nach aktivieren/deaktivieren der Regeln/NAT/... erstmal ca 1 bis 2 Minuten (offizielle glaub ich genau 30 Sekunden, aber sicher ist sicher) garnicht pingen, damit er die Session wieder verwirft.

    Gruß,
    Matthias
Unfiltered HTML