[CISCO] problemen met PAT?

maandag 4 augustus 2008 12:46

Karnemelk FTW

vervang dit eens

ip nat inside source route-map SDM_RMAP_1 interface Dialer1 overload

door dir

ip nat inside source list 102 interface Dialer1 overload

Acties:

maandag 4 augustus 2008 13:41

Zie je eigenlijk iets in de logging (vooral rond de logging die je configureerde op de acl's etc)
Op de moment dat je met zo'n "probleempc" een connectie naar buiten opzet, zie je dan enige dropped items verschijnen ??

Doe een een debug rond pat, desnoods met een ACL zodat de impact bepert blijft.
Zo kan je wat volgen wat er allemaal gaande is hé...

Het feit dat op 1 PC alles goed werkt is toch wel raar en zegt me dat je geen fundamentele zaken gemist hebt.

Start debugging my boy!

PS : Je zou inderdaad die "route-map" kunnen wegdoen en gewoon de ACL 102 meegeven zoals Trailblazer meegaf. Zal de performance ten goede komen, want een 28xx architectuur met route-maps (pbr) zal mischien terugvallen op "process-switching" ipv de meer geavanceerdere mogelijkheden...(fast/cef)

Acties:

maandag 4 augustus 2008 16:47

Topicstarter

De logging laat niets zien, die stond eerst niet eens aan, die heb ik speciaal hiervoor aangezet.
Nat debugging had ik al aangezet, en er waren ook nat translation tables gelijk nadat ik hotmail had geprobeerd. Het is helaas een live omgeving, dus overdag wijzigingen maken zullen mijn collega's en de mail server niet waarderen.

Acties:

Leon T

Ni!

Op welk VLAN zit de PC die het wel goed doet? Toevallig op vlan1? Als ik je access lists goed lees zou alleen 192.168.1.0 0.0.0.255 online komen.

maandag 4 augustus 2008 18:29

Acties:

maandag 4 augustus 2008 18:44

Tja, LeonT zegt daar al iets.
Je hebt daar een puike config met vanalle toeters-en-bellen maar als je nu eens zou beginnen zeggen welke PC's met welke IP's goed werken en welke niet etc ... zou ook al helpen ;-)

Acties:

maandag 4 augustus 2008 19:22

Karnemelk FTW

Zit wel wat in maar ik ging er vanuit dat de TS dat zelf ook welk kon bedenken. Overigens is het 1e wat ik doe in dit soort dingen is alle ACLs van interfaces afslopen. Een Cisco wordt echt niet zomaar gehacked door de 1e de beste scriptkiddie.

Acties:

maandag 4 augustus 2008 19:54

Leon T schreef op maandag 04 augustus 2008 @ 16:47:
Op welk VLAN zit de PC die het wel goed doet? Toevallig op vlan1? Als ik je access lists goed lees zou alleen 192.168.1.0 0.0.0.255 online komen.

Hij heeft er inderdaad wel een ACL rondhangen, maar ik zie hem nergens op een interface actief staan hoor (toch op geen van de fastetheret sub-interfaces / vlans)

Deze dus :

ip access-list extended sdm_fastethernet0/0.1_in
remark SDM_ACL Category=1
remark Enterprise Manager
permit tcp any eq 1158 192.168.6.0 0.0.0.15
remark SQL-Net
permit tcp any eq 1521 192.168.6.0 0.0.0.15
remark Rest van *verwijderd* weigeren
deny ip any 192.168.6.0 0.0.0.15
remark Al het uitgaande verkeer toestaan
permit ip any any

Acties:

maandag 4 augustus 2008 21:42

☑Rekt | ☐ Not rekt

jvanhambelgium schreef op maandag 04 augustus 2008 @ 19:22:
[...]

Hij heeft er inderdaad wel een ACL rondhangen, maar ik zie hem nergens op een interface actief staan hoor (toch op geen van de fastetheret sub-interfaces / vlans)

De regel

ip nat inside source route-map SDM_RMAP_1 interface Dialer1 overload

heeft deze route map gekoppeld:

access-list 102 remark SDM_ACL Category=2
access-list 102 deny ip any 192.168.6.0 0.0.0.15
access-list 102 permit ip 192.168.1.0 0.0.0.255 any

via deze regels:

