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

Gateway hängt sich auf

Moin,

heute hatte ich einen interessanten Ausfall:
In der SG sind ~30 VLANs am laufen, allesamt mit der Gateway *.*.*.1 bzw. entsprechende aus den /30er/29er/28er Netzen.
Nach einem kurzen Schreck kamen wir schnell dahinter, dass heute ein Subnetz zwar funktioniert, aber nichts mehr über die Gateway lief, in sowie out.
Dazu einfach das Interface aus Zeitgründen disabled und wieder enabled, lief wieder. Den Luxus um den Fehler aufzuzeichnen hatten wir nicht.
Möglicherweise hätte ein reload via Console für das Netzwerkmodul in Linux gereicht.

Nun, mich interessiert für die Nachbereitung für das interne Eskalationsmanagement: Hatte das jemand anderes bereits erlebt? WAS ist da passiert, wie könnte man das forcen? Wenn man die Ursache kennt, könnte man das fixen. Es ist das erste Mal, dass mir eine Gateway abrauchte, aber ich will das nicht einfach abhaken.

Gruß, Patrick

This thread was automatically locked due to age.

0 dirkkotte over 4 years ago

Hallo,

einen solchen Fehler durch SG verursacht habe ich noch nicht erlebt.

Damit auch keine schlüssige idee, wonach zu suchen wäre.

Evtl. für den betreffenden Zeitraum alle Logfiles durchsehen.

Ich habe mir aber einen ähnlich aussehenden Fehler selbst gebaut.

- eine Zusätzliche interface-IP lässt sich an das falsche Interface binden.

das fiel anfangs gar nicht auf, nur nach einen reboot wurde es hässlich.

Mit link down/up war das temporär zu korrigieren.

... und mit binden der Adresse an das richtige Interface zu beheben, das war aber Stunden später.

Dirk

Systema Gesellschaft für angewandte Datentechnik mbH // Sophos Platinum Partner
Sophos Solution Partner since 2003
If a post solves your question, click the 'Verify Answer' link at this post.
Cancel
Vote Up 0 Vote Down

Cancel
0 Patrick Lachmann over 4 years ago in reply to dirkkotte

Ich habe da mal was großzügig rausgeschnipselt.

Vorher und insb. beim Fehlerzeitpunkt gab es keine auffälligen Einträge.
Bei diesem Auszug wird was von einer doppelten IP erzählt, aber so ganz ohne weiteren Hinweise ist das auch seltsam.

Eine Doppelbelegung ist ausgeschlossen, das betroffene Netz war das allererste jemals aufgesetzte und wurde seither nicht mehr angepackt.

