Onderwerp: Watchguard ARP Cache overflow

Goedenavond,

Even een pop-quiz-hotshot momentje voor de fanatieke WHT figuren.

Na aanschaf van een Watchguard Firebox X750e doen zich timeouts voor in de verbinding van buitenaf naar ons netwerk... Op een willekeurig moment is/zijn een/de server(s) niet bereikbaar van buitenaf.
Servers staan in EvoSwitch: router -> firebox -> switch -> servers

Het probleem is 'hoogstwaarschijnlijk' een ARP CACHE OVERFLOW van de Firebox. Na uren lang wachten (NL -> AZIE werkt niet met tijdverschil) en antwoorden op wat basic vragen, kwam support zelf met de opmerking This seems to be the issue related to ARP cache. In Drop-in mode chances of getting the Arp cache is high.

Vervolgens volgen wat replies en reply-replies, gaat er een week voorbij, zonder resultaat. Nu ik dit type, realiseer ik me pas dat na een week 'chatten' de enige concrete aanbeveling van WG support is geweest: verander de default gateway van het hduige adres naar het ipadres van de firebox om te testen, en laat weten of het werkt...

Dit zonder resultaat, waarop een verzoek volgde van een allowed-packets capture van de traffic monitor (waar zij overigens zelf ook in kunnen snuffelen inmiddels). Deze is inmiddels aangeboden en ik wacht nu op een reply.

Een eerder ingezonden log (tshark) bevatte echter de volgende regeltjes:

Code:

5222	7.781610	Dell_aa:aa:aa	Dell_bb:bb:bb	ARP	Who has x.x.x.200?  Tell x.x.x.204
5223	7.781619	Dell_bb:bb:bb	Dell_aa:aa:aa	ARP	x.x.x.200 is at 00:18:8b:bb:bb:bb
5695	42.924248	Dell_bb:bb:bb	Watchgua_cc:cc:cc	ARP	Who has x.x.x.222?  Tell x.x.x.200
5698	43.923683	Dell_bb:bb:bb	Watchgua_cc:cc:cc	ARP	Who has x.x.x.222?  Tell x.x.x.200
5725	44.923355	Dell_bb:bb:bb	Watchgua_cc:cc:cc	ARP	Who has x.x.x.222?  Tell x.x.x.200
5728	46.412688	Dell_bb:bb:bb	Broadcast	ARP	Who has x.x.x.222?  Tell x.x.x.200
5729	46.413397	Watchgua_cc:cc:cc	Broadcast	ARP	Gratuitous ARP for x.x.x.222 (Request)

Het volledige log laat overduidelijk zien dat bij de 1e regels het probleem 'begint', en na de laatste regel het probleem is gefixt. Hier gaat een periode van +/- 30 seconden overheen, maar dit is niet altijd zo lang/kort.

In ieder geval, de reden dat ik dit blabla verhaal hier neerzet is omdat ik benieuwd ben naar eventuele soortgelijke ervaringen bij jullie, terwijl ik wacht op een antwoord.

Het apparaatje á 3000 euro zou toch gewoon moeten werken in een simpele drop-in mode, zou je zeggen. 10 dagen met support in de weer zonder enig resultaat brengt ook geen happy feelings met zich mee.

Servers gebruiken gewoon externe IP adressen, geen gebruik van VLANS/NAT op firebox, switch is ok (geeft geen foutmeldingen in log), servers gebruiken 1 netwerkkaart.

Ik ben benieuwd naar alle reacties/ervaringen met watchguard op dit gebied.

MVG,

Marlboro

Wij gebruiken ook overal watchguard, en dat is het eerste wat we uitzetten bij firewalls die in drop-in worden gezet.

Dit is inderdaad een probleem, ook belast dit de wachtguard enorm.

Oplossing, gewoon uitzetten die handel, en regel de arp op de switches.

Ha, het is toch niet te geloven.
Binnen een uur een reply met nuttige inhoud!
Alhoewel het niet het meest gewenste antwoord is natuurlijk...

Maar even to the point, 'gewoon uitzetten' begrijp ik niet helemaal. Ik zie geen opties mbt ARP caching, of ik kijk er overheen. Kan je dat nader toelichten?

Heb je overigens nog adviezen mbt Watchguard/Firebox?

De IPS/AV service trial verloopt binnenkort, maar aangezien de betreffende servers puur webcontent related zijn lijkt me dat een overbodige service om aan te schaffen. Eens?

Is het ook zo dat de 'standaard' Intrusion Prevention (Setup->Intrusion Prevention, in Policy Manager) los staat van die IPS/AV service?

Onder de Global Settings zet je TCP Syn checking uit, dit zorgt voor het ARP gedoe.

Vraag met niet waarom het dat is, maar dat uitzetten doet het altijd bij ons.

Voor je lifesecurity, die zou ik toch wel nemen.
Dat contract houd software updates ook bij, die kan je dan krijgen voor de volgende 2 jaar. Dat is de FireWare versie.

Draai je nu v9.0 ?

AV is nuttig voor bedrijfstoepassingen om de clients te beschrmen, servers voor webhosting zou ik er niet direct achter zetten.

De antispam licentie is dan wel weer iets wat zeer goed is en niet veel kost.

Die logs die je ziet, die zijn gemaakt nadat inderdaad op aanbeveling van support TCP SYN CHECKING uitgezet is... ik vroeg het al aan die support aziaat, antwoord:

Reason why i recommended you to uncheck the Block SYN Flood attacks is as we know that TCP works on 3-way handshake protocol. TCP SYN checking checks the Half Close connections. There is a timeout value fixed for the packets to be recieved by sequence to the firebox. If the packet hits after the timeout value the firebox RESETS the connection. When we DISABLE this option it still works on 3-way handshake protocol but it doesn't set the timeout value so it doesn't reset the connection frequently or doesn't wait for the packet to reach in sequence. So, disabling that option doesn't create a security hole on the firebox because it will still block half close connections.

Maak ervan wat je zelf wilt.

Lifesecurity update-abotje heb ik inderdaad wel genomen - draai inderdaad v9 nu.

Antispam is ook overbodig in dit geval, email wordt vrijwel niet gebruikt - puur uitgaande emails. Af en toe wat spam deleten om tijd/administratie/geld te besparen is snel overwogen natuurlijk.

Maar even back-to-basic, het probleem wat jij dus oplost met een vinkje wegvinken, doet zich hier nog steeds voor... ik vrees echter dat jij daar ook geen oplossing voor hebt?

Het enige dat ik dan kan aanbevelen in de firebox nog eens opnieuw flashen.

Ik ga het zeker proberen wanneer er geen duidelijkheid komt. Mag toch hopen dat support op korte termijn ook zoiets gaat adviseren.

Bedankt voor je replies!