NGT: Bug i Cisco 677i-DIR-ruteren?

[Martin Lie]

Heisann,

 

Jeg har et snodig problem med Cisco-ruteren til NextGenTel (Cisco 677i-DIR). Problemet jeg har er at det virker som om Cisco-en har en eller annen algoritme som i forbindelse med NATing skriver om innholdet i pakkene, og ikke bare i UDP/TCP-headeren.

 

Case: Har DNS-server på innsiden av en NAT-ruter. Ved oppslag mot localhost på serveren returneres riktig IP, ved oppslag mot ekstern IP returneres alltid den eksterne IP-en som svar på samtlige DNS-forespørsler.

 

Har dumpet trafikk på port 53 (DNS) på serveren, og det er tydelig at Cisco-en skriver om innholdet i UDP-datagramet som returneres fra DNS-serveren:

 

[/root]# tcpdump -pen -i rl0 port 53

tcpdump: listening on rl0

1. 69: 10.10.37.198.1690 > 80.203.226.24.53: 9894+ A? www.vg.no. (27)

2. 69: 80.203.226.24.26005 > 10.10.37.198.53: 9894+ A? www.vg.no. (27)

3. 231: 10.10.37.198.53 > 80.203.226.24.26005: 9894- 1/4/3 A 193.69.165.20 (189)

4. 231: 80.203.226.24.53 > 10.10.37.198.1690: 9894- 1/4/3 A 80.203.226.24 (189)

 

(Linjenumrene er lagt til i etterkant, og er ikke med i original dump.)

 

Dette viser altså et klientprogram (dig) på serveren, som kjører forespørsel mot server-programmet på samme server (named) via ekstern IP. Legg merke til at IP-adressen som returneres fra DNS-serveren skrives om av Cisco-en fra linje 3 til 4 her.

 

1. Forespørselen sendes først fra klienten på port 1690, til ekstern ip (80.203.226.24) på port 53.

2. Den blir NATet inn til serveren på intern ip (10.10.37.198) port 53.

3. DNS-serveren finner IP-en til www.vg.no og svaret blir sendt ut til ekstern ip igjen.

4. Svaret blir til slutt NATet tilbake til klienten på port 1690, men nå er svaret som serveren sendte omskrevet.

 

Ved den siste NAT-omskrivingen her, blir IP-adressen som DNS-serveren sendte (193.69.165.20) omskrevet til 80.203.226.24, og dessuten dukker følgende NAT-oppføring opp i ruteren:

 

Local IP - - - - - - Global IP - - - - - - Timer Flags - - Proto - Interface

193.69.165.20:13568 80.203.226.24:26071 120 0x00046 udp eth0 wan0-0

 

Det ser altså ut som om ruteren har oppfattet 193.69.165.20 som en intern IP som skal NATes ut til omverdenen. Men på innsiden eksisterer selvsagt kun interne IP-er (på 10.10.37.0/24-nettverket), og hvertfall ikke VG sin IP! Dette gjør at det er umulig å hoste domener på en DNS-server bak Cisco-ruteren, ettersom alle hoster som hostes får IP-adressen 80.203.226.24.

 

Hvorfor i all verden skjer dette? Har noen en idé? Bug i Cisco-ruteren, eller en algoritme som har slått seg litt vrang (og som kanskje kan disables?)

 

Ciscoen har forresten følgende versjon:

CBOS 677i Software (C677i-I-M), Version v2.4.7 - Release Software

[Martin Lie]

Fant en workaround som funket. Den står beskrevet her.

 

Mange takk til Zenith på #nextgentel@EFnet som tipset meg om dette! Og til Thor, som tok seg tid til å publisere løsningen på problemet sitt da han fant det.

 

Quoter løsningen her også, i tilfelle ovennevnte URL går ned:

 

 

Thor> Problemet er at 677 omskriver alle A og PTR records i

Thor> DNS queries så de ser ud til at komme fra dens eksterne

Thor> IP. Det er jo unægteligt en smule irriterende når det ikke

Thor> er den adresse der skulle have stået! Er der nogen som

Thor> har oplevet dette problem og eventuelt fundet en måde

Thor> at disable denne feature?

 

Har løst problemet! 677 laver ikke om på DNS requests hvis man laver

en NAT entry som "forwarder" port 53 til en anden port. Så en patched

udgave af tinydns har løst problemet.

 

/Thor

 

Har nå lagt til følgende NAT entry i Cisco-en:

set nat entry add 10.10.37.198 253 0.0.0.0 53 *

 

Og deretter satt opp DNS-serveren til å lytte på port 253. Nå skjer ingen omskriving av adressene i data-delen. Juhu!

[Loomy]

Bare meg som ikke forstod en dritt av det? :o

[jokki]

Bare meg som ikke forstod en dritt av det? :o

det var ikke bare deg.

Kan du Nat geniet hjelpe meg og si hvordan jeg forwarder port 4462/4461 4465 på min netopia 3351???

[Loomy]

Finfin guide til port forwarding på http://www.relativt.net :wink:

[jokki]

får det fremdels ikke til etter å ha gjort som det stod

[Corn]

I følge forklarelsen på www.relativt.net til hvorfor msn filsending ikke virker med NGT, så er det fordi routeren endrer ip-addressen på TCP-pakken til din lokale IP (10.0.0.x)

 

Det var jo noe av det samme som skjedde her, altså routeren endret en ip-addresse som ble sendt ut.. Siden du fant en løsning på dette problemet, er det ikke mulig på en lignende måte å løse msn-filsending problemet?

 

Altså å hindre at routeren endrer addressen på TCP-pakken?

 

Godt mulig at jeg er helt på jordet her, men man kan jo håpe

[Martin Lie]

Du er litt på jordet, men ikke helt.

 

Ruteren bruker NAT, som omskriver IP-adressen som er i headeren til TCP-pakken. Dette er slik det skal være, for å få maskiner med "interne" ikke-offentlige IP-adresser (som 10.0.0.x) til å kommunisere med maskiner som har offentlige Internett-adresser.

 

Det som skjedde i mitt tilfelle (det som startet tråden) var at ruteren også endret på IP-adresser som var i data-delen av TCP-pakken. Data-delen skal uansett ikke berøres av NAT, og dette var derfor en bug eller et forsøk fra Cisco sin side på å legge til ny funksjonalitet i ruteren, men som i praksis fikk uheldige konsekvenser for meg.

 

Vanlige NAT-oppføringer (aka "åpning av porter") skal være lett å legge til, i henhold til f.eks. guiden til relativt.net, men den workarounden som jeg fant hadde ikke noe direkte med NAT å gjøre, og vil heller ikke være en løsning dersom man har problemer med NAT.