ASA blockt verkeer met gelijk source en destination poort

[Q]

Beste goden,

Na veel testen met netcat en tcpdump ben ik er eindelijk achter waarom openvpn en ntp (UDP) niet meer werkt..

Met netcat heb ik kunnen bevestigen dat als de source poort van een udp pakket gelijk is aan de destination, dat de cisco asa firewall besluit om dat maar te blokkeren.

Kan iemand dit fenomeen verklaren? Is er een logische reden waarom een firewall dit soort verkeer zou moeten blokkeren? Het heeft wel gewerkt.

EDIT:

1. Al het verkeer met een gelijke source en destination poort wordt geblocked zowel van UDP als TCP.
2. Al het verkeer met een source poort onder de 1024 lijkt te worden geblocked (privileged ports).

Iemand bekend met een mogelijke setting die dit kan veroorzaken?

[ Voor 24% gewijzigd door Q op 03-02-2010 20:12 ]

[Verwijderd]

Van welke interface naar welke interface gaat het verkeer op de asa? Of blijft het intra interface?

Iets meer details zouden niet verkeerd zijn ;-)

Wat geeft de ASA zelf in zijn log weer als reden voor het droppen?

[Q]

De asa geeft niets weer in zijn logs. Ik ga kijken of ik de logging nog kan verbeteren. Het verkeer gaat niet naar fysieke interfaces, maar van vlan x naar vlan y.

Kan er een setting zijn binnen de ASA die dit vreemde gedrag kan verklaren?

Inmiddels, ik snap er niets van, werkt het wel weer goed vanuit andere vlans richting Internet. Maar ik heb niets aangepast. Met goed werken bedoel ik dat zaken als NTP waarbij source en destination poort gelijk zijn weer goed werken.

Maar andere netwerken geven nog steeds dit probleem.

[Verwijderd]

Gaat overig verkeer wel goed tussen je VLAN's?

Ofwel, staat same-security-traffic permit intra-interface aan?

[Q]

Verwijderd schreef op dinsdag 09 februari 2010 @ 14:50:
Gaat overig verkeer wel goed tussen je VLAN's?

Ofwel, staat same-security-traffic permit intra-interface aan?

Al het verkeer werkt prima. Alles werkt goed. Dit is het enige wat niet werkt en het heeft prima gewerkt.

Logische conclusie moet zijn dat er iets is aangepast, dus ik ga verder graven.

[Verwijderd]

Q schreef op dinsdag 09 februari 2010 @ 18:39:
[...]


Al het verkeer werkt prima. Alles werkt goed. Dit is het enige wat niet werkt en het heeft prima gewerkt.

Logische conclusie moet zijn dat er iets is aangepast, dus ik ga verder graven.

Je kan via ASDM packet tracer gebruiken, je kunt hiermee een packet injecteren en dus simuleren wat je nu ziet. Dan gaat hij alle stappen af die een normaal ip packet ook zou volgen, en kun je precies zien waar hij gedropped wordt.

[Q]

En dat is dus zo frustrerend: packet tracer beweert dat het pakket allowed is. Maar het wordt gedropped.

De situatie is nu dat verkeer met een source poort onder de 1024 en status 'nieuw' wordt gedropt, zowel udp als tcp.

Dit is echter op 1 interface, de andere netwerken hebben er geen last (meer) van.

[ Voor 51% gewijzigd door Q op 10-02-2010 01:20 ]

[Verwijderd]

Q schreef op woensdag 10 februari 2010 @ 01:19:
En dat is dus zo frustrerend: packet tracer beweert dat het pakket allowed is. Maar het wordt gedropped.

De situatie is nu dat verkeer met een source poort onder de 1024 en status 'nieuw' wordt gedropt, zowel udp als tcp.

Dit is echter op 1 interface, de andere netwerken hebben er geen last (meer) van.

Strange.. neem aan dat je asa up to date is.

Wat als je een capture start vanuit de asa? Zie je ook echt de packets de interface inkomen en weer verlaten?

[Q]

Asa is speciaal geupdated hiervoor. Pakketten met een source poort <1024 worden niet in een capture gevangen.

[Verwijderd]

Enige update? Ben zelf ook wel benieuwd eigenlijk, aardig wat met ASA gewerkt, maar dit nog nooit tegen gekomen.. :-)

[Q]

Ik kom er niet uit en heb er geen tijd voor. Ik weet vrijwel zeker dat het de asa is, maar we kunnen er nu wel mee leven, met wat lap middelen.

Wat er moet gebeuren is dat de config bewaard moet worden, en dan gaan we rules en netwerken wissen, kijken of daar nog iets zit. De config is erg complex.

[ Voor 35% gewijzigd door Q op 20-02-2010 13:45 ]

[Verwijderd]