route-map SDM_RMAP_1 permit 1
match ip address 102

Wat inhoudt dat alleen 192.168.1.0/24 het internet op mag.

[ Voor 5% gewijzigd door Vicarious op 04-08-2008 20:31 ]

Vicariously I live while the whole world dies

Acties:

dinsdag 5 augustus 2008 09:14

Whoops ;-)
Inderdaad effe over gekeken ... was enkel naar pure interface acl's aan 't loeren...

Nochtans spreekt de TS over dat sommige sites "traag" (maar werkend...) zijn dus een keiharde bounce tegen een ACL zal er ook wel niet inzitten...

Het is en blijft een vaag verhaal voorlopig ;-)
Zoals we niet meer details van welke pc's met welke IP's al dan wel niet volledig werken hebben we niet veel info ....

Je noemde daar 2 domeinen op "hotmail.com" en "routenet.nl" die "niet" werken ? of traag werken ??
Probeer eens wat andere websites ? microsoft.com ? cisco.com ? enkele .nl domeintjes ??
Is het hele DNS-verhaal hier wel OK ? Ik zie niet dat de router dns-proxy speelt, dus de client doen hun resolving dmv een dns-resolver op internet.

Hoe zit het met een dns-lookup test vanop de PC's ?? Gaat dit vlot ? duurt het eventueel (abnormaal) lang ? etc,etc,

Acties:

dinsdag 5 augustus 2008 09:53

☑Rekt | ☐ Not rekt

jvanhambelgium schreef op maandag 04 augustus 2008 @ 21:42:
Whoops ;-)
Inderdaad effe over gekeken ... was enkel naar pure interface acl's aan 't loeren...

Nochtans spreekt de TS over dat sommige sites "traag" (maar werkend...) zijn dus een keiharde bounce tegen een ACL zal er ook wel niet inzitten...

Het is en blijft een vaag verhaal voorlopig ;-)
Zoals we niet meer details van welke pc's met welke IP's al dan wel niet volledig werken hebben we niet veel info ....

Je noemde daar 2 domeinen op "hotmail.com" en "routenet.nl" die "niet" werken ? of traag werken ??
Probeer eens wat andere websites ? microsoft.com ? cisco.com ? enkele .nl domeintjes ??
Is het hele DNS-verhaal hier wel OK ? Ik zie niet dat de router dns-proxy speelt, dus de client doen hun resolving dmv een dns-resolver op internet.

Hoe zit het met een dns-lookup test vanop de PC's ?? Gaat dit vlot ? duurt het eventueel (abnormaal) lang ? etc,etc,

Wellicht dat het in VLAN2 ook werkt door deze route:
ip route 192.168.2.0 255.255.255.0 192.168.1.2

Vicariously I live while the whole world dies

Acties:

dinsdag 5 augustus 2008 10:53

Topicstarter

Ok, hoop reacties, ik ga even proberen ze allemaal te beantwoorden.

Als eerste nog een kleine uitleg over de situatie: Ik zit in een gebouw met meerdere bedrijven, waarbij ik als systeembeheerder bij het grootste bedrijf werk. 192.168.1.0/24 is "ons" netwerk. De andere netwerken zijn van de andere bedrijven.
Als grootste bedrijf hebben wij de Cisco aangeschaft en tussen de netwerken gehangen die gescheiden worden door VLANs.
Mate van vertrouwen tussen de bedrijven is hoog, ik kan op alle 6 de bedrijven als administrator inloggen op alle servers, dus beveiliging tussen de interne netwerken is niet gedaan mbv ACL's of iets in die richting.
Elk bedrijf heeft zijn eigen modem voor internet, want we komen wel origineel uit verschillende gebouwen, daarom dat alleen 1.0 op internet kan, de anderen kunnen zelf op internet.

Wij hebben de Cisco als koppeling tussen de netwerken aangeschaft met mogelijke uitbreidingsmogelijkheden naar gezamenlijk internet via glasvezel. We hebben een huis tuin en keuken routertje als internetrouter.

