[Cisco]NAT mapping met source translation...

[Verwijderd]

Hello, ik moet even gauw een mail fallback voor een klant opzetten op een extra internetverbinding. Wat ik niet wil is dat ik de default gateway van deze mailserver aan moet passen. Deze moet dus met zijn default gateway naar de bestaande firewall blijven wijzen.

Om dit te doen moet ik een vorm van nat source translation gaan toepassen, waarvan ik weet dat dit problemen oplevert. (Asymetrisch routeren) Echter ik kan mn vinger er niet achter krijgen waarom het niet werkt.

Extra router: 172.17.0.9 intern
Mailserver: 172.17.0.102 intern
Publiek ip: 194.109.a.b

Dit is wat ik nu erin heb gefrot, maar dit werkt niet. Pakket komt wel aan maar mailserver gooit het op zn default gateway naar buiten.

ip nat inside source static tcp 172.17.0.102 25 194.109.a.b 25 extendable
ip nat outside source static 194.109.a.b 172.17.0.102
Ja, dat is niet handig, aangepast zodat ik hide achter het private adres van de router
ip nat outside source static 194.109.a.b 172.17.0.9

Doh, dat slaat ook nergens op, zo verberg ik alleen verkeer als het afkomstig is van het publieke adres waarnaar gemailed word. Wat ik dus moet doen is alle verkeer van het internet aanpassen als het maar naar 194.109.a.b wordt gestuurd.

Ik dacht zoiets:
ip nat pool 1 172.17.0.9 172.17.0.9 netmask 255.255.0.0
ip nat inside source list 1 interface Dialer0 overload
ip nat inside source static tcp 172.17.0.102 25 194.109.a.b 25 extendable
ip nat outside source list 2 pool 1
!
access-list 1 permit 172.17.0.0 0.0.255.255
access-list 2 permit 0.0.0.0

Maar dat werkt dus ook niet. Man,man,man, met een netscreen of een checkpoint doe ik dit zo maar ik zit nou toch effe te kutten.

[ Voor 34% gewijzigd door Verwijderd op 11-08-2006 16:58 . Reden: Deed iets fout en aangepast... ]

[Metzie]

Je verhaal is lastig om te volgen, maar volgens mij wil je dat de interne host denkt dat het verkeer vanaf een lokale host komt. Ik heb nog niet zoveel cisco ervaring, maar ben je niet vergeten op de interfaces ip nat inside | ip nat outside te markeren?

Je moet eens kijken naar bijgaand document, nat on a stick. Volgens mij beschrijft dit wel redelijk jou situatie.

[Equator]

With Metzie.. ^^^

Als je de default GW van je exchange machine niet aan wilt passen (wat vrij logsch is) zal je ervoor moeten zorgen dat het emailverkeer lijkt alsof het van een lokaal station komt.
Je zal op je router dus en moeten portmappen (poort 25 naar binnen), en ook nog eens het source address moeten NAT'en.

[ Voor 9% gewijzigd door Equator op 14-08-2006 11:13 . Reden: Type + verduidelijking ]

[TrailBlazer]

gaan mailservers niet moeilijk doen als het source ip addres anders is dan de ip adressen in de headers. Ook kan je een probleem gaan krijgen als de dns namen verkeerd resolven volgens mij.
Overigens is je config wel goed alleen deze regel hoeft volgens mij niet.

ip nat inside source list 1 interface Dialer0 overload

overigens zal die server geen mail kunnen versturen natuurlijk. Volgens mij kan je trouwens ook een ander adres gebruiken. voor je statische translatie de router zal dan mbv proxy arp het verkeer naar zich toe trekken. Maar dat maakt niet heel veel uit verder

[ Voor 52% gewijzigd door TrailBlazer op 14-08-2006 11:49 ]

[Verwijderd]

Bedankt voor de antwoorden. Ik wil inderdaad dat het lijkt of verbindingen die van deze router binnenkomen lijken afkomstig te zijn van 172.17.0.9. (De Exchange server antwoordt anders over de andere verbinding die als default gateway ingesteld is)

Interfaces zijn inderdaad als als inside en outside gemarkeerd. De config werkt prima als ik even de default gateway aanpas, maar dat wil ik dus niet.

@Equator, Source adres wil ik inderdaad aanpassen en dat probeer ik ook te doen, maar de source is eigenlijk het hele internet wat ik ook in mijn laatste config probeer te proggen. (acl 2) Werkt helaas neit.

