cisco access-list- geen wildcard match?

Pagina: 1
Acties:

  • witchdoc
  • Registratie: Juni 2000
  • Laatst online: 19-01 11:05
Raar probleempje met cisco access lists.
Bedoeling is source natting te doen voor een aantal users zodat deze allemaal buitengaan met een bepaald source ip.
Client netwerk: 172.16.18.0 /23 (255.255.254.0)
Test user: 172.16.18.101 /23

ip access-list extended my_list
ip nat pool my_pool 10.11.12.13 netmask 255.255.255.0
ip nat inside source list my_list pool my_pool overload
ip access-list extended my_list
504 permit tcp host 172.16.18.101 host 192.103.109.4
550 permit tcp 172.16.18.0 0.0.1.255 host 192.103.109.4
551 permit tcp any host 192.103.109.4


Als ik deze connectie gebruik vanaf .101 user pc krijg ik hits op rule 504 en werkt de connectie.
Rule 550 zou deze user en gans zijn subnet moeten toelaten.
Rule 551 zou eender welke user die probeert te connecteren naat 192.103.109.4 moeten toelaten.

Als ik rule 504 toevoeg krijgt deze wél matches en rule 550 en 551 logischer wijze niet. Als ik rule 504 dan verwijder krijgen 550 en 551 og steeds geen matches. Dit lijkt me niet te kloppen.
Waarom matched rule 550 of 551 niet voor verkeer dat wel matched aan rule 504?

Ook, je kan logging activeren bij die acces-lists ( 504 permit tcp host 172.16.18.101 host 192.103.109.4 log). Ik kan alleen niet vinden waar ik die logs dan ook kan bekijken.Wie heeft een idee?

  • DGTL_Magician
  • Registratie: Februari 2001
  • Laatst online: 30-01 15:53

DGTL_Magician

Kijkt regelmatig vooruit

poohbeer schreef op maandag 27 oktober 2008 @ 11:24:
Raar probleempje met cisco access lists.
Bedoeling is source natting te doen voor een aantal users zodat deze allemaal buitengaan met een bepaald source ip.
Client netwerk: 172.16.18.0 /23 (255.255.254.0)
Test user: 172.16.18.101 /23

ip access-list extended my_list
ip nat pool my_pool 10.11.12.13 netmask 255.255.255.0
ip nat inside source list my_list pool my_pool overload
ip access-list extended my_list
504 permit tcp host 172.16.18.101 host 192.103.109.4
550 permit tcp 172.16.18.0 0.0.1.255 host 192.103.109.4
551 permit tcp any host 192.103.109.4


Als ik deze connectie gebruiJk vanaf .101 user pc krijg ik hits op rule 504 en werkt de connectie.
Rule 550 zou deze user en gans zijn subnet moeten toelaten.
Rule 551 zou eender welke user die probeert te connecteren naat 192.103.109.4 moeten toelaten.

Als ik rule 504 toevoeg krijgt deze wél matches en rule 550 en 551 logischer wijze niet. Als ik rule 504 dan verwijder krijgen 550 en 551 og steeds geen matches. Dit lijkt me niet te kloppen.
Waarom matched rule 550 of 551 niet voor verkeer dat wel matched aan rule 504?

Ook, je kan logging activeren bij die acces-lists ( 504 permit tcp host 172.16.18.101 host 192.103.109.4 log). Ik kan alleen niet vinden waar ik die logs dan ook kan bekijken.Wie heeft een idee?
Dan logt ie hits in je console logbuffer. Deze kun je bekijken met show logging. Je ACL lijkt me zo vluchtig gezien wel goed dus zou die moeten hitten.

Blog | aaZoo - (Wireless) Networking, Security, DDoS Mitigatie, Virtualisatie en Storage


Verwijderd

Dat is omdat een ACL werkt volgens het principe van first match, zodra hij een match vindt stopt hij met de ACL af te lopen.
Je kan dit testen door je 504 na je 550 te zetten en dan zal je zien dat er een match is op 550.

  • jvanhambelgium
  • Registratie: April 2007
  • Laatst online: 20:33
@Sybie! -> Als hij de 504 weg gaat nemen is de volgende "first match" wel degelijk de 550, die zou dus een "hit" moeten geven. Die ACL "covert" wel degelijk zijn source-station.

Als je het "logging" statement gaat gebruiken zal tijdens een "show ip access-list XXX" je tussen haakjes ook getalletje zien verschijnen van hoeveel hits je er tegen hebt.
Verder zal ook een "show log" je in principe 1 lijn per hit moeten geven met extra info, maar het kan zijn dat je hiervoor de optie "log-input" op de ACL moet gebruiken en niet enkel "log"

Wil ik nog enkel meegeven dat je soms moet oppassen vanwege de dynamiek hier, ACL's toevoegen en weer weghalen en toevoegen etc. kan mischien niet altijd direct het gewenste resultaat geven omdat bepaalde zaken nog in gebruik zijn ?
Haal het NAT statement eens van de interface en re-apply dit.

Voor sommige architecturen werken de ACL's ook "in hardware" geladen dus de counters zijn niet altijd representatief dacht ik.

  • TrailBlazer
  • Registratie: Oktober 2000
  • Laatst online: 07-02 09:48

TrailBlazer

Karnemelk FTW

Heb je ook geen hits als je je router een keertje reload voordat je opnieuw gaat testen. Mischien ziet er wel gewoon een raar iets in de code waarmee de counters geupdate worden. Als dat erg destructief is kan je ook nog proberen alle nat entries te clearen.

  • Ascension
  • Registratie: September 2008
  • Laatst online: 19:31
Waarom doe je 'permit tcp' en geen 'permit ip'? Wil je alleen TCP verkeer NATen?

Verwijderd

@ JavanhamBelgium => Sorry verkeerd gelezen, ik LAS dat hij zichafvroeg waarom 550 ed geen hits kregen en 504 wel.
Pagina: 1