Firewall Regel greift mal und dann wieder nicht

Hi, besten Dank für den Hinweis.

Die MAC "6E" ist das outside Interface der UTM also im Netz 83.X.X.X direkt am Public-SRV - Hier greift die Regel allow von outside nach 172.x.x.x

Die Mac "5a" ist das Inside Interface der UTM im Netz 172.x.x.x am DC hier kommt der Deny ins Spiel.

Anbei nochmal ein Screenshot, ich hab gerade keine Idee dazu...

Grüße Marco

Hallo,

E0 wird nicht angesprochen. Kennt auch die Source nicht. 

5A sollte die Source auch nicht kennen, tut Sie aber. 

Kann man bitte auf dem Sender die ARP Tables überprüfen? 

Das Konstrukt hier zeigt auf, dass der SRC Server scheinbar unterschiedliche Pakete schickt oder jemand dazwischen. 

ETH6 ist WAN oder DMZ? Ist der SRC Server direkt attached oder übers WAN erreichbar? 

Hallo,

E0 wird nicht angesprochen. Kennt auch die Source nicht. 

5A sollte die Source auch nicht kennen, tut Sie aber. 

Kann man bitte auf dem Sender die ARP Tables überprüfen? 

Das Konstrukt hier zeigt auf, dass der SRC Server scheinbar unterschiedliche Pakete schickt oder jemand dazwischen. 

ETH6 ist WAN oder DMZ? Ist der SRC Server direkt attached oder übers WAN erreichbar? 

Unknown said:

ETH6 ist WAN oder DMZ?

WAN an einem dedizierten Switch, VMNIC7, ETH6 der UTM und ISP Router stecken direkt auf diesem Switch.
Der Public-SRV hat auch nur diese eine NIC

Unknown said:

Kann man bitte auf dem Sender die ARP Tables überprüfen? 

Routen tut das die UTM zwischen "ETH6 Public" und "ETH0 Inside"

(Ich hab dass so nicht gebaut da distanziere ich mich vehement von, das ist ein gewachsenes Konstrukt welches ich erbte :-/ )

Grüße

Noch zur Ergänzung: In meiner Freihandzeichnung hatte ich beim Public-SRV die IP Endung.5 hingemalt das ist die 35 und ETH6 der UTM die .33

Hi,

bist Du dir sicher mit den MAC Adressen der UTM?
Ich bin mir nicht sicher ob als DSTMAC die Adresse des eingehenden Interface steht. Wenn die Firewall die Pakete schon verarbeitet hat, müsste nach meinem Verständnis die DSTMAC die des nächsten Inferface, hier also ETH0 sein, oder?

Kannst Du mal die relevanten Einträge aus dem Firewall Log posten?

Gruß

Jas

Jas Man said:

bist Du dir sicher mit den MAC Adressen der UTM?

Ja bin ich, anbei nochmal Screenshots der UTM Interfaces inkl. Hardware Eigenschaft und ein IPCONFIG /ALL Auszug der SRC & DST Devices.

Das Firewall Log ist das vom ersten Beitrag oder meintest du noch ein anderes Log?

Jas Man said:

Ich bin mir nicht sicher ob als DSTMAC die Adresse des eingehenden Interface steht. Wenn die Firewall die Pakete schon verarbeitet hat, müsste nach meinem Verständnis die DSTMAC die des nächsten Inferface, hier also ETH0 sein, oder?

Exakt so habe ich das auch in Erinnerung und gerade da macht es mich ja so stutzig :-/

Grüße

Hallo,

bitte auf der Shell einmal einen tcpdump auf das eine und das andere Interface durchführen. 

Irgendwie habe ich das Gefühl, dass die Pakete falsch ankommen. Dann besteht ein Routing Problem vom Switch davor. 

tcpdump -ni ethX host IP1 and host IP2 

Das ggf. parallel ausführen. 

Ich meinte die Logs aus den Log Dateien unter Logging & Reporting -> View Log Files. Da öffnest Du den Firewall Log und suchst nach den entsprechenden Einträgen für die IPs (STRG + F). Poste bitte mal ein paar geblockte und ein paar erlaubte Verbindungen.

Der Log zeigt mehr Informationen, u.a. über welches Interface die Pakete eingegangen sind. Alternativ geht auch der von LucaChristmann1 vorgeschlagene TCPDUMP. Aber da müsstest Du ggf. warten bis beide Situationen (geblockt und erlaubt) aufgetreten sind falls es nicht regelmässig passiert.

Gruß

Jas

Hallo zusammen,

ich hab mal exakt die Logs aus der Passage des Screenshots rausgesucht:

2017:05:30-08:40:57 sg001 ulogd[25797]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth0" outitf="eth0" srcmac="00:50:56:b6:6a:15" dstmac="00:1a:8c:5f:72:5a" srcip="83.137.XXX.35" dstip="172.18.1.2" proto="17" length="230" tos="0x00" prec="0x00" ttl="127" srcport="52283" dstport="389"
2017:05:30-08:40:58 sg001 ulogd[25797]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth0" outitf="eth0" srcmac="00:50:56:b6:6a:15" dstmac="00:1a:8c:5f:72:5a" srcip="83.137.XXX.35" dstip="172.18.1.2" proto="6" length="48" tos="0x00" prec="0x00" ttl="127" srcport="64019" dstport="389" tcpflags="SYN"
2017:05:30-08:41:03 sg001 ulogd[25797]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="33" initf="eth6" outitf="eth0" srcmac="00:50:56:b6:6a:15" dstmac="00:1a:8c:5f:84:6e" srcip="83.137.XXX.35" dstip="172.18.1.2" proto="17" length="231" tos="0x00" prec="0x00" ttl="127" srcport="64523" dstport="389"
2017:05:30-08:41:04 sg001 ulogd[25797]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="33" initf="eth6" outitf="eth0" srcmac="00:50:56:b6:6a:15" dstmac="00:1a:8c:5f:84:6e" srcip="83.137.XXX.35" dstip="172.18.1.2" proto="17" length="231" tos="0x00" prec="0x00" ttl="127" srcport="50164" dstport="389"

Daraus erschliesst sich mir aber immer noch nicht warum die Pakete einmal am ETH0 und einmal am ETH6 landen.

Danke und Güße
Marco

Hallo,

wie vermutet kommen die Interface falsch an. Das ist dein Switch bzw. der Virtuelle Switch vor der Appliance (VMware). 

Hier existiert eine Fehlkonfiguration. Dieses Paket von der SRC IP mit der DST IP darf nicht auf beiden Interfacen aufschlagen. 

Im Dump würde man ähnliches sehen. 

Die Appliance agiert hier korrekt und blockiert Pakete auf falschen Interfacen. 

Würde mir daher mal die Switch bzw. Vmware Config des Virtuellen Switches angucken. 

Yep, den VMswitch hatte ich auch schon in Verdacht. Da die SRCMAC gleich bleibt, vermute ich irgendeine HA Funktion in der VMWARE.

Oder irgendeine Brücke. Das müsste sich dann aber auch auf andere VMs auswirken.

Gruß

Jas

Besten Dank erstmal bis hier hin allen die mitgewirkt haben. 

Ich werde mir erstmal eine komplette Zeichnung des physikalischen Gesamtkonstrukts machen und die Wege analysieren, danach überprüfe ich die Konfiguration der Switche und vSwitche so wie die vMware HA Konfiguration.

Sobald der Fehler behoben ist werde ich es hier nochmal als Lösung mitteilen.

Grüße