2019:12:02-10:02:45 hq-1 dns-resolver[15327]: No change to REF_NetDnsIPrep3t :: iprep3.t.ctmail.com
2019:12:02-10:02:46 hq-1 ulogd[16792]: ulogd running
2019:12:02-10:03:01 hq-1 /usr/sbin/cron[17127]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:03:45 hq-1 dns-resolver[15327]: Updating REF_NetDnsIPrep3t :: iprep3.t.ctmail.com
2019:12:02-10:04:01 hq-1 /usr/sbin/cron[18306]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:05:01 hq-2 /usr/sbin/cron[9669]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:05:01 hq-2 /usr/sbin/cron[9668]: (root) CMD (/usr/local/bin/create_rrd_graphs.plx --mode daily,weekly,monthly,yearly --type sandstorm_combined,sandstorm_web,sandstorm_email)
2019:12:02-10:05:01 hq-1 /usr/sbin/cron[19603]: (root) CMD (/usr/local/bin/create_rrd_graphs.plx --mode daily,weekly,monthly,yearly --type sandstorm_combined,sandstorm_web,sandstorm_email)
2019:12:02-10:05:01 hq-1 /usr/sbin/cron[19604]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:05:01 hq-1 /usr/sbin/cron[19609]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:05:47 hq-1 dns-resolver[15327]: Updating REF_NetDnsResolver1a :: resolver1.ast.ctmail.com
2019:12:02-10:06:01 hq-1 /usr/sbin/cron[21045]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:07:01 hq-1 /usr/sbin/cron[22070]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:07:49 hq-1 dns-resolver[15327]: Updating REF_NetDnsIPrep4t :: iprep4.t.ctmail.com
2019:12:02-10:07:56 hq-2 syslog-ng[9678]: Configuration reload request received, reloading configuration;
2019:12:02-10:07:56 hq-2 ulogd[16427]: SIGTERM received
2019:12:02-10:07:56 hq-2 ulogd[10748]: ulogd running
2019:12:02-10:08:01 hq-1 /usr/sbin/cron[23306]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:09:01 hq-1 /usr/sbin/cron[24344]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:10:01 hq-1 /usr/sbin/cron[25082]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:10:01 hq-1 /usr/sbin/cron[25088]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2019:12:02-10:10:01 hq-1 /usr/sbin/cron[25093]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:10:01 hq-2 /usr/sbin/cron[10948]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2019:12:02-10:10:01 hq-2 /usr/sbin/cron[10949]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:11:01 hq-1 /usr/sbin/cron[26372]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:11:52 hq-1 dns-resolver[15327]: Updating REF_NetDnsIPrep2t :: iprep2.t.ctmail.com
2019:12:02-10:12:01 hq-1 /usr/sbin/cron[26924]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:12:53 hq-1 dns-resolver[15327]: Updating REF_NetDnsIPrep3t :: iprep3.t.ctmail.com
2019:12:02-10:13:01 hq-1 /usr/sbin/cron[27718]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:14:01 hq-2 /usr/sbin/cron[11420]: (root) CMD (/usr/local/bin/create_rrd_graphs.plx --mode monthly,daily)
2019:12:02-10:14:01 hq-1 /usr/sbin/cron[28341]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:15:01 hq-1 /usr/sbin/cron[28797]: (root) CMD ( /usr/local/bin/rpmdb_backup )
2019:12:02-10:15:01 hq-1 /usr/sbin/cron[28809]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:15:01 hq-1 /usr/sbin/cron[28811]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:15:01 hq-2 /usr/sbin/cron[11804]: (root) CMD ( /usr/local/bin/rpmdb_backup )
2019:12:02-10:15:01 hq-2 /usr/sbin/cron[11803]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:15:55 hq-1 dns-resolver[15327]: Updating REF_NetDnsResolver4a :: resolver4.ast.ctmail.com
2019:12:02-10:16:01 hq-1 /usr/sbin/cron[29500]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:16:01 hq-1 /usr/sbin/cron[29506]: (root) CMD (/usr/local/bin/create_rrd_graphs.plx --mode monthly,daily)
2019:12:02-10:16:34 hq-2 ntpd[22718]: Deleting interface #21 lag0.1000, 10.16.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=21907 secs
2019:12:02-10:16:35 hq-1 ntpd[17179]: Deleting interface #18 lag0.1000, 10.16.0.1#123, interface stats: received=2168, sent=2168, dropped=0, active_time=21907 secs
2019:12:02-10:16:39 hq-2 ntpd[22718]: Listen normally on 60 lag0.1000 10.16.0.1:123
2019:12:02-10:16:39 hq-2 ntpd[22718]: new interface(s) found: waking up resolver
2019:12:02-10:16:42 hq-1 ntpd[17179]: Listen normally on 62 lag0.1000 10.16.0.1:123
2019:12:02-10:16:42 hq-1 ntpd[17179]: new interface(s) found: waking up resolver
2019:12:02-10:16:44 hq-2 snmpd[20209]: Received TERM or STOP signal... shutting down...
2019:12:02-10:16:46 hq-2 snmpd[17189]: NET-SNMP version 5.7.3
2019:12:02-10:16:47 hq-1 snmpd[10728]: Received TERM or STOP signal... shutting down...
2019:12:02-10:16:48 hq-1 snmpd[1766]: Duplicate IPv4 address detected, some interfaces may not be visible in IP-MIB
2019:12:02-10:16:48 hq-1 snmpd[2085]: NET-SNMP version 5.7.3
2019:12:02-10:16:54 hq-2 snmpd[17189]: Received TERM or STOP signal... shutting down...
2019:12:02-10:16:55 hq-2 snmpd[22045]: NET-SNMP version 5.7.3
2019:12:02-10:16:56 hq-1 dns-resolver[15327]: Updating REF_NetDnsResolver5a :: resolver5.ast.ctmail.com
2019:12:02-10:17:01 hq-2 /usr/sbin/cron[25644]: (root) CMD ( nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2019:12:02-10:17:01 hq-1 snmpd[2085]: Received TERM or STOP signal... shutting down...
2019:12:02-10:17:01 hq-1 /usr/sbin/cron[7497]: (root) CMD (/sbin/audld.plx --trigger)
2019:12:02-10:17:01 hq-1 /usr/sbin/cron[7498]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:17:01 hq-1 /usr/sbin/cron[7512]: (root) CMD ( nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2019:12:02-10:17:05 hq-1 snmpd[7341]: Duplicate IPv4 address detected, some interfaces may not be visible in IP-MIB
2019:12:02-10:17:08 hq-1 snmpd[9034]: NET-SNMP version 5.7.3
2019:12:02-10:18:01 hq-1 /usr/sbin/cron[31836]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:19:01 hq-2 /usr/sbin/cron[14393]: (root) CMD (/var/chroot-http/usr/bin/run-two -w -l /var/run/ad-sid-sync.lock /var/chroot-http/usr/bin/ad-sid-sync.plx full >/dev/null 2>&1)
2019:12:02-10:19:01 hq-1 /usr/sbin/cron[1590]: (root) CMD (/var/chroot-http/usr/bin/run-two -w -l /var/run/ad-sid-sync.lock /var/chroot-http/usr/bin/ad-sid-sync.plx full >/dev/null 2>&1)
2019:12:02-10:19:01 hq-1 /usr/sbin/cron[1591]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:19:59 hq-1 dns-resolver[15327]: Updating REF_NetDnsResolver1a :: resolver1.ast.ctmail.com
2019:12:02-10:20:01 hq-2 /usr/sbin/cron[14496]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2019:12:02-10:20:01 hq-2 /usr/sbin/cron[14497]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:20:01 hq-1 /usr/sbin/cron[2613]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:20:01 hq-1 /usr/sbin/cron[2615]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2019:12:02-10:20:01 hq-1 /usr/sbin/cron[2616]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:21:01 hq-1 /usr/sbin/cron[3443]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:22:01 hq-1 /usr/sbin/cron[4278]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:23:02 hq-1 /usr/sbin/cron[5217]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:24:01 hq-1 /usr/sbin/cron[6369]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:25:01 hq-1 dns-resolver[15327]: Updating REF_NetDnsResolver1a :: resolver1.ast.ctmail.com
2019:12:02-10:25:01 hq-2 /usr/sbin/cron[15261]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:25:01 hq-1 /usr/sbin/cron[7427]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2019:12:02-10:25:01 hq-1 /usr/sbin/cron[7429]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:26:01 hq-1 /usr/sbin/cron[8704]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:26:02 hq-1 dns-resolver[15327]: Updating REF_NetDnsIPrep4t :: iprep4.t.ctmail.com
2019:12:02-10:27:01 hq-1 /usr/sbin/cron[9824]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2019:12:02-10:27:55 hq -- MARK --
Cancel
Vote Up 0 Vote Down

Cancel
0 Bernhard Kanduth over 4 years ago

Hallo, ich hänge mich hier auch mal ran, denn meine UTM hat sich heute zum zweiten mal verabschiedet und kommt nicht mehr online, musste den Stecker ziehen.

Folgendes findet sich in den Logs:

Firewall:

2019:12:03-01:53:35 Firewall ulogd[3995]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="10:5a:f7:7f:c4:c1" dstmac="00:1a:8c:4c:0c:91" srcip="193.83.xxx.xxx" dstip="91.xxx.xxx.xxx" proto="6" length="60" tos="0x00" prec="0x00" ttl="56" srcport="44037" dstport="4433" tcpflags="SYN"

��2019:12:03-06:25:51 kanwall ulogd[5514]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="10:5a:f7:7f:c4:c1" dstmac="00:1a:8c:4c:0c:91" srcip="78.1xx.1xx.xx" dstip="91.xxx.xxx.xxx" proto="6" length="60" tos="0x00" prec="0x00" ttl="55" srcport="49220" dstport="4433" tcpflags="SYN"

Web:

2019:12:03-01:53:35 Firewall httpproxy[20379]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="CONNECT" srcip="192.1xx.xx.xx" dstip="52.xx.xxx.xx" user="" group="" ad_domain="" statuscode="200" cached="0" profile="REF_DefaultHTTPProfile (Default Web Filter Profile)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="4399" request="0xbfa00300" url="_hidden_" referer="" error="" authtime="0" dnstime="17347" aptptime="224" cattime="0" avscantime="0" fullreqtime="136167" device="0" auth="0" ua="" exceptions="fileextension" application="bdefnder" app-id="49"

��2019:12:03-06:25:52 Firewall httpproxy[6131]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="main" file="httpproxy.c" line="286" message="reading configuration"

Würde mich interessieren, ob es vermehrte Vorfälle dieser Art gibt?

mfg

Bernhard
Cancel
Vote Up 0 Vote Down

Cancel
0 Patrick Lachmann over 4 years ago in reply to Bernhard Kanduth

Ähm, das ist scheinbar ein komplett anderes Problem.

Der lesbare Logteil sieht normal aus, aber woher ist die Grütze?

Ich würde da mal eher in die Systemlogs sehen sowie das Verabschieden genauer beschreiben.

EDIT:

Wenn die Grütze original in den Logfiles steht, sieht das nach einem Absturz (und nicht geschlossenen bzw. fertiggeschriebenen Files) aus.
Dann erst Recht in die System/Kernellogs sehen.
Cancel
Vote Up 0 Vote Down

Cancel

0 Bernhard Kanduth over 4 years ago in reply to Patrick Lachmann

Hallo,

danke für die Info, anbei die Logs

System Log:

2019:12:03-01:51:31 Firewall dns-resolver[5083]: No change to REF_NetDnsOutlookoff :: outlook.office365.com
2019:12:03-01:51:31 Firewall dns-resolver[5083]: No change to REF_NetDnsClashofcla :: game.clashofclans.com
2019:12:03-01:52:33 Firewall dns-resolver[5083]: Updating REF_NetDnsOutlookoff :: outlook.office365.com
2019:12:03-01:52:33 Firewall dns-resolver[5083]: No change to REF_NetDnsClashofcla :: game.clashofclans.com
2019:12:03-01:52:36 Firewall dns-resolver[5083]: Updating REF_NetDnsMicroSurfaImage :: dl-proc.ds.microsoft.com
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
������������������������������������������������������������������
2019:12:03-06:25:51 Firewall syslog-ng[5537]: syslog-ng starting up; version='3.4.7'

Um 6:25 wurde der Stecker gezogen!

Kernel Log:

Vom Ausfall in der Nacht gibt es keine Eiträge im Logfile, erst  nach dem Start, gegen Mittag ist die Firewall wieder
hängen geblieben, und war offline und auch intern nicht erreichbar, geggen 17:17 erfogte der Neustart.

2019:12:03-06:27:06 Firewall kernel: [  193.201639] tun: Universal TUN/TAP device driver, 1.6
2019:12:03-06:27:06 Firewall kernel: [  193.201644] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
2019:12:03-17:17:33 Firewall kernel: [  110.526490] IPv4: martian destination 0.0.0.0 from 169.254.213.51, dev eth5
2019:12:03-17:17:33 Firewall kernel: [  112.568290] IPv4: martian destination 0.0.0.0 from 169.254.213.51, dev eth5
2019:12:03-17:17:33 Firewall kernel: [  114.625845] IPv4: martian destination 0.0.0.0 from 169.254.213.51, dev eth5
2019:12:03-17:17:33 Firewall kernel: [  116.695414] IPv4: martian destination 0.0.0.0 from 169.254.213.51, dev eth5
2019:12:03-17:17:34 Firewall kernel: [  118.729167] IPv4: martian destination 0.0.0.0 from 169.254.213.51, dev eth5

mlg
Bernhard

+1 Bernhard Kanduth over 4 years ago in reply to Patrick Lachmann

Hallo,

es war offensichtlich ein Hardwaredefekt, die neue Hardware ist bereits unterwegs.

Bernhard
Cancel
Vote Up 0 Vote Down

Cancel
0 Wolfgang Hoess over 4 years ago in reply to Bernhard Kanduth

Hallo,

ich habe seit Freitag genau das gleiche im LOG bei 3 verschiedene Kunden und die UTMs stellen alle paar Stunden den Betrieb ein.

1 UTM wurde getauscht und läuft nun wieder.

Kann aber fast kein Zufall sein das mehrere gleichzeitig einen Hardwaredefekt haben - hat sonst wer dieses Problem?

Gruß

Wolfgang
Cancel
Vote Up 0 Vote Down

Cancel
0 Bernhard Kanduth over 4 years ago in reply to Wolfgang Hoess

Könnte vielleicht damit etwas zu tun haben:

https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/41894-intel-kaempft-mit-fehler-im-atom-c2000.html

mfg

Bernhard
Cancel
Vote Up 0 Vote Down

Cancel
0 papa_ over 4 years ago in reply to Bernhard Kanduth

Damit sind mir reihenweise die SG135 gestorben. Waren aber komplett tot, nicht mal eine BIOS-Meldung beim Einschalten.
Cancel
Vote Up 0 Vote Down

Cancel
0 Wolfgang Hoess over 4 years ago in reply to Bernhard Kanduth

Ok,

danke für die Info.

Würd mich aber aktuelle eher wundern - da es bei uns neue Aktuelle SGs betrifft von 11/19
Cancel
Vote Up 0 Vote Down

Cancel