Q schreef op zaterdag 20 februari 2010 @ 13:44:
Ik kom er niet uit en heb er geen tijd voor. Ik weet vrijwel zeker dat het de asa is, maar we kunnen er nu wel mee leven, met wat lap middelen.

Wat er moet gebeuren is dat de config bewaard moet worden, en dan gaan we rules en netwerken wissen, kijken of daar nog iets zit. De config is erg complex.

Geen TAC support? ;-)

[axis]

Vreemd, en als je in je ASDM de logging op debug zet en filtert op poort 123 zie je ook niets? Ik heb een stuk of 10 asa's, maar heb nog niet zoiets eerder meegemaakt. Hier een unix doosje dat achter een dynamic translation zit:

code:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nic0, link-type EN10MB (Ethernet), capture size 96 bytes
13:25:41.806125 IP 10.229.10.46.123 > 194.109.153.91.123: NTPv4, Client, length 48
13:25:41.806965 IP 194.109.153.91.123 > 10.229.10.46.123: NTPv4, Server, length 48
13:25:41.807067 IP 10.229.10.46.123 > 194.109.153.91.123: NTPv4, Client, length 48
13:25:41.807685 IP 194.109.153.91.123 > 10.229.10.46.123: NTPv4, Server, length 48
13:25:41.807733 IP 10.229.10.46.123 > 194.109.153.91.123: NTPv4, Client, length 48
13:25:41.808488 IP 194.109.153.91.123 > 10.229.10.46.123: NTPv4, Server, length 48
13:25:41.808524 IP 10.229.10.46.123 > 194.109.153.91.123: NTPv4, Client, length 48
13:25:41.809319 IP 194.109.153.91.123 > 10.229.10.46.123: NTPv4, Server, length 48

en in de ASDM (ben nog niet zo'n cli held):



Misschien zie je wat over het hoofd, en valt je iets op als je vergelijkt..

[ Voor 3% gewijzigd door axis op 21-02-2010 13:37 ]

[Q]

Is in behandeling bij Cisco, maar die kunnen ook niet echt helpen. Die willen even een config dump hebben of op je scherm mee kijken. Grappenmakers.

Bovenstaande is exact hoe ik het zou verwachten dat het zou moeten werken. En ik zie niets. Het heeft goed gewerkt, er is met de ASA gekloot en daarna was het stuk.

Ik kom er wel uit, het heeft gewerkt, het kost alleen veel werk. Config weer terug draaien en testen. Het is gezien de reacties niet ergens een verborgen vinkje.

Bedankt voor het meedenken, ik post de oplossing, als ik die vind.

[ Voor 6% gewijzigd door Q op 21-02-2010 23:45 ]

[Q]

Beste mensen, ik heb de oorzaak gevonden, voor wie het boeit:

Na nog wat beter testen bleek het verkeer volgens een pcap op de ASA wel uit de juiste interface te komen. Ik snapte er niets meer van.

Zou het dan toch een layer 2 device zijn, een switch? Dat kan toch niet?

Mooi wel.

Wij gebruiken HP Procuve switches en die hebben twee vage security opties die ik heb uitgeschakeld (geen security risico) en prompt kwam al het verkeer door.

Een layer 2 device dat op layer 3 loopt te kloten. Dat snap ik niet.

Maar ik ben blij, case closed.

[MrFX]

Q schreef op woensdag 07 april 2010 @ 17:48:
Beste mensen, ik heb de oorzaak gevonden, voor wie het boeit:

Na nog wat beter testen bleek het verkeer volgens een pcap op de ASA wel uit de juiste interface te komen. Ik snapte er niets meer van.

Zou het dan toch een layer 2 device zijn, een switch? Dat kan toch niet?

Mooi wel.

Wij gebruiken HP Procuve switches en die hebben twee vage security opties die ik heb uitgeschakeld (geen security risico) en prompt kwam al het verkeer door.

Een layer 2 device dat op layer 3 loopt te kloten. Dat snap ik niet.

Maar ik ben blij, case closed.

Vreemd probleem ik ben overigens wel benieuwd welke 2 security settings dit waren.

Het enige wat me bijstaat van mijn cisco BCMSN studie is:

The destination MAC is a unicast, and there is an entry for the address in the MAC table, AND the source and destination address are found off the same port.This frame will be filtered it will not be forwarded at all by the switch.

bron:Trainsignal BCMSN

[Q]

MrFX schreef op woensdag 07 april 2010 @ 18:18:
[...]


Vreemd probleem ik ben overigens wel benieuwd welke 2 security settings dit waren.

Auto DoS <-- Toen ik die uit schakelde was het issue over.

Storm Control (STP?)

Dit is HP Procurve specifiek.

[ Voor 5% gewijzigd door Q op 07-04-2010 20:50 ]