Toen kwam bij mij op dat de Cisco ook als internetrouter kan dienen aangezien ik toch een interface "over" heb, en we hadden een VPN nodig. Dus heb ik de Cisco geconfigureerd met PPPoE en alles leek goed te gaan, de VPN was functioneel, mails kwamen binnen en gingen weg, en ik kan van alles pingen, maar zodra er gebrowsed wordt komen er problemen. Routenet is tergend traag, hotmail.com verwijst nog door naar login.live.com maar valt dan dood neer.
Als ik de oude router weer terugzet en de standaardgateway daar weer op zet flitst alles weer langs.

-edit-

Gisteravond even geprobeerd die routemap te vervangen door list, geen verandering, maar ik laat het wel zo staan, alle prestatieverbeteringen hoe theoretisch ook zijn altijd welkom.

[ Voor 5% gewijzigd door MaVl op 05-08-2008 10:00 ]

Acties:

dinsdag 5 augustus 2008 11:05

Er zijn daar duistere krachten aan het werk ;-)
Het is toch al goed te kunnen lezen dat vb smtp vlotjes binnen EN buiten gaat ! (eerlijk gezegd ; dat maakt het probleem alleen nog maar boeiender ... euh ... lastiger)

Werkt je mail met een relay-host/smarthost , maw dump je al de mail bij je provider op een bepaalde machine/IP of doe de MTA zelf end-to-end delivery ?
Doe een een http-browser open op je mailserver (of is het een appliance oid) ? -> kan je eigenlijk surfen naar de "probleemsites" ?

Mischien dat het toch eens tijd is om de sniffer boven te halen! en te proberen om te zien wat er zich tussen een client (je browser) en een internet-server gaat afspelen, mischien komen er "abnormale dingen" boven drijven, excessieve "errors" "retransmissions" etc meer van die prullen...

PS : Kan je ook eens een "ip virtual-reassembly interface XXXXX" op al je interfaces doen ??
Je gebruikt daar fancy statements die je mischien niet nodig hebt ;-) en die mischien ietwat buggy kunnen zijn onder bepaalde omstandigheden etc.

Acties:

dinsdag 5 augustus 2008 12:17

☑Rekt | ☐ Not rekt

Dat komt door die access-list die je hebt. Je laat alleen het netwerk 192.168.1.0 toe op je PAT pooltje. De rest probeert het waarschijnlijk rechtstreeks via het publieke IP naar buiten te komen zodra er even geen sessie openstaat?

Ga nou eerst eens na van welke pc's het wel goed gaat en van welke neit, en post dan in welk VLAN ze zitten en welke IP-configuratie ze hebben. Dan wordt het allemaal waarschijnlijk al een stuk duidelijker.

Vicariously I live while the whole world dies

Acties:

dinsdag 5 augustus 2008 13:19

Topicstarter

Alleen vlan 1 mag via onze modem internetten, de probleem pc's en de werkende zitten alle in 192.168.1.0/24.
Ons internetdomein heeft een MX-adres dat rechtstreeks naar ons publieke ip adres wijst.
Onze mail server doet zelf dns lookups en stuurt de mails rechtstreeks naar de in de mx vermelde adressen van domeinen, backuphost is onze provider, maar die wordt alleen gebruikt als een externe server niet reageert.
Ip configuratie van alle clients: DHCP die vertelt ze een ip in 192.168.1.0/24, de dns server, de standaardgateway en de routes naar de andere 192.168 netwerken, dit omdat de clients bij gebruik van de huis tuin en keuken router niet uit zichzelf weten dat 192.168 naar een andere router moet dan de standaardgateway.
De goed internettende pc is de mijne, DHCP 192.168.1.11. De niet werkende, de andere pc's die van dezelfde DHCP hun gegevens krijgen.
Huis tuin en keuken router ip: 192.168.1.225.
Cisco ip: 192.168.1.220
En ja, als ik van router wissel, dan verander ik de standaard gateway in de dhcp server en dan ga ik naar een client, doe een ipconfig /refresh en dan ipconfig /all om te controleren. En als ik dan op de dhcp server zit dan verander ik ook gelijk op de server (uiteraard geen dhcp client zelf) de standaardgateway naar de goeie van de 2.

Acties:

dinsdag 5 augustus 2008 13:26

Dit begint een beetje te gek worden ;-)

