Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 4 subscribers
  • Views 2820 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

NAT Masquereding stellt Funktion ein

Daniel Beckers

Guten Morgen,

ich habe seit Tagen ein sehr seltsames Phänomen. An einer SG135 betreibe ich verschiedene Netze - eines ist das Gäste WLAN. Da hier der Zugang relativ frei ist, habe ich auch eine separate Maskierungsregel erstellt, damit die Nutzer eine andere IP nutzen, wenn Sie ins Internet gehen. Jeden Morgen wenn ich ins Büro kommen, muss ich aber diese Regel löschen und neuerstellen, da ich keine Verbindung mehr über diese Regel ins Internet habe. Auf der Firewall sind die Pakete grün. Bei einem tcpdump konnte ich erkenne, dass von WAN Seite, das Paket garnicht zurück kommt - jedoch wird das Paket das ins WAN geht doppelt angezeigt (bei einem PING). Sobald ich dann die Regel auf einen andere externe Schnittstelle lege, klappt alles wieder... bis zum nächsten Tag (anscheinend, da in der Nacht kein Traffic generiert wird). Hat irgendjemand ne Idee? Auf der UTM ist die neuste Version. 



This thread was automatically locked due to age.
Parents
  • 0

    Hallo Daniel,

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

    You say "die neuste Version" - is that 9.510?

    Can you show us about 20 lines from your tcpdump demonstrating what you describe.  Also, please show us your tcpdump command.

    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

    Hallo BAlfson,

    ich habe zuerst eine PING aus einem Netz gesendet, das keine Probleme hat (4x), dann einen Ping aus dem Netz das Probleme macht, an den gleichen externen Host (4x)

     

    sg135:/home/login # tcpdump -i any -n -e 'icmp and (host 192.168.32.135 or host 192.168.31.180 or host 81.169.XXX.XXX)'
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    08:01:21.058571 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 163, length 40
    08:01:21.087288 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 163, length 40
    08:01:21.087380 Out 00:1a:8c:4c:55:60 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.31.180: ICMP echo reply, id 1, seq 163, length 40
    08:01:22.061227 In 4c:cc:6a:64:0b:3e ethertype IPv4 (0x0800), length 76: 192.168.31.180 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 164, length 40
    08:01:22.061398 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 164, length 40
    08:01:22.091829 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 164, length 40
    08:01:22.091923 Out 00:1a:8c:4c:55:60 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.31.180: ICMP echo reply, id 1, seq 164, length 40
    08:01:23.072072 In 4c:cc:6a:64:0b:3e ethertype IPv4 (0x0800), length 76: 192.168.31.180 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 165, length 40
    08:01:23.072209 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 165, length 40
    08:01:23.112145 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 165, length 40
    08:01:23.112257 Out 00:1a:8c:4c:55:60 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.31.180: ICMP echo reply, id 1, seq 165, length 40
    08:01:24.079921 In 4c:cc:6a:64:0b:3e ethertype IPv4 (0x0800), length 76: 192.168.31.180 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 166, length 40
    08:01:24.080075 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 166, length 40
    08:01:24.108012 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 166, length 40
    08:01:24.108131 Out 00:1a:8c:4c:55:60 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.31.180: ICMP echo reply, id 1, seq 166, length 40
    08:01:28.443399 In 60:6c:66:a1:56:58 ethertype IPv4 (0x0800), length 76: 192.168.32.135 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 117, length 40
    08:01:28.443606 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 117, length 40
    08:01:28.472372 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 117, length 40
    08:01:28.472471 Out 00:1a:8c:4c:55:66 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.32.135: ICMP echo reply, id 1, seq 117, length 40
    08:01:29.452778 In 60:6c:66:a1:56:58 ethertype IPv4 (0x0800), length 76: 192.168.32.135 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 118, length 40
    08:01:29.452940 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 118, length 40
    08:01:29.482422 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 118, length 40
    08:01:29.482510 Out 00:1a:8c:4c:55:66 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.32.135: ICMP echo reply, id 1, seq 118, length 40
    08:01:30.451137 In 60:6c:66:a1:56:58 ethertype IPv4 (0x0800), length 76: 192.168.32.135 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 119, length 40
    08:01:30.451307 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 119, length 40
    08:01:30.479432 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 119, length 40
    08:01:30.479594 Out 00:1a:8c:4c:55:66 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.32.135: ICMP echo reply, id 1, seq 119, length 40
    08:01:31.467809 In 60:6c:66:a1:56:58 ethertype IPv4 (0x0800), length 76: 192.168.32.135 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 120, length 40
    08:01:31.467921 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 120, length 40
    08:01:31.497687 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 120, length 40
    08:01:31.497784 Out 00:1a:8c:4c:55:66 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.32.135: ICMP echo reply, id 1, seq 120, length 40

    Ein Ping von einem internen Host auf den anderen über das GW funktioniert - allerdings ist hier keine Maskierung aktiv. Seltsam ist aber nun auch, dass ich das Probleme heute morgen nur auf dem Notebook hatte, jedoch nicht auf dem Handy - beide hängen im gleichen WLAN auf dem gleichen Netz.

    Anbei auch noch ein paar Bilder der Config:

    Danke für eure Unterstützung

  • 0 in reply to Daniel Beckers

    Assuming that Internal is on eth0 and External is on eth1, I interpret the following as:

    08:01:28.443399 In 60:6c:66:a1:56:58 ethertype IPv4 (0x0800), length 76: 192.168.32.135 > 81.169.XXX.XXX: ICMP echo request, id 1, seq 117, length 40
    08:01:28.443606 Out 00:1a:8c:4c:55:61 ethertype IPv4 (0x0800), length 76: 130.180.XXX.XXX > 81.169.XXX.XXX: ICMP echo request, id 1, seq 117, length 40
    08:01:28.472372 In 18:59:33:8d:91:6f ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 130.180.XXX.XXX: ICMP echo reply, id 1, seq 117, length 40
    08:01:28.472471 Out 00:1a:8c:4c:55:66 ethertype IPv4 (0x0800), length 76: 81.169.XXX.XXX > 192.168.32.135: ICMP echo reply, id 1, seq 117, length 40

    Ping request packet from 192.168.32.135 to 81.169.XXX.XXX arrives on eth0
    Ping request packet to 81.169.XXX.XXX is masqueraded from eth1
    Ping reply packet from 81.169.XXX.XXX arrives on eth1
    Ping reply packet from 81.169.XXX.XXX is forwarded to 192.168.32.135

    So, everything looks normal to me.  What happens if you disable the firewall on your PC before trying the ping?

    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

    Hi,

     

    du hast mehrere Uplinks wie ich im Screenshot erkennen konnte. Mit welcher Adresse geht das Gast-WLan raus, wenn dieser Fehler auftritt?

    Ist das eine Adresse auf dem gleichen Uplinkinterface? Wenn nicht würde ich das Routing prüfen.

     

    Gruß

    Hendrik

Reply
  • 0 in reply to BAlfson

    Hi,

     

    du hast mehrere Uplinks wie ich im Screenshot erkennen konnte. Mit welcher Adresse geht das Gast-WLan raus, wenn dieser Fehler auftritt?

    Ist das eine Adresse auf dem gleichen Uplinkinterface? Wenn nicht würde ich das Routing prüfen.

     

    Gruß

    Hendrik

Children
No Data
Unfiltered HTML