Route problemen

[krietjur]

Allereerst even een (versimpeld) plaatje, wel zo duidelijk:



Ik zit te werken op m'n pc, IP 10.70.4.2. Mijn default gateway is 10.70.2.10 (een Linux machine). Deze machine verzorgt internettoegang en geeft toegang tot een paar andere subnets, die in dit verhaal verder niet echt relevant zijn. In het 10.70.0.0/16 netwerk hangt een VPN apparaat (Watchguard Firebox) die verbinding maakt met een locatie in Duitsland. Het subnet daar is 10.55.0.0/16. Het IP adres van dit VPN apparaat is 10.70.2.1. (en hetzelfde apparaat in Duitsland heeft 10.55.2.1).

Op de Linux router heb ik een route toegevoegd, om verkeer voor 10.55.0.0/16 te routeren via de Firebox (10.70.2.1).

Het probleem: als ik vanaf mijn PC een verbinding wil maken met een machine in het 10.55.0.0/16 netwerk, dan lukt dat niet altijd. Een RDP verbinding bijvoorbeeld lukt niet. Een telnet verbinding wel, al duurt dat de eerste keer vrij lang. Pingen lukt wel, de eerste ping duurt ook vrij lang. Zodra ik een keer gepingt heb naar de betrefende machine lukt een RDP verbinding ook ineens. Op de PC is dan door Windows een route toegevoegd (bijvoorbeeld 10.55.1.1 via 10.70.2.1), en communiceert dan dus rechtstreeks met de Firebox en niet meer via de Linux router.

Pingen vanuit het 10.55.0.0/16 netwerk naar het 10.70.0.0/16 netwerken lukt niet, tenzij ik handmatig de route naar 10.55.0.0/16 via de Firebox toevoeg. Als ik dan op de Linux router kijk, dan zie ik de echo replies langskomen. Echo requests gaan dus direct van de Firebox naar de PC, de reply blijft via de Linux router gaan (en komt vervolgens nooit ergens aan )

Wat doe ik fout?! Routes op mijn default gateway staan gewoon goed, dan zou ik toch zonder problemen een verbinding op moeten kunnen zetten? En ook andersom zou het toch gewoon moeten werken?

[TrailBlazer]

Controleer eens op al je devices de subnetmaskers. Verder denk ik dat er nogal veel gebruik gemaakt wordt van ICMP redirect en proxy-arp en dat zijn gewoon geen dingen die je graag wil hebben in je netwerk. Persoonlijk raad ik je aan om de VPN devices naar een dedicated subnet achter je router/firewall te verplaatsen zodat je een duidelijk routing punt hebt in je netwerk.
Op dit moment stuurt je PC verkeer voor 10.55.0.0/16 eerst naar de linux machine die ziet dan hee voor dat adres moet je een andere gateway op dit subnet gebruiken en zal daardoor een ICMP redirect gaan sturen.

[krietjur]

Ik heb alles nog eens gecontroleerd maar kan geen fouten ontdekken in de subnetmaskers.

Het lijkt me ook beter om de Firebox in een ander subnet te plaatsen (vanuit mijn 10.72.x.x en 10.71.x.x. heb ik ook geen problemen). Helaas is dit zo ingesteld door een colllega uit Duitsland en die is nogal eigenwijs zegmaar..

Blijft het vreemd dat dit niet werkt, want hoewel het beter zou kunnen, zou het zo toch ook moeten kunnen werken..

[TrailBlazer]

Ik weet niet hoeveel PC er in het subnet 10.70.0.0/16 staan (achterlijk subnet masker BTW) maar het handigste is dan om gewoon een persistent static route op die PC's te zetten. Niet mooi wel snel en eenvoudige oplossing.

De ping vanuit Duitsland werkt niet denk ik omdat de linux machine waarschijnlijk een statefull FW heeft en opeen ICMP replies langs ziet komen die hij niet verwacht en gewoon dropt.

[ Voor 29% gewijzigd door TrailBlazer op 06-11-2009 11:28 ]

[krietjur]

Aantal pc's zal zo rond de 200 zijn. Daarnaast de nodige printers, servers etc. Hele netwerk-structuur is bedacht door de Duitse collega en kan ik dus helaas niet van afwijken. Op de duitse locatie (en alle andere locaties die door hem zijn opgebouwd) is het precies zo ingericht, met het verschil dat ze daar een Cisco router gebruiken ipv de Linux router die ik hier gebruik. (de Linux router wordt hier ook nog vervangen door een Cisco, maar dat is nog even toekomstmuziek).

Dat de Linux FW het dropt klinkt wel logisch eigenlijk ja..

Ik kan het dus maar beter even hogerop zoeken in Duitsland denk ik om te zorgen dat de boel beter geconfigureerd wordt.

Bedankt!

[CaVeFiSh]

Ook al gedacht aan de routes op de clients, bijv:

ADD ROUTE 0.0.0.0 0.0.0.0 [gateway-IP]

Dit is ook een route die hij standaard zou aanmaken op het moment dat je je gateway naar je VPN server zou verwijzen. Gebruik dit alleen om te testen! Op het moment dat je nu dus wel kunt pingen betekend het dus dat de ICMP packet gedropt worden door je Linux router.

[pistole]

De reden dat je de additionele route in je tabel krijgt (rechtstreeks naar de vpn device) is dat het vpn device rechtstreeks antwoord geeft naar je client. Je client ziet dat als een 'directe' gateway naar het adres en zal hem, tijdelijk, toevoegen aan je route tabel.

Dit is in jou geval niet gewenst. Wat de makkelijkste oplossing is, is het toevoegen van een route op de vpn device, waarin staat dat alle adressen in het subnet benaderd moeten worden via de linux gateway.

Mooist is inderdaad dat je de vpn device in een ander subnet zet.

[CaVeFiSh]

Zoals ik al aan probeerde te geven is het een route die niet permanent dient te zijn, zit geen -p optie in de ADD ROUTE regel. Is om simpelweg te kunnen concluderen waar het fout loopt.

[krietjur]

Ik heb de collega kunnen overtuigen (wonderbaarlijk!) dat de VPN-box in een ander subnet plaatsen de beste oplossing is.

[TrailBlazer]

pistole schreef op vrijdag 06 november 2009 @ 12:31:
De reden dat je de additionele route in je tabel krijgt (rechtstreeks naar de vpn device) is dat het vpn device rechtstreeks antwoord geeft naar je client. Je client ziet dat als een 'directe' gateway naar het adres en zal hem, tijdelijk, toevoegen aan je route tabel.

nee hoor die extra route komt door een ICMP redirect van de linux server. Het zou ook een security risico zijn als een PC1 een pakket kan sturen naar een andere PC2 met een fake source adres en vervolgens PC2 al het verkeer voor dat subnet via PC1 gaat proberen te routeren. De TS geeft toch ook aan dat de ICMP replies richting linuxserver gaan en niet direct via de VPN doos.

Dit is in jou geval niet gewenst. Wat de makkelijkste oplossing is, is het toevoegen van een route op de vpn device, waarin staat dat alle adressen in het subnet benaderd moeten worden via de linux gateway.

Mooist is inderdaad dat je de vpn device in een ander subnet zet.

Een statische route zal nooit geprefereerd worden boven een connected interface met hetzelfde subnet. Tenzij de statische route more specific is. Je zou dus in theorie 2 keer een /17 kunnen toepassen dit is echt uberranzig.