@TrailBlazer, mailserver verstuurd over de andere verbinding. Dit is puur een noodoplossing, de 2e lijn zal namelijk straks aan een load balancer gehangen worden en die regelt het dan allemaal. (Da's ook de reden dat ik geen gateways aan wil passen) Volgens mij moet die regel er wel in, dit is toch de regel die normaal genat verkeer door de router laat?

Ik zal het nat-on-a-stick dokkie es doorlezen.

[TrailBlazer]

Verwijderd schreef op maandag 14 augustus 2006 @ 15:48:
@TrailBlazer, mailserver verstuurd over de andere verbinding. Dit is puur een noodoplossing, de 2e lijn zal namelijk straks aan een load balancer gehangen worden en die regelt het dan allemaal. (Da's ook de reden dat ik geen gateways aan wil passen) Volgens mij moet die regel er wel in, dit is toch de regel die normaal genat verkeer door de router laat?

Ik zal het nat-on-a-stick dokkie es doorlezen.

Als je inderdaad andere machines wel wil laten internetten via deze verbinding dan moet deze regel er bij inderdaad. Voor de mailserver zelf is het niet nodig.

[Verwijderd]

Document doorgenomen en een aantal zaken geprobeerd. Probleem is dat ze in dit document 1 op 1 natten en ik moet 0.0.0.0/0 verbergen achter het interne IP adres van de router. Zou dit ook nog werken als ik access-list permit 0.0.0.0 gebruik en hieraan refereer?

[Verwijderd]

je zal inkomend verkeer moeten natten naar 172.17.0.9. tevens moet je je mail van buitenaf doorsturen naar je mailserver (port 25)

iig wat er gebeurt bij inkomend verkeer, bijv mailtjes van 1.2.3.4:

mail komt aan op je externe interface en wordt geforward naar je mailserver.
op de interne interface van de router: 1.2.3.4 wordt genat naar 172.17.0.9.
De mailserver handelt het af en stuur verkeer terug naar 172.17.0.9 (omdat dit directly connected is).
De nat rule transleert het weer naar 1.2.3.4 en de versturende party ontvangt jou pakketjes ook.

Hoe je dit doet en of het echt mogelijk is, geen idee, ik ben geen cisco man

Voor uitgaande email zie ik als de enige mogelijkheid om een externe relay host te gebruiken en een static route op je machine toe te voegen met de gateway naar de nieuwe router. of de static route op je oude router te zetten natuurlijk... Dit betekent echter wel handmatig switchen naar een relay host op het moment dat je normale verbinding eruit ligt.

[Verwijderd]

@iis5_rulez: wat betreft je nat mapping verhaal zou je inderdaad denken dat het zo werkt. Alleen wordt het originele source adres dus niet vervangen door 172.17.0.9 maar blijft hier het publieke adres staan. Resultaat is dat de Exchange server de mail over zijn default gateway naar buiten gooit.

Uitgaande mail is geen probleem, dit hoeft nog niet over de backup verbinding te lopen.

Iemand anders nog met dit bijltje gehakt?

[Clueless]

Ik denk dat je even duidelijkheid moet scheppen nu (voor mij dan in ieder geval). Je wil een 2de mailserver op een 2de verbinding of je wil dezelfde mailserver beschikbaar hebben op een tweede internetverbinding...

In het geval van de 2de is het dan niet mogelijk om dit met routing-protocollen op te lossen ipv moeilijk te doen met NAT? Je hebt NAT wel nodig maar niet voor dit deel denk ik.

Waar je mee zit is je routering. Je moet een secondary route aanmaken. Die moet dan weer voor mail verwijzen naar je mailserver. Je gateway heeft er volgens mij niet zo veel mee te maken dat je gateway aan de *binnenkant* blijft, dat is namelijk je standaardrouter. Je moet ervoor zorgen dat je bij een connection-failure gebruik maakt van een 2de verbinding.

Door gebruik te maken van een routing-protocol als OSPF (en gebruik te maken van route-metrics om prioriteit aan te geven) kan je dynamisch routeren. Door dat je primaire router ook je primaire internetconnectie is zal deze als beste uit de bus komen omdat deze i.i.g. 1 hop minder heeft naar je eindbestemming. Je extra router is altijd 1 hop extra verwijderd. Bij een connection drop wordt er een linkstate doorgeseind waarna de routering veranderd en je dus dynamisch kunt switchen. Zodra je main connectie weer up komt zal de routering weer terug worden aangepast.

In dit verhaal ben ik er van uit gegaan dat je 2 Cisco routers hebt. Voor meer informatie moet je maar even zoeken naar basic single-area OSPF. Dit is slechts een andere manier van je probleem oplossen....

offtopic:
Mijn Cisco is een beetje roestig, maar in theorie moet het kunnen

[Verwijderd]

Sorry voor mijn late reactie... druk, druk, druk.

@Clueless: OSPF heb ik ook overwogen maar dan werkt het pas zodra de mailserver doorheeft dat de andere gateway niet meer actief is. Mijn bedoeling was eigenlijk het systeem in te richten zodat beide verbindingen op ieder moment mail af kunnen leveren op dezelfde mailserver.

Ik ga overleggen wat ze van OSPF vinden, helaas is het andere apparaat niet een Cisco apparaat (Netscreen) dus dat kan het wat complexer maken.

[TrailBlazer]

OSPF is OPSF dus dat mag geen probleem zijn

[Zoetjuh]

Ik weet dat dit een oud topic is en mijn post is ook niet meer dan informatief. Ik zag echter nergens op gathering.tweakers.net een ander topic dat verder in gaat op Source Address Translation (ip nat outside source ...); dus vandaar.

Toevallig ben ik de laatste twee dagen met een vergelijkbaar probleem bezig geweest. Na wat onderzoek en testen heb ik uiteindelijk echter een oplossing gevonden.

Situatie:
Server NIC #1: 10.0.0.10 (gw: 10.0.0.1).
Server NIC #2: 192.168.1.2 (geen gw)

Router #1: 10.0.0.1 (voor al het normale verkeer)
Router #2: 192.168.1.1 (de 2de lijn die we voor sommige inbound connecties willen gebruiken)

Al het verkeer (dat niet op een direct connected subnet zit; of waarvoor niet speciaal een static route is aangelegd) wordt via de def. gw (via NIC #1) verstuurd. Wanneer internet verkeer via Router #2 binnen komt, wordt dit normaal via Router #1 weer verstuurd. Dit werkt / willen we natuurlijk niet.

De reden dat ze via Router #1 worden verstuurd is simpel; de source van het ontvangen packet geeft aan dat het van het internet af komt. Om dit op te lossen zullen we source-address translation moeten gaan gebruiken.

De stukken config die van belang zijn

code:

interface Vlan1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
interface Dialer0
 ip address negotiated
 ip nat outside
!
ip route 0.0.0.0 0.0.0.0 Dialer0 permanent
ip route 192.168.2.0 255.255.255.0 Dialer0
!
ip nat pool NieuweSourcePool 192.168.2.1 192.168.2.254 netmask 255.255.255.0
ip nat inside source static 192.168.1.2 <public IP> extendable
ip nat outside source list 100 pool NieuweSourcePool add-route
!
access-list 100 permit ip any any
access-list 100 permit gre any any

In dit geval zijn er meerdere IPs door de ISP toegewezen aan deze lijn, waardoor ik niet sommige poorten op het Dialer0 IP NAT, maar het complete IP. Via ACLs op Dialer0 wordt dit boeltje veilig gehouden. In een omgevng waar maar één public IP wordt toegekend, zou een "ip nat inside source static tcp 192.168.2.1 3389 interface Dialer0 3389" in dit geval ook goed zijn om port 3389 PAT/NATten.

De oplossing
Voor alle inkomende packets die voldoen aan source list 100, zal het source address worden aangepast naar een vrij IP uit de "NieuweSourcePool" pool. In dit geval is dat 192.168.2.x. Door de wel bekende "ip nat inside source..." wordt na de source translation, de desination getranslate en komt de packet aan op de server.

Op de server heb ik een permanent route aangemaakt voor 192.168.2.0/24 welke naar 192.168.1.1 (op NIC #2) wijst. De server zag van de ontvangen packet een source IP 192.168.2.x en zal de antwoord-packet aan de hand van de permanent route naar Router #2 sturen.

Op Router #2 is de packet nu op de LAN interface ontvangen. Om er voor te zorgen dat de source-address-translation weer ongedaan wordt gemaakt (in dit geval de destination van de uitgaande packet), moet deze packet door de NAT worden geroutereerd. Dit is dan ook de reden dat er binnen Router #2 naast de default route, ook voor 192.168.2.0/24 nog een route staat om packets over de Dialer te sturen. Zonder deze laatste routing regel op Router #2 zullen packets blijven "hangen" op de LAN interface van de router en zal de packet het internet nimmer meer zien.