ACL doet vaag

[xelnaha]

Hallo,

Ik ben gisteren tegen een vaag probleem aangelopen, welke ik nog niet kan verklaren. We zijn bezig op het netwerk om acl's te verbouwen zodat verkeer van server A moet naar Server B, laten voor gemak server A ip 1.1.1.1 geven en IP van server B 2.2.2.2

1.1.1.1 --> 2.2.2.2 @ tcp/383
wordt toegestaan.

We doen dit op een catalys 6500.

Op de svi is als volgt geconfigureerd:

code:

Interface Vlan 2
ip access-group vlan2-in in
ip access-group vlan2-out out

ip access-list vlan2-in is als volgt:

code:

10 permit ip any any log

ip access-list vlan2-out is als volgt:

code:

10 permit tcp host 1.1.1.1 host 2.2.2.2 eq 383 log

Met deze config komt de verdinding niet tot stand, dankzij SYN time out. We zien in het log dat het pakket door komt. Het antwoord komt niet terug.

Wanneer ik de accesslist vlan2-in aanpas naar:

code:

1 permit tcp host 2.2.2.2 any established log

zie ik wel een log hit en wordt de sessie ook opgebouwd.

Nu mijn vraag, ip any any zou established verkeer toch ook moeten toestaan? Immers, established is gewoon een TCP flag. Wat klopt hier niet aan? Ik heb reeds wat rond gegoogled maar kom niet tot een antwoord waarom dit gedrag zo is.

Iemand vaker tegen dit probleem aangelopen?

[jvanhambelgium]

De 6500 is een behoorlijk complex doosje.
Mischien dit even doorlezen ;

http://www.cisco.com/en/U...a00800c9470.shtml#wp39514

Voor verschillende 6500 SUP's gelden wat andere regels. Zoals je weet worden die ACL's ook "gecompiled" in hardware (performance) in tegenstelling tot kleine(re) Cisco doosjes.

Het zou me *ECHT* verwonderen als je daar tegen een 'ordinaire" IOS bug aanloopt. Het kan natuurlijk wel, maar mischien is dit soort "behaviour by design" en moet je eerst iets forcen oid.

[Kabouterplop01]

Welk ip adres heeft interface vlan 2?

[xelnaha]

Kabouterplop01 schreef op donderdag 02 augustus 2012 @ 14:07:
Welk ip adres heeft interface vlan 2?

ik heb de ip adressen aangepast naar voorbeeld ivm feit dat werkgever niet leuk vind dat deze dingen op internet komen wat mij betreft maak je er 2.2.2.1 van

[Kabouterplop01]

dat raakt de materie!

Dat lijkt me ook dat het een vage situatie is. Misschien moet TAC daar iets over brullen.
Er is maar 1 ding wat ik me kan voorstellen wat een beetje in de richting is.
beveiliging van je supervisor en vlan.
de regel permit ip any any log vervangen voor permit ip <ip wildcard subnet> any (log)
dan heb je een soort antispoofing en is specifieker. (maar dat terzijde, het is inderdaad merkwaardig)

However.... Werkt het wel zonder die ACL in?

offtopic: dan kun je ook tcp any any established doen...

[ Voor 11% gewijzigd door Kabouterplop01 op 03-08-2012 08:58 ]

[xelnaha]

Kabouterplop01 schreef op vrijdag 03 augustus 2012 @ 08:53:
dat raakt de materie!

de regel permit ip any any log vervangen voor permit ip <ip wildcard subnet> any (log)
dan heb je een soort antispoofing en is specifieker. (maar dat terzijde, het is inderdaad merkwaardig)

dit is historie helaas. Zelf gebruik ik nooit ip any any, om exact de reden die jij geeft.

Kabouterplop01 schreef op vrijdag 03 augustus 2012 @ 08:53:
However.... Werkt het wel zonder die ACL in?
offtopic: dan kun je ook tcp any any established doen...

zonder werkt het wel ja. Ik heb redelijk kunnen pinpointen dat het verschil ergens in de permit ip zit en permit tcp ..... established. Ik kan het nog niet verklaren waarom, behalve wat eerder is gezegd: bij het compilen is iets niet helemaal lekker gegaan.

[Kabouterplop01]

1 puntje nog en dat is iets wat jvanhambelgium ook al aangaf.

door die permit ip any any log is het niet meer in hardware, maar de log statement zorgt ervoor dat het door de supervisor gaat.

Nu rijst de vraag: werkt het niet, of zie je die log entry niet. (Volgens mij doet de switch niet ip any any loggen, mbmt het beveiligen van de supervisor)

[WhizzCat]

Misschien roep ik iets stoms, maar is het wel een routed link en geen NATted link? Anders gelden er andere source/destination adressen lijkt mij.

[_-= Erikje =-_]

Kijk anders eens wat de resulterende ACL in de hardware is (commando ala show tcam interface gigabitEthernet 1/0/1.100 acl in ip)

[Barreljan]

Even los van alle supervisor kwesties (want daar gaat het niet over)

Je doet een in én out acl.
Daar hoort inderdaad die established bij. Je hebt altijd terugkerend verkeer.