1) Trek je "backup" internet-modem/routertje 192.168.1.225 een uit de stekker -> lost dit het probleem niet op ?
2) Verander jouw werkende PC met DHCP (reserveratie?) 192.168.1.11 eens naar het IP van zo'n probleem PC
3) Klop eens vast IP / gateway / dns in een "probleem PC" en probeer eens te surfen ??
4) Ik veronderstel dat je nergens op PC's gebruik maakt van een proxy-server settings ?

Acties:

dinsdag 5 augustus 2008 14:13

☑Rekt | ☐ Not rekt

Hoe zit het met je DNS configuratie? Geef je in je DHCP je eigen interne DNS server op? En welke forwarders staan er dan in die DNS server ingesteld?

Vicariously I live while the whole world dies

Acties:

dinsdag 5 augustus 2008 15:12

Topicstarter

Als de Cisco internet router is, dan is de "backup" uit.
DHCP reserveringen zijn er niet, er is een pool, en iedereen die inprikt en erom vraagt krijgt een adres.
Proxy maak ik tijdens het testen geen gebruik van, Firefox op elke pc zonder proxy en kijken of het werkt, maar alleen voor mij is er Firefox, mijn collega's maken (hogerhand beslist) allemaal gebruik van explorer met een proxy, maar die heb ik voor het testen al omzeild.

De DHCP geeft als dns server onze domeinserver op, en deze doet zijn lookups bij onze provider, en ook dit verkeer komt aan . Ik was de inspect rule voor domain vergeten, toen werkte niets meer, inspect rule voor domain erbij en dns werkt ook als zonnetje.

Het ip van mijn pc op het ip van een probleem pc vastzetten moet ik nog proberen, maar dan moet ik of mijn eigen modem van thuis meenemen of 'savonds testen, want ik kan niet overdag de routers veranderen en even de stekker uit het modem trekken terwijl de mailserver druk bezig is.

Acties:

dinsdag 5 augustus 2008 15:31

☑Rekt | ☐ Not rekt

Je hoeft toch geen routers los te trekken om je eigen pc een ander IP toe te wijzen?

Vicariously I live while the whole world dies

Acties:

dinsdag 5 augustus 2008 15:32

Topicstarter

Dat hoeft niet nee, maar hij wordt gebruikt als internet router, die functie gaat over naar de Cisco, dus waarom zou ik een router in het netwerk laten zitten die als enige functie heeft een ip adres hebben?

Acties:

dinsdag 5 augustus 2008 16:09

☑Rekt | ☐ Not rekt

Aha, je hebt nu dus weer de huis tuin en keukenrouter aangesloten en de cisco niet meer als ik het goed begrijp?

Vicariously I live while the whole world dies

Acties:

Leon T

Ni!

Kijk, bovenstaande uitleg maakt de configuratie van de router weer wat duidelijker.

Een andere vraag aan je; wat is de cpu usage van je router als er gewebbrowsed wordt (show proc cpu)? De reden dat ik dat vraag is dat jij bijzonder veel aan verkeer onder je inspect hebt staan, wat je performance nogal kan verminderen. Met name de ip inspect http baart me veel zorgen.

dinsdag 5 augustus 2008 17:02

Acties:

dinsdag 5 augustus 2008 17:37

Topicstarter

Om het wat duidelijker te maken: http://home.kabelfoon.nl/~avenger/tweakers/situatie.pdf
De verbingen van "andere netwerken" en "192.168.1.0/24" zijn als 2 getekend, maar dat is maar 1 fysieke verbinding met een paar subinterfaces.

Over die inspect rules, zoals je kunt zien is er ook een ip inspect Test met alleen tcp, udp en icmp, daarmee was het ook langzaam helaas. Vanavond helaas geen tijd om te testen, dus het antwoord zal ik je even schuldig moeten blijven over de belasting.

Acties:

dinsdag 5 augustus 2008 17:38

☑Rekt | ☐ Not rekt

die show proc cpu kun je ook gewoon overdag doen, dat verandert niets in je config. Laat alleen zien hoe zwaar je cpu belast wordt.

Je kan ook sh proc cpu history doen, krijg je ASCII grafiekjes te zien, is meestal iets duidelijker.

Vicariously I live while the whole world dies

Acties:

dinsdag 5 augustus 2008 17:49

☑Rekt | ☐ Not rekt

Overigens, wat levert een ping op naar bijv. www.hotmail.com? en als je die continue laat draaien? En als daarin iets misgaat, wat levert dan tegelijkertijd een ping naar de lokale interface van je Cisco router op?

