Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 25 subscribers
  • Views 6504 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!
Reply
  • 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!
Children
No Data
Unfiltered HTML