1
German - Deutsch / Re: An API exception occured
« on: April 15, 2019, 06:19:24 pm »
Unter Services: IGMP Proxy ist die Meldung seit 19.1.6 weg, dort wirkt der Fix.
Gruss, Stefan
Gruss, Stefan
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
German - Deutsch / Re: Creating resolv.conf alle 15 min
« on: April 10, 2019, 07:08:14 pm »
Hallo Julian,
sieht hier ähnlich aus, ebenfalls mit init7:
Ist das überhaupt ein Problem? Funktioniert alles einwandfrei.
Gruss, Stefan
sieht hier ähnlich aus, ebenfalls mit init7:
Code: [Select]
root@OPNsense:~ # cat /var/log/system.log | grep dhc
[ ]
Apr 10 18:25:37 OPNsense dhclient: Creating resolv.conf
Apr 10 18:25:37 OPNsense dhclient[53161]: bound to XXX.XXX.XXX.XXX -- renewal in 900 seconds.
Apr 10 18:37:42 OPNsense dhcp6c[6317]: Sending Renew
Apr 10 18:37:42 OPNsense dhcp6c[6317]: unknown or unexpected DHCP6 option server unicast, len 16
Apr 10 18:37:42 OPNsense dhcp6c[6317]: Received REPLY for RENEW
Apr 10 18:37:42 OPNsense dhcp6c[6317]: status code for PD-0: success
Apr 10 18:40:37 OPNsense dhclient[53161]: DHCPREQUEST on igb0 to XXX.XXX.XXX.XXX port XX
Apr 10 18:40:37 OPNsense dhclient[53161]: DHCPACK from XXX.XXX.XXX.XXX
Apr 10 18:40:37 OPNsense dhclient: Creating resolv.conf
Ist das überhaupt ein Problem? Funktioniert alles einwandfrei.
Gruss, Stefan
3
German - Deutsch / Re: Suricata will nicht mit URLhaus?
« on: April 10, 2019, 10:44:32 am »
Jetzt geht es auf einmal. An was es genau lag weiss ich nicht.
In jedem Fall muss man nach einer Konfigänderungen immer schön geduldig warten, bis folgendes im LOG auftaucht:
URLhaus greift nicht auf WAN, sondern nur auf dem Interface auf welchem die URL aufgerufen wird, bei mir IGB1.
Was mir auch noch aufgefallen ist: Bei Konfigänderungen haut es auf meiner Box oft die WAN-IP raus. Das Gateway ist dann offline. Nur IPv4, die IPv6 überlebt's. Das passiert aber auch ca. bei jedem dritten Neustart. Auch schon vor aktiviertem Suricata.
Konfiguration als Referenz:
Interfaces: Settings
Services: Intrusion Detection: Administration
In jedem Fall muss man nach einer Konfigänderungen immer schön geduldig warten, bis folgendes im LOG auftaucht:
Code: [Select]
suricata: [100145] <Notice> -- all [X] packet processing threads, [X] management threads initialized, engine started.Und nach einer Regeländerung:Code: [Select]
suricata: [100145] <Notice> -- rule reload startingURLhaus greift nicht auf WAN, sondern nur auf dem Interface auf welchem die URL aufgerufen wird, bei mir IGB1.
Was mir auch noch aufgefallen ist: Bei Konfigänderungen haut es auf meiner Box oft die WAN-IP raus. Das Gateway ist dann offline. Nur IPv4, die IPv6 überlebt's. Das passiert aber auch ca. bei jedem dritten Neustart. Auch schon vor aktiviertem Suricata.
Konfiguration als Referenz:
Interfaces: Settings
| Hardware CRC | [X] Disable |
| Hardware TSO | [X] Disable |
| Hardware LRO | [X] Disable |
| VLAN Hardware Filtering | [Disable VLAN Hardware Filtering] (Wenn VLAN im Einsatz) |
Services: Intrusion Detection: Administration
| Enabled | [X] |
| IPS mode | [X] |
| Promiscuous mode | [X] (Wenn VLAN im Einsatz) |
| Pattern matcher | [Hyperscan] |
| Interfaces | [IGB1, WAN] |
| Home networks | [private IPv6-Netzwerke zusätzlich eintragen] |
4
German - Deutsch / Re: Suricata will nicht mit URLhaus?
« on: April 09, 2019, 01:02:35 pm »
Vielen Dank, chemlud.
Hab’s jetzt noch mit Aho-Corasick versucht. Verhält sich genau gleich.
Irgendwelche Ideen an was das liegen könnte oder wie ich der Ursache auf die Spur kommen könnte?
Hab’s jetzt noch mit Aho-Corasick versucht. Verhält sich genau gleich.
Irgendwelche Ideen an was das liegen könnte oder wie ich der Ursache auf die Spur kommen könnte?
5
German - Deutsch / Re: An API exception occured
« on: April 09, 2019, 09:34:45 am »
Hey franco, ich zumindest konnte gar nicht anders denken, weil mir hierzu das nötige Hintergrundwissen fehlte. 
Aber vielen Dank für die Info, schon wieder was über PHP gelernt.
Aber vielen Dank für die Info, schon wieder was über PHP gelernt.
6
German - Deutsch / Re: An API exception occured
« on: April 08, 2019, 07:10:16 pm »
Oh, das erklärt dann wohl auch folgende Meldung unter Services: IGMP Proxy?
Code: [Select]
Warning: count(): Parameter must be an array or an object that implements Countable in /usr/local/www/services_igmpproxy.php on line 121
7
German - Deutsch / [Solved] Suricata will nicht mit URLhaus?
« on: April 08, 2019, 07:08:17 pm »
Hallo Leute,
ich beschäftige mich gerade zum ersten Mal mit Suricata auf einer APU2 von PC Engines mit OPNsense 19.1.5_1 drauf.
Der Test mit dem Regelset OPNsense-App-detect/test funktioniert (WAN, Hyperscan, IPS, Alert und Drop). Die Eicar-Signatur wird erkannt, blockiert und unter Alarms erscheint ein entsprechender Eintrag.
Wenn ich das Regelset abuse.ch/URLhaus aktiviere und nach dem rule reload complete eine verseuchte Datei herunterlade (z. B. https://urlhaus.abuse.ch/url/1227/), dann wird diese URL vom IPS durchgelassen und es erscheint kein Eintrag unter Alarms.
Ich habe es auch mal nur im IDS-Modus und mit der LAN-Schnittstelle (IGB1) im promiscuous mode (wegen VLANs) versucht. Verhält sich auch nicht anders.
Funktioniert bei euch Suricata mit URLhaus?
Nach einem Reboot steht folgendes im Log:
ich beschäftige mich gerade zum ersten Mal mit Suricata auf einer APU2 von PC Engines mit OPNsense 19.1.5_1 drauf.
Der Test mit dem Regelset OPNsense-App-detect/test funktioniert (WAN, Hyperscan, IPS, Alert und Drop). Die Eicar-Signatur wird erkannt, blockiert und unter Alarms erscheint ein entsprechender Eintrag.
Wenn ich das Regelset abuse.ch/URLhaus aktiviere und nach dem rule reload complete eine verseuchte Datei herunterlade (z. B. https://urlhaus.abuse.ch/url/1227/), dann wird diese URL vom IPS durchgelassen und es erscheint kein Eintrag unter Alarms.
Ich habe es auch mal nur im IDS-Modus und mit der LAN-Schnittstelle (IGB1) im promiscuous mode (wegen VLANs) versucht. Verhält sich auch nicht anders.
Funktioniert bei euch Suricata mit URLhaus?
Nach einem Reboot steht folgendes im Log:
Code: [Select]
suricata: [100237] <Notice> -- all 5 packet processing threads, 4 management threads initialized, engine started.
suricata: [100237] <Warning> -- [ERRCODE: SC_WARN_DEFAULT_WILL_CHANGE(317)] - in 5.0 the default for decoder event stats will go from 'decoder.<proto>.<event>' to 'decoder.event.<proto>.<event>'. See ticket #2225. To suppress this message, set stats.decoder-events-prefix in the yaml.
suricata: [100135] <Notice> -- This is Suricata version 4.1.3 RELEASE
8
German - Deutsch / Re: Firewall "härten"
« on: April 07, 2019, 11:51:09 am »
Jetzt wo ich meine Zusammenfassung nochmals lese: ja, ist ziemlich verworren das Ganze. Sorry, dass ich dich zum Seufzen bringe, JeGr. 
Und ein herzliches Dankeschön für deine Zeit und Geduld.
Schwamm drüber und aus die Maus mit "härten". Rein nach dem Motto:
"Historically, ICMP has a bad reputation but it is generally beneficial and does not deserve the reputation on modern networks. Allowing an ICMP type of any is typically acceptable when allowing ICMP."
https://docs.netgate.com/pfsense/en/latest/book/firewall/configuring-firewall-rules.html
Und falls noch andere ICMP-Noobs wie ich hier mitlesen und eine Vorlage wünschen, hier bitte sehr:
Ich mach das jetzt so wie seit eh und je plus neu lasse ich auf dem WAN-Interface gewisse ICMP-Typen rein:
ICMP+ICMPv6-LAN-Regeln
ICMP-WAN-Regeln
ICMPv6-WAN-Regeln gem. https://tools.ietf.org/html/rfc4890#section-4.3
*1) Sofern man nicht will, dass lokal alles überallhin pingen kann, z. B. im Gästenetz und in der DMZ.
*2) Ob diese Regeln nötig sind oder durch das "state keeping" abgedeckt sind, kann ich immer noch nicht abschätzen. Zumindest die ICMPv6-Echo-Reply-Regel dürfte nicht viel bringen.
Beispielsweise ein IPv6-Test mit http://ipv6-test.com/ ergibt auch nur mit zugelassenem Echo Request die volle Punktzahl.
*3) Bei den ICMPv6-WAN-Regeln würde noch Packet Too Big (Type 2) dazu gehören, aber das steht bei OPNsense momentan nicht zur Verfügung. Das dürfte aber nicht tragisch sein, denn Type 2 (wie auch Type 1 Destination Unreachable) ist standardmässig frei gegeben, sofern ich die erste der folgenden Regeln richtig interpretiere:
Und ein herzliches Dankeschön für deine Zeit und Geduld.Schwamm drüber und aus die Maus mit "härten". Rein nach dem Motto:
"Historically, ICMP has a bad reputation but it is generally beneficial and does not deserve the reputation on modern networks. Allowing an ICMP type of any is typically acceptable when allowing ICMP."
https://docs.netgate.com/pfsense/en/latest/book/firewall/configuring-firewall-rules.html
Und falls noch andere ICMP-Noobs wie ich hier mitlesen und eine Vorlage wünschen, hier bitte sehr:
Ich mach das jetzt so wie seit eh und je plus neu lasse ich auf dem WAN-Interface gewisse ICMP-Typen rein:
ICMP+ICMPv6-LAN-Regeln
| Pass, | LAN, | IPv4, | ICMP, | Echo Request, | Source: LAN net, | Destination: LAN address *1 |
| Block, | LAN, | IPv4, | ICMP, | Echo Request, | Source: LAN net, | Destination: RFC 1918 *1 |
| Block, | LAN, | IPv6, | ICMP, | Echo Request, | Source: LAN net, | Destination: RFC 1918 *1 |
| Pass, | LAN, | IPv4+6, | ICMP, | any, | Source: LAN net, | Destination: any |
ICMP-WAN-Regeln
| Pass, | WAN, | IPv4, | ICMP, | Echo Request, | Source: any, | Destination: WAN address |
| Pass, | WAN, | IPv4, | ICMP, | Destination Unreachable, | Source: any, | Destination: WAN address *2 |
| Pass, | WAN, | IPv4, | ICMP, | Time Exceeded, | Source: any, | Destination: WAN address *2 |
ICMPv6-WAN-Regeln gem. https://tools.ietf.org/html/rfc4890#section-4.3
| Pass, | WAN, | IPv6, | ICMP, | Destination Unreachable, | Source: any, | Destination: WAN address *2 |
| Pass, | WAN, | IPv6, | ICMP, | Packet Too Big, | Source: any, | Destination: WAN address *3 |
| Pass, | WAN, | IPv6, | ICMP, | Time Exceeded, | Source: any, | Destination: WAN address *2 |
| Pass, | WAN, | IPv6, | ICMP, | Parameter Problem, | Source: any, | Destination: WAN address *2 |
| Pass, | WAN, | IPv6, | ICMP, | Echo Request, | Source: any, | Destination: WAN address |
| Pass, | WAN, | IPv6, | ICMP, | Echo Reply, | Source: any, | Destination: WAN address *2 |
*1) Sofern man nicht will, dass lokal alles überallhin pingen kann, z. B. im Gästenetz und in der DMZ.
*2) Ob diese Regeln nötig sind oder durch das "state keeping" abgedeckt sind, kann ich immer noch nicht abschätzen. Zumindest die ICMPv6-Echo-Reply-Regel dürfte nicht viel bringen.
Beispielsweise ein IPv6-Test mit http://ipv6-test.com/ ergibt auch nur mit zugelassenem Echo Request die volle Punktzahl.
*3) Bei den ICMPv6-WAN-Regeln würde noch Packet Too Big (Type 2) dazu gehören, aber das steht bei OPNsense momentan nicht zur Verfügung. Das dürfte aber nicht tragisch sein, denn Type 2 (wie auch Type 1 Destination Unreachable) ist standardmässig frei gegeben, sofern ich die erste der folgenden Regeln richtig interpretiere:
Code: [Select]
root@OPNsense:~ # cat /tmp/rules.debug | grep ipv6-icmp
pass in log quick inet6 proto ipv6-icmp from {any} to {any} icmp6-type {1,2,135,136} keep state label "IPv6 requirements (ICMP)"
pass out log quick inet6 proto ipv6-icmp from {(self)} to {fe80::/10,ff02::/16} icmp6-type {129,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {fe80::/10} to {fe80::/10,ff02::/16} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {ff02::/16} to {fe80::/10} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
9
German - Deutsch / Re: Firewall "härten"
« on: April 01, 2019, 04:46:26 pm »
Ich versuche mich mal mit folgender Zusammenfassung:
- Man muss sich bei der Sense nicht um ICMP-Firewallregeln kümmern, weil sich das "state keeping" um alles Nötige kümmert. (Erlaubte, aufbauende Verbindungen erhalten allfällige ICMP-Antworten in jedem Fall.)
- Einzige Ausnahmen sind "Echo request" zulassen, wenn ein Interface oder etwas in einem Netz pingbar sein soll und "ICMPv6 Router Advertisement" + "ICMPv6 Router Solicitation" zulassen, wenn IPv6 im Einsatz ist.
- Die generelle Empfehlung (u. A. vom BSI) "ICMP redirect" ausgehend zu blocken, wird von der Sense per "tunables" umgesetzt. (Allerdings erst ab 19.1.3: https://forum.opnsense.org/index.php?topic=11941.msg54462#msg54462
Ich musste unter System: Settings: Tunables noch auf Default klicken, damit dieses tunable angezeigt wurde.) - ICMP kann per Firewallregeln nicht geblockt werden.
10
German - Deutsch / Re: Firewall "härten"
« on: March 27, 2019, 03:20:54 pm »
Oh, ich bin jetzt gerade noch über diesen Thread hier gestolpert:
https://forum.opnsense.org/index.php?topic=8736.msg38955#msg38955
Wenn ich das richtig verstanden habe und die Analyse von @indyspeed stimmt, dann sind zumindest meine abgehenden Regeln eh für die Katz.
https://forum.opnsense.org/index.php?topic=8736.msg38955#msg38955
Wenn ich das richtig verstanden habe und die Analyse von @indyspeed stimmt, dann sind zumindest meine abgehenden Regeln eh für die Katz.
11
German - Deutsch / Re: Firewall "härten"
« on: March 27, 2019, 03:05:04 pm »
> Auf dem WAN würde ich Echo Request noch erlauben.
Für welchen Verwendungszweck? Die einzige Idee, die mir in den Sinn kommt, ist dass ich auf dem WAN-Interface nach Innen Pingen könnte und das will/brauch ich eigentlich nicht?
> Destination any würde nur etwas bringen, wenn du public IPs bspw. in einer DMZ oder so noch hättest, ansonsten würde ich das auf WAN Address oder This Firewall einschränken.
"Normale Rechner" im Netz profitieren davon nicht? Ich bin unsicher wie das BSI das genau meint. Eigentlich habe ich das so interpretiert, dass man Typ 3 und 11 komplett auf alle Rechner durchlassen darf/soll.
> Auf dem LAN: wenn du vorher explizit RFC1918 wegfilters durch Blocks und Passes, kannst du dahinter eigentlich "any" nutzen
Sorry, aber ich verstehe nicht was du meinst. Gibt es eine elegantere/bessere Lösung?
Für welchen Verwendungszweck? Die einzige Idee, die mir in den Sinn kommt, ist dass ich auf dem WAN-Interface nach Innen Pingen könnte und das will/brauch ich eigentlich nicht?
> Destination any würde nur etwas bringen, wenn du public IPs bspw. in einer DMZ oder so noch hättest, ansonsten würde ich das auf WAN Address oder This Firewall einschränken.
"Normale Rechner" im Netz profitieren davon nicht? Ich bin unsicher wie das BSI das genau meint. Eigentlich habe ich das so interpretiert, dass man Typ 3 und 11 komplett auf alle Rechner durchlassen darf/soll.
> Auf dem LAN: wenn du vorher explizit RFC1918 wegfilters durch Blocks und Passes, kannst du dahinter eigentlich "any" nutzen
Sorry, aber ich verstehe nicht was du meinst. Gibt es eine elegantere/bessere Lösung?
12
German - Deutsch / Re: IPv6: Wie kann man den aktuellen Präfix in Firewall-Regeln referenzieren?
« on: March 27, 2019, 12:16:03 pm »
Ich weiss nicht ob ich IPv6 als "richtig" bezeichnen will, wenn es NUR mit dynamischen Präfixen ausgeliefert wird. Das sieht mir eher nach von ISP-Marketingabteilungen kaputt gemacht aus. Aber um das soll sich die Diskussion hier nicht drehen.
Ist auf franco’s "long-term TODO list":
https://forum.opnsense.org/index.php?topic=9773.msg44620#msg44620
Wie sieht das eigentlich bei der Konkurrenz aus? Gibt es gut funktionierende Lösungen für diesen Anwendungsfall?
Ist auf franco’s "long-term TODO list":
https://forum.opnsense.org/index.php?topic=9773.msg44620#msg44620
Wie sieht das eigentlich bei der Konkurrenz aus? Gibt es gut funktionierende Lösungen für diesen Anwendungsfall?
13
German - Deutsch / Re: IPv6: Wie kann man den aktuellen Präfix in Firewall-Regeln referenzieren?
« on: March 26, 2019, 07:06:14 pm »
Also kann man die Aussage wagen: Sobald mehrere Subnetze im Einsatz sind, dann ist "richtiges" IPv6 Pflicht? (Ausser man will basteln oder nur IPv4 verwenden.)
Man sollte die ISPs verpflichten, dass zumindest auf Anfrage ein statisches Präfix zur Verfügung gestellt werden muss. Und das kostenlos und nicht nur bei "Business-Anschlüssen". Hätte man gleich in den Standard mit einbauen sollen und bei Zuwiderhandlung muss der Laden schliessen oder so.
Man sollte die ISPs verpflichten, dass zumindest auf Anfrage ein statisches Präfix zur Verfügung gestellt werden muss. Und das kostenlos und nicht nur bei "Business-Anschlüssen". Hätte man gleich in den Standard mit einbauen sollen und bei Zuwiderhandlung muss der Laden schliessen oder so.
14
German - Deutsch / Re: Firewall "härten"
« on: March 26, 2019, 06:42:30 pm »
Vielen Dank, soweit begriffen. Sind folgende Regeln für die Umsetzung korrekt? Nur mal IPv4.
*Oder Destination irgendwie einschränken?
*Sofern ich nicht will, dass lokal alles überallhin pingen kann.
| Pass, | WAN, | IPv4, | ICMP, | Destination Unreachable, | Source: any, | Destination: any* |
| Pass, | WAN, | IPv4, | ICMP, | Time Exceeded, | Source: any, | Destination: any* |
| Pass, | LAN, | IPv4, | ICMP, | Echo request, | Source: LAN net, | Destination: LAN address |
| Block, | LAN, | IPv4, | ICMP, | Echo request, | Source: LAN net, | Destination: RFC 1918* |
| Pass, | LAN, | IPv4, | ICMP, | any, | Source: LAN net, | Destination: RFC 1918 |
| Pass, | LAN, | IPv4, | ICMP, | Echo request, | Source: LAN net, | Destination: ! RFC 1918 |
| Pass, | LAN, | IPv4, | ICMP, | Destination Unreachable, | Source: LAN net, | Destination: ! RFC 1918 |
| Pass, | LAN, | IPv4, | ICMP, | Time Exceeded, | Source: LAN net, | Destination: ! RFC 1918 |
15
German - Deutsch / Re: Firewall "härten"
« on: March 26, 2019, 11:53:17 am »
> Warum Kompromiss? Von außen mit v4 echoreq, timex, squench, unreach aufmachen IST ja "was gebraucht wird". Mehr brauchts nicht. Intern dann ggf. alles (oder viel) aufzumachen sehe ich als kein Problem an [ ]
Ich glaube ich hab’s jetzt begriffen (bitte nicht hauen und nicht lachen, ich sehe mich immer noch als Netzwerkanfänger): Bei den Empfehlungen in all den verlinkten Artikeln geht es immer nur um die Schnittstelle zwischen internem und externem Netz. Beim BSI ist das schön verständlich beschrieben, finde ich:
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m05/m05120.html
In diesem Artikel wird für öffentliche Server in der DMZ ebenfalls Source Quench (Typ 4) ankommend zulassen empfohlen. Gemäss Wikipedia (und OPNsens-WebGUI) ist das veraltet.
"Since research suggested that "ICMP Source Quench [was] an ineffective (and unfair) antidote for congestion",[9] routers' creation of source quench messages was deprecated in 1995 by RFC 1812. Furthermore, forwarding of and any kind of reaction to (flow control actions) source quench messages was deprecated from 2012 by RFC 6633."
Quelle: https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Source_quench
>>> Time Exceeded tritt bei nem normalen Ping ja eigentlich eher selten auf.
>> Ist es nicht so, dass wenn ich ICMP Time Exceeded blocke, ein Traceroute nicht funktionieren dürfte?
>Mein Fehler, natürlich beim Traceroute bei der TTL. Genau, deshalb "timex" von außen erlaubt.
Ich war/bin verwirrt, weil ein Traceroute intern funktioniert (Host von einem VLAN auf Host in einem anderen VLAN), auch wenn ich ICMP Time Exceeded zu Testzwecken explizit blocke. Darum auch ich die Frage, ob die Sense standardmässig gewisse Dinge durchlässt. Allerdings sollte sie das ja spätestens bei einem expliziten Block nicht mehr tun, vermute ich jetzt mal.
Ich glaube ich hab’s jetzt begriffen (bitte nicht hauen und nicht lachen, ich sehe mich immer noch als Netzwerkanfänger): Bei den Empfehlungen in all den verlinkten Artikeln geht es immer nur um die Schnittstelle zwischen internem und externem Netz. Beim BSI ist das schön verständlich beschrieben, finde ich:
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m05/m05120.html
In diesem Artikel wird für öffentliche Server in der DMZ ebenfalls Source Quench (Typ 4) ankommend zulassen empfohlen. Gemäss Wikipedia (und OPNsens-WebGUI) ist das veraltet.
"Since research suggested that "ICMP Source Quench [was] an ineffective (and unfair) antidote for congestion",[9] routers' creation of source quench messages was deprecated in 1995 by RFC 1812. Furthermore, forwarding of and any kind of reaction to (flow control actions) source quench messages was deprecated from 2012 by RFC 6633."
Quelle: https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Source_quench
>>> Time Exceeded tritt bei nem normalen Ping ja eigentlich eher selten auf.
>> Ist es nicht so, dass wenn ich ICMP Time Exceeded blocke, ein Traceroute nicht funktionieren dürfte?
>Mein Fehler, natürlich beim Traceroute bei der TTL. Genau, deshalb "timex" von außen erlaubt.
Ich war/bin verwirrt, weil ein Traceroute intern funktioniert (Host von einem VLAN auf Host in einem anderen VLAN), auch wenn ich ICMP Time Exceeded zu Testzwecken explizit blocke. Darum auch ich die Frage, ob die Sense standardmässig gewisse Dinge durchlässt. Allerdings sollte sie das ja spätestens bei einem expliziten Block nicht mehr tun, vermute ich jetzt mal.