Dus vaag? Nee, by design.

[CyBeR]

Barreljan schreef op zondag 05 augustus 2012 @ 17:52:
Even los van alle supervisor kwesties (want daar gaat het niet over)

Je doet een in én out acl.
Daar hoort inderdaad die established bij. Je hebt altijd terugkerend verkeer.

Dus vaag? Nee, by design.

Dat wilde ik eerst ook stellen, maar toen bedacht ik dat 'ie in de eerste instantie de in acl op 'alles toestaan' had gezet.

[jvanhambelgium]

Barreljan schreef op zondag 05 augustus 2012 @ 17:52:
Even los van alle supervisor kwesties (want daar gaat het niet over)

Je doet een in én out acl.
Daar hoort inderdaad die established bij. Je hebt altijd terugkerend verkeer.

Dus vaag? Nee, by design.

Mischien dat je voor die dingen beter reflexive ACL's kan gebruiken die gelijk het gaatje openen in de andere richting.

Ik zou niet gewoon bot stellen "by design" want een IN en OUT ACL worden volledig los van elkaar ge-evalueerd (denk ik) op een interface! (geen enkele state-notie, en de ene ACL weet niets van de andere ACL)

Bijgevolg zou ik ook denken dat inbound packets, zelfs MET een established-bit hoog door zouden mogen terug naar binnen bij een "ip any any" allow als ingress ACL. (zoals de TS probeerde)

"ip any any" zal zich niet eens bezighouden met een level dieper te kijken naar oa flags/state/ports.Dat laat gewoon alles door dat "voldoet" als IP-packet en een source-IP en destination-IP heeft.

Aan de TS : Heb je die inbound ACL ook al eens als "permit tcp host 2.2.2.2 any log" (dus zonder established) getest ? Is mischien ook al afdoende.

Zou leuk zijn als iemand hier een Cisco note van kan boven toveren.

[Barreljan]

Ik stel het niet bot, en nee ze hebben geen notie van elkaar. Dat klopt ook.
Established verkeer moet je inkomend er op zetten, of je moet je andere host (je destination) in dezelfde IN acl opnemen. Dat kan ook.
Established verkeer is op een router (ongeacht model/ios) zo goed als altijd nodig voor fatsoenlijk uitgaand verkeer en dus je TCP sessie dus ook wat betekend dat je inkomend established moet opnemen. Desnoods selectiever op bepaalde IP adressen.

Reflexive acl zou ik niet doen, niet op een 6500. Het kan namelijk redelijk wat impact mee brengen in cpu gebruik. Maar ik ken de omgeving niet, de exacte samenstelling van de het chassis en wat er aan verkeer langs komt. Net als een LOG optie aan een acl regel op een router, dat kan flinke impact hebben op je CPU.

[Kabouterplop01]

Barreljan schreef op zondag 05 augustus 2012 @ 20:40:

Established verkeer moet je inkomend er op zetten, of je moet je andere host (je destination) in dezelfde IN acl opnemen. Dat kan ook.
Established verkeer is op een router (ongeacht model/ios) zo goed als altijd nodig voor fatsoenlijk uitgaand verkeer en dus je TCP sessie dus ook wat betekend dat je inkomend established moet opnemen.

Dat is aardig verwarrend.

[xelnaha]

De ACL's zijn bij design op deze manier gebouwd, een IN en in OUT voor het vekeer vanaf de INside interface, en verkeer aankomende op de OUTside interface en niet incoming en outgoing, zoals ik dit al heel vaak door elkaar heb gehaald.

Reflective hebben we uitstaat ivm hoge CPU belasting inderdaad.

Aan de TS : Heb je die inbound ACL ook al eens als "permit tcp host 2.2.2.2 any log" (dus zonder established) getest ? Is mischien ook al afdoende.

niet getest, en zou wel werken maar zet te veel open, aangezien established verkeer op de OUTside acl al is toegestaan.

Helaas heb ik niet meer de mogelijkheid om uitgebreid te testen.

[jvanhambelgium]

xelnaha schreef op maandag 06 augustus 2012 @ 21:53:
Reflective hebben we uitstaat ivm hoge CPU belasting inderdaad.
[...]
Helaas heb ik niet meer de mogelijkheid om uitgebreid te testen.

Spijtig datje niet meer kunt testen.
Voor performance rond "reflexive ACL's" moest je je geen zorgen maken indien jullie een PFC-card geinstalleerd hebben. De 6500 doet deze dan in hardware met niet meer "impact" dan andere ACL's.

---------
The Cisco Catalyst 6500 Series switches support the following types of ACLs and ACL-based features in hardware with no performance impact:

•IP standard and extended ACLs permit and deny (with Supervisor 1a with PFC use the no ip unreachable s command on VLAN and other interfaces)

•VACLs

–Supervisor 720—Supports IP and MAC VACLs
–Supervisor 1a with PFC and Supervisor 2 with PFC2—Support IP, IPX, and MAC VACLs

•Reflexive (session-based) ACLs—Limit of 512 sessions on Supervisor 1a with PFC; 32K sessions on Supervisor 2 with PFC2; 96K sessions on Supervisor 720 with PFC3