Vicariously I live while the whole world dies

Acties:

woensdag 6 augustus 2008 10:07

Heb je al eens overwogen de doos een keertje te rebooten ? Mischien heb je over een langere tijd allerlei configwijzigingen gemaakt (acl's aangepast, inspects en andere zaken) en is er "iets" blijven hangen.
Kan nooit geen kwaad het doosje eens een stamp te geven ;-) Zelfs een Cisco ;-)

Mogelijk moet je ook overwegen (indien je kennis ver genoeg reikt) om tussen het fastethernetje van de Cisco en je Internet modem een hubje te zetten en het PPPoE verkeer te sniffen/decoden (met Wireshark) zodat je kan volgen WAT ER EIGENLIJK PLAATSHEEFT.

Meten is weten zeggen wij hier in Belgie wel eens ;-)

Acties:

woensdag 6 augustus 2008 20:07

Topicstarter

Hij is al een keer gereboot, tijdens het wijzigen van al de acl's had ik de acls een keer aan de verkeerde kant gezet. Gelukkig was dat alleen de running config die ik gewijzigd had, stekker eruit en erin en ik kon weer in mijn eigen router.
PPPoE sniffen gaat mij net even boven mijn pet helaas. Ik hoopte eigenlijk dat ik enorm geblunderd had met de config en dat jullie mij zouden zeggen "wat een domme fout in die acl, doe dit en het werkt", maar kennelijk moet ik er toch nog iets dieper in duiken.
De cpu belasting tijdens browsen laten zien heeft wel avonduren nodig, want dat betekent dat ik internet op de cisco moet zetten, anders valt er weinig te browsen via de cisco, en die wijziging kan ik niet overdag doen, dan heeft onze mailserver geen internet meer, hoe tijdelijk dat ook is, dat is niet wenselijk.

Acties:

Verwijderd

Vreemd probleem, ik zou als eerste eens proberen met een kale configuratie (alleen dialer + nat)

Zodra je de cisco aansluit, draait er dan al wat over de VPN? Hoeveel verkeer denk je dat hier over heen gaat?

donderdag 7 augustus 2008 11:11

Acties:

donderdag 7 augustus 2008 11:56

Topicstarter

Ok weer een update.
Zonder ACL's werkte het hele verhaal helaas ook niet.

Omdat ik de PAT absoluut niet vertrouwde heb ik de opstelling veranderd.

De opstelling is ondertussen behoorlijk exotisch geworden. Linksys van de zaak (192.168.1.225) en modem van de zaak laat ik staan zodat onze mail server blijft draaien.
Van thuis meegenomen: Linksys van mijzelf, modem van mijzelf.

Op alle interfaces heb ik "no ip nat inside" of "no ip nat outside" gedaan.
Ik heb de dialer verwijderd en heb Fa0/1 als ip adres 192.168.9.2 gegeven.
De linksys van mijzelf heb ik tussen de modem van mijzelf en de cisco gezet met als ip adres 192.168.9.1.
De linksys en de Cisco ondersteunen beide RIP, dat heb ik aangezet om te voorkomen dat ik op de linksys tig statische routes aan moet maken naar mijn interne netwerken.
Op Fa0/1 zit nu inkomende acceslist Mathijs_inkomend en op Fa0/0.1 zit inkomende inspectrule Inpsect_Mathijs.
De situatie is nu dus dat de Linksys de PAT voor zijn rekening neemt en de Cisco de VPN.
VPN test ik later vandaag, maar al mijn pc's kunnen nu internetten.
Dit tot mijn teleurstelling, want ik wil dat de Cisco zelf de PPPoE doet en de PAT.

Wat mij nu behoorlijk dwars zit is de volgende vraag: "is mijn PAT configuratie nou fout of zit ik tegen een bug aan te kijken?"

Volgende acties: in mijn linksys forwards maken voor de vpn en testen of die werkt.

Acties:

donderdag 7 augustus 2008 16:52

Topicstarter

De VPN werkt ook in nieuwe opstelling, de Linksys laat het door naar de Cisco en er is verkeer mogelijk over de verbinding.

-edit-

De VPN is van zeer tijdelijke aard, een softwareleverancier van ons moet eens in de zoveel weken wat updaten, deze verbinding staat dus meer uit dan aan.

