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

Keine Route von Sophos SG-125 zu externem Netzwerk, Routingproblem?

Ich habe ein Problem mit meiner Sophos SG-125 mit UTM9:

Es gibt ein internes Netzwerk 192.168.0.0/24 und via Site-2-Site-VPN ist ein externes Netzwerk 172.31.0.0/16 in AWS angebunden.

Alles funktioniert perfekt. Geräte aus dem internen Netz erreichen die Cloud und umgekehrt. Da ICMP explizit erlaubt ist, können sich die Geräte auch netzübergreifend pingen.

Außer: die Firewall selbst kann keine IP im externen Netz pingen. Ich habe im externen Netz einen Radius-Server, den ich in der Firewall eintragen möchte. Auch dieser ist nicht erreichbar.

Was muss ich tun, damit die Sophos Adressen im externen Netz erreicht. Ich dachte, eine statische Route wäre nicht erforderlich, da ja bereits das Site-2-Site-VPN eine Route für das gesamte Netz anlegt.

Habe ich etwas übersehen?

Um es nochmal deutlich zu machen. Es geht nur darum, dass die Firewall selbst keine Adressen im externen Netz erreicht. Aus dem lokalen Netz ist alles erreichbar.



This thread was automatically locked due to age.
Parents
  • Hallo Bert,

    Herzlich willkommen hier in der Community !

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. Frowning2)

    What do you see in the Routes Table relative to 172.31.0.0/16?

    Do you see traffic blocked in the firewall log?

    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
  • Hallo Bob,

    in der Route Table sehe ich:

    172.31.0.0/16 via 169.254.32.29 dev vpc0.0  proto zebra  metric 100

    Im Firewall-Log tauchen die geblockten Requests nicht auf.

    Hier gibt es einen anderen User mit dem gleichen Problem:

    https://community.sophos.com/utm-firewall/f/management-networking-logging-and-reporting/34695/how-to-route-traffic-originating-on-utm-to-server-in-amazon-vpc

    Eine Lösung ist am Ende genannt, aber ich verstehe nicht genau, wie die SNAT-Regel angelegt werden muss. :-(

  • Good find, Bert.  I agree that the description is difficult to follow

    Assuming that the interface address is 192.168.0.1, and your endpoint has an IP of 87.x.y.153 try:

         SNAT : {87.x.y.153} -> Any -> {172.31.0.0/16} : from {192.168.0.1}

         Might need to select "Rule applies to IPsec packets" in 'Advanced'.

    Glück damit 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
  • Sorry, hier bin ich ein wenig "lost". Mal ganz dumm gefragt:

    Ich gehe in Interfaces & Routing -> Static Routing

    Unter "Policy Routes" mache ich eine...

    - Route vom Typ "Interface route"

    - Source Interface "Internal"

    -Source Network: die Interface IP von vpc0.0 die ich mittels ifconfig ausgelesen habe
    - Service: Any

    - Destination network: die IP welche ich erreichen/pingen will

    - Target interface: External (WAN)

    So klappt es nicht. Was mache ich falsch?

  • Hier habe ich noch einen offensichtlich wertvollen Tipp gefunden:

    https://community.sophos.com/utm-firewall/f/management-networking-logging-and-reporting/34540/aws-vpc-peering-and-routing

    Unter NAT existiert per Default ein Masquerading Internal (Network) -> External (WAN).

    Hier habe ich nun einen neuen Eintrag Any -> External (WAN) hinzugefügt, um das "selfNAT" der Firewall zu ermöglichen.

    Löst das Problem nicht, scheint mir aber ein Bestandteil der Lösung zu sein.

  • I also tried tcpdump icmp on the console. I see all pings from the firewall to any local IP. But no pings into the external net appear.

  • Static Routes can't be used with IPsec tunnels - they have no effect.  I wonder what's happening in the tunnel.  Before doing the following, check to be certain that you have 192.168.0.0/24 and 172.31.0.0/16 correctly configured in AWS and in your UTM's IPsec setup.

    If the name of your IPsec Connection is 'AWS', as root, then get the REF with

         cc get_object_by_name ipsec_connection site_to_site 'AWS'|grep \'ref

    The result will contain something like REF_IpsSitAws.  Now, watch the traffic in the tunnel with:

         espdump -n --conn REF_IpsSitAws -vv

    Copy here six lines when you ping from behind the IPsec endpoint in AWS to a device in your internal network. Also, six lines when you ping from your internal network to AWS.

    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
  • Amazon VPC-Verbindungen sind zwar IPSEC-Verbindungen, werden in der Firewall aber irgendwie separat behandelt. Dieses Kommando liefert z.B. nur einen Eintrag für eine deaktivierte Azure Site-2-Site-Verbindung:

    cc get ipsec connections

    [
              'REF_IpsSitAzureConne'
     ]

    Jedoch nicht die aktive Amazon VPC-Verbindung.

    Es gibt auch keinen Namen den ich einer VPC-Verbindung mitgeben kann. Wenn ich nach der Routing-Tabelle gehe ist der interne Name "vpc-0", aber

    cc get_object_by_name ipsec_connection site_to_site 'vpc-0'

    ...liefert nichts als den Statuscode 0 zurück.

  • Ahhh - I forgot it was VPC.  I don't remember having any problem, so I'm guessing...

    Does the following give you the tunnel name?

          cc get_objects ipsec_connection amazon_vpc|grep \'ref

    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
  • OK, . Das funktionierte. Da auf dem Tunnel viel Traffic ist, habe ich gefiltert und nacheinander ausgeführt:

    a) espdump -n --conn REF_IpsAmaVpn0f77f21 -vv | grep ICMP

    b) espdump -n --conn REF_IpsAmaVpn0f77f21 -vv | grep 1812

    c) espdump -n --conn REF_IpsAmaVpn0f77f22 -vv | grep ICMP

    d) espdump -n --conn REF_IpsAmaVpn0f77f22 -vv | grep 1812

    Dabei konnte ich Pings von meinem Rechner im internen Netz nach extern mit a) sehen. Ein Ping vom Tools-Menü der Firewall zu einer remote-Adresse schlug fehl und es gab keinen Logeintrag auf der Konsole.

    Ebenso schlug fehl, einen Radius-Client im Remote-Net in die Firewall einzutragen und zu testen. b) und d) zeigten keinen Logeintrag und im UI gibt es einen Timeout.

    Sieht so aus, als ob einfach das Routing von self-originated Traffic in Richtung Tunnel nicht funktioniert. :-(

Reply
  • OK, . Das funktionierte. Da auf dem Tunnel viel Traffic ist, habe ich gefiltert und nacheinander ausgeführt:

    a) espdump -n --conn REF_IpsAmaVpn0f77f21 -vv | grep ICMP

    b) espdump -n --conn REF_IpsAmaVpn0f77f21 -vv | grep 1812

    c) espdump -n --conn REF_IpsAmaVpn0f77f22 -vv | grep ICMP

    d) espdump -n --conn REF_IpsAmaVpn0f77f22 -vv | grep 1812

    Dabei konnte ich Pings von meinem Rechner im internen Netz nach extern mit a) sehen. Ein Ping vom Tools-Menü der Firewall zu einer remote-Adresse schlug fehl und es gab keinen Logeintrag auf der Konsole.

    Ebenso schlug fehl, einen Radius-Client im Remote-Net in die Firewall einzutragen und zu testen. b) und d) zeigten keinen Logeintrag und im UI gibt es einen Timeout.

    Sieht so aus, als ob einfach das Routing von self-originated Traffic in Richtung Tunnel nicht funktioniert. :-(

Children
No Data