[ Voor 40% gewijzigd door MaVl op 07-08-2008 14:02 ]

Acties:

donderdag 7 augustus 2008 17:11

Topicstarter

Het probleem is opgelost, maar zat niet in de PAT.
Voor iedereen die hier misschien ook mee te maken krijgt hieronder de oplossing die ik tegenkwam op Cisco.com. Ik was aan het zoeken naar voorbeelden van PPPoE verbinding op andere types van routers om te zien of er overeenkomsten waren toen ik opeens de volgende tekst bij 1 van de types zag:

code:

Why can I access some web pages with PPPoE but not others? 
Access to only some web pages is a common problem when you run a PPPoE client on a router. By design, PPPoE can support an MTU of up to 1492 bytes. Therefore, you must ensure that end devices send out frames no larger than 1492 bytes. Limiting the MTU to 1492 bytes can be a problem because most PCs and end-user workstations have a default MTU of 1500 bytes. 

There are two options for adjusting the MTU size: adjust the MTU size at the router and adjust the MTU size at the PC.

Ik heb toen op alle sub interfaces ip tcp adjust-mss 1412 aangezet en het werkt als een zonnetje.

Waarom werkte het wel op mijn pc? Ik heb 1 van de oudste pc's in het bedrijf, en deze werkt met een nog wat lagere mtu.

Acties:

donderdag 7 augustus 2008 17:20

Aha, dat is uiteraard ook van belang, maar ik zag dat je dat reeds op de Dialer had staan en dacht dat het genoeg was ;-(

Nu kan ik best begrijpen dat je op de ethernet-kant dat ook moet "forceren" om dat gelijk te houden, anders heb je mischien van deze vieze problemen.

PS : Heb dat vroeger ook occasioneel gezien met L2TP/ATMP implementaties over dial met vb FTP dat "soms" werkt en "soms" ook niet (niet op Cisco, op Ascend)

PS2 : Met een sniffer had je dat direct gezien

Anywayz, blij dat het werkt!

[ Voor 5% gewijzigd door jvanhambelgium op 07-08-2008 17:12 ]

Acties:

donderdag 7 augustus 2008 19:05

☑Rekt | ☐ Not rekt

Hahaha tering zoiets simpels... nouja, mooi dat je erachter bent in ieder geval.

Vicariously I live while the whole world dies

Acties:

donderdag 7 augustus 2008 20:27

Karnemelk FTW

Zoiets simpels was het niet hoor dan had ik het wel meteen gezien

. Wel vreemd dat je router niet standaard ICMP packets stuurt als je probeert iets groter dan 1500 bytes te versturen.

Acties:

donderdag 7 augustus 2008 20:50

☑Rekt | ☐ Not rekt

TrailBlazer schreef op donderdag 07 augustus 2008 @ 19:05:
Zoiets simpels was het niet hoor dan had ik het wel meteen gezien . Wel vreemd dat je router niet standaard ICMP packets stuurt als je probeert iets groter dan 1500 bytes te versturen.

Nee, maar als ik PPPoE lees moet er bij mij eigenlijk standaard al een belletje gaan rinkelen "MTU size", aangezien ik hier meermaals tegenaan gelopen ben.

Vicariously I live while the whole world dies

Acties:

donderdag 7 augustus 2008 21:05

Topicstarter

Ik kan je wel vertellen dat ik dit mijn hele leven niet meer vergeet, ik heb wat zweetdruppeltjes gelaten hierover.
Maar ik ben gelukkig, draait als een zonnetje, de proxy werkt, vpn werkt, en morgen gaat er 2 factor authentication op met van die leuke tokentjes die getallen wisselen, dus dan mag hij voorzichtig iets meer open.

Acties:

donderdag 7 augustus 2008 21:45

Karnemelk FTW

Voor dit soort dingen is een packetsniffer ideaal. Als je op je Cisco
debug ip packet dump
doet. Kan je die output zelfs in wireshark invoeren dacht ik. Kijk hier wel mee uit want dit is de manier om je router onderuit te helpen. Eventueel kan je er nog een access-list aan hangen zodat je enkel verkeer van en naar en bepaalde host ziet. Dan wel ip route-cache weghalen van je interfaces.

Acties: