VPN - NAT problems

[Destn]

Bij een klant heb ik volgend probleem:
VPN verbinding valt regelmatig weg, user moet dan wachten tot het VPN logon scherm terug verschijnt en kan na herinloggen terug een tijdje verder werken.

Nu beheren wij niet zelf die VPN (checkpoint) maar wel het zusterbedrijf.

Toen we het probleem voorlegden kregen we volgende uitleg.

-------------------------------

For setting up their VPN connection with the **** Group LAN more and more users are using a router/firewall box at home. This box then has a built-in DHCP server, providing your home pc with an IP address from one of the private ranges.
The **** Group Firewall (with which the VPN is set up) uses this IP address for the communication with your PC.
Now if 2 users have a VPN active at the same time using the same IP address on the PC at home (or another remote location), then the firewall will frees one session in favorite of the other. If then that other session sends traffic it will frees the first one and unfrees the last one to reactivate it. For example we have 2 VPN's: vpnA and vpnB. The remote pc's of vpnA an vpnB have the same internal IP address; for example 10.0.0.2. Traffic in vpnA is working fine. Then traffic is sent over vpnB. As they have the same remote IP address, the firewall will frees (pause) vpnA in favor of vpnB, which becomes active again. These switches are done rather fast and work fine as long as the traffic is not to heavy and there are not to much users with the same remote IP-address. But because companies standardize on internet equipment for home users, we are getting in the situation that more than 2 users have the same remote IP-address at the same time!
When several users start working at the same time they might have problems, because returning packets are send to the wrong sessions and replies are timing out!

To avoid this situation I want to assign as much as possible, a unique IP address to each Pc involved with a secureclient VPN.
PC's that get their IP address from the internet are not impacted, because they get a unique IP address.

.....
Dan nog een hoop blabla over het feit dat alle home users aangepast moeten worden.
----------------

Dit lijkt me een mooie uitleg maar houdt voor mij totaal geen steek.
Want als ik het NAT verhaaltje goed snap, wordt je intern IP address toch vertaalt naar je extern IP address door een extra pakketje rond je IP pakket te zetten?
Dus je gaat toch buiten met je publiek adres? In principe weet de company firewall toch niet af van het ipadres van de client?

Graag jullie commentaar hieromtrent.

[Verwijderd]

dus jullie loggen in naar het hoofdkantoor?

blijft het internet wel aan?

ik heb ook wel eens dat mijn internet er uit valt dit check ik vaak met een ping sturen naar google:
PING www.google.nl -t

als je dan een timeout krijgt kan dus ook je vpn er uit vliegen

Gr Sander

[Destn]

Verwijderd schreef op woensdag 26 april 2006 @ 15:18:
dus jullie loggen in naar het hoofdkantoor?

blijft het internet wel aan?

ik heb ook wel eens dat mijn internet er uit valt dit check ik vaak met een ping sturen naar google:
PING www.google.nl -t

als je dan een timeout krijgt kan dus ook je vpn er uit vliegen

Gr Sander

Zo te horen blijft internet aan en surfen ze via hun thuisnetwerk.

Maar hoe zit dat NAT-verhaaltje nu ineen? Klopt zijn redenering of niet?

[Verwijderd]

Het lijkt mij geen goede redenering,

ik heb ook een klant waarbij kantoren inbellen bij het hoofdkantoor, hier heb ik geen problemen mee
er zijn per kantoor 2 computers die eigenlijk de hele dag ingelogt zijn.

en dit heeft verder niets te maken met de thuis/kantoor gebruiker te maken
tenzij er in hun router uitgaand iets geblokt wordt, dit lijkt mij niet anders kunnen ze helemaal niets naar buiten toe

als zij verbinding krijgen met de server waarop ze inloggen en later van de lijn verbroken worden lijkt mij een probleem met het internet of met de server aan de andere kant of internet lijn aan de andere kant

[gammuts]

Verwijderd schreef op woensdag 26 april 2006 @ 15:40:
Het lijkt mij geen goede redenering

Mij wel.

Neem aan (zoals in het voorbeeld) dat 10.0.0.2 bij twee klanten gebruikt wordt en dat het bedrijfsnetwerk 10.10.10.0/24 is en dat de checkpoint als extern IP 66.66.66.66 heeft.

Een pakketje dat van klant A naar je bedrijfshost 10.10.10.10 gaat, heeft voordat het door de IPsec-mangel gaat, afzender 10.0.0.2 en destination 10.10.10.10. De IPsec-mangel beschouwt het complete pakketje als data. De afzender van het versleutelde pakketje is ook 10.0.0.2, maar de destination is nu 66.66.66.66 geworden. Dit versleutelde pakket kan richting klantrouter gestuurd worden. De klantrouter nat het afzenderadres naar zijn publiek IP-adres.

...Pakketje gaat internet over...

Het versleutlede pakketje komt aan bij de Checkpoint. De CP decodeert het bericht. Het originele (dus onversleutelde) pakketje wordt gestuurd naar 10.10.10.10. Voor 10.10.10.10 is het simpelweg van 10.0.0.2 gekomen.

...Nu komen we bij de ontknoping/crux...

Dus als 10.10.10.10 verkeer terug gaat sturen, zal ie dat naar 10.0.0.2 doen. Tot de CP is het onversleuteld. De CP gaat het weer versleutelen, en gaat het daarna sturen naar ... ? Ja, waar naar toe? Hij weet dat 10.0.0.2 ook voor klant B gebruikt wordt. Dus naar welke tunnel moet ie het 'routeren'? Ik zou het niet weten.


De Engelse uitleg zit wel vol met typefouten, maar de inhoud klopt wel. Ik heb het even op een iets andere manier proberen te zeggen. Ik hoop dat het je helpt.

[Destn]

Voor alle duidelijkheid, de Engelse uitleg is gequoteerd van een mail (dus niet van mezelf )

Ik heb wat opzoeking gedaan en kan me wel vinden in je uitleg. Alleen, dit is de enige klant bij wie dit fenomeen optreedt

Waarom hebben al de andere dan dit probleem niet?

Trouwens zijn oplossing vind ik echt 'not done'.

[Destn]

En dit heb ik van een ander forum:

Zolang de concentrator op een publiek IP adres zit zou er geen enkele probleem moeten zijn.
De PC (op een private IP) zet de VPN verbinding op, waarna de (home)router dit verkeer vertaalt naar een publiek IP adres (NAT). Elke sessie wordt verstuurd vanaf een uniek poortnummer op de home-router, en de concentrator ziet dit poortnummer dus.

Twee VPN sessies vanaf hetzelfde publieke IP adres (door NAT) hebben dus wel degelijk unieke kenmerken en de concentrator zou daar probleemloos mee om moeten gaan.

Ik heb deze situatie zelf draaien (voor zowel L2TP als PPTP) en met regelmaat meerdere VPNsessies vanaf een zelfde IP adres actief gezien.
(IPSEC komt pas veel later aan de orde, da's enkel encryptie van de payload!)

Waarschijnlijk zit het probleem gewoon in de aparte software die bij dit bedrijf gebruikt wordt. De leverancier lijkt mij dan verantwoordelijk voor het oplossen ervan. Hun antwoord dat je gepost had ziet er trouwens wel heel stoer uit, maar is klinklare nonsens aangezien hun concurrenten het wel netjes voor elkaar krijgen.

Simpelste en goedkoopste oplossing (die je misschien als alternatief kunt noemen voor de probleemgevallen): VPDN configuratie op een Cisco router bij het bedrijf, en op de clients gewoon de ingebouwde VPN optie van Microsoft gebruiken (draai een IPSEC image op de router en je hebt ook nog encryptie).
Authenticatie kan lokaal op de Cisco router of vanaf een radius server.
En da's enkel de authenticatie voor de netwerk verbinding. Alle verdere applicatie verkeer (bv. inloggen op een Windows domein) blijft z'n eigen beveiliging gebruiken.

[Equator]

gammuts schreef op woensdag 26 april 2006 @ 23:02:
[...]
Mij wel.

Neem aan (zoals in het voorbeeld) dat 10.0.0.2 bij twee klanten gebruikt wordt en dat het bedrijfsnetwerk 10.10.10.0/24 is en dat de checkpoint als extern IP 66.66.66.66 heeft.

Een pakketje dat van klant A naar je bedrijfshost 10.10.10.10 gaat, heeft voordat het door de IPsec-mangel gaat, afzender 10.0.0.2 en destination 10.10.10.10. De IPsec-mangel beschouwt het complete pakketje als data. De afzender van het versleutelde pakketje is ook 10.0.0.2, maar de destination is nu 66.66.66.66 geworden. Dit versleutelde pakket kan richting klantrouter gestuurd worden. De klantrouter nat het afzenderadres naar zijn publiek IP-adres.

...Pakketje gaat internet over...

Het versleutlede pakketje komt aan bij de Checkpoint. De CP decodeert het bericht. Het originele (dus onversleutelde) pakketje wordt gestuurd naar 10.10.10.10. Voor 10.10.10.10 is het simpelweg van 10.0.0.2 gekomen.

...Nu komen we bij de ontknoping/crux...

Dus als 10.10.10.10 verkeer terug gaat sturen, zal ie dat naar 10.0.0.2 doen. Tot de CP is het onversleuteld. De CP gaat het weer versleutelen, en gaat het daarna sturen naar ... ? Ja, waar naar toe? Hij weet dat 10.0.0.2 ook voor klant B gebruikt wordt. Dus naar welke tunnel moet ie het 'routeren'? Ik zou het niet weten.


De Engelse uitleg zit wel vol met typefouten, maar de inhoud klopt wel. Ik heb het even op een iets andere manier proberen te zeggen. Ik hoop dat het je helpt.

Op zich een leuk verhaal, maar dat gaat alleen op bij een site-2-site verbinding.
Normaliter krijgt een 'inbelende' vpn client een IP adres van de 'gebelde' VPN server (de VPN concentrator in dit geval)
Dit IP adres komt danwel uit een voor gedefinieerde pool met adressen of wordt door DHCP uitgedeeld.

Zolang dit een client is (iets dat niet routeerd) wordt er per client een host route aangemaakt op de VPN concentrator zodat hij weet waar hij de pakketjes heen moet sturen. Dat die client zelf een IP adres heeft aan zijn LAN zijde maakt de VPN concentrator niets uit.

Aan de andere kant, vanuit de client gezien kan je dit probleem wel hebben. Stel nou dat de client zelf een identieke IP range thuis gebruikt als op de zaak. En je wilt een pakketje sturen naar een IP adres. Wanneer de VPN client niet per default alle uitgaande IP pakketten over de tunnel gooit zou je client niet beter weten dat het pakketje lokaal afgelevert dient te worden.

Wanneer je het over een site2site koppeling hebt, kan je puur routing technisch gezien geen 2 sites aan een centraal punt koppelen wanneer beide sites een identieke ip range gebruiken. Op dat moment weet je centrale router inderdaad niet waar het pakketje heen zou moeten.

[engelbertus]

Destn schreef op woensdag 26 april 2006 @ 15:10:
Bij een klant heb ik volgend probleem:
VPN verbinding valt regelmatig weg, user moet dan wachten tot het VPN logon scherm terug verschijnt en kan na herinloggen terug een tijdje verder werken.

Nu beheren wij niet zelf die VPN (checkpoint) maar wel het zusterbedrijf.

Toen we het probleem voorlegden kregen we volgende uitleg.

-------------------------------

For setting up their VPN connection with the **** Group LAN more and more users are using a router/firewall box at home. This box then has a built-in DHCP server, providing your home pc with an IP address from one of the private ranges.
The **** Group Firewall (with which the VPN is set up) uses this IP address for the communication with your PC.
Now if 2 users have a VPN active at the same time using the same IP address on the PC at home (or another remote location), then the firewall will frees one session in favorite of the other. If then that other session sends traffic it will frees the first one and unfrees the last one to reactivate it. For example we have 2 VPN's: vpnA and vpnB. The remote pc's of vpnA an vpnB have the same internal IP address; for example 10.0.0.2. Traffic in vpnA is working fine. Then traffic is sent over vpnB. As they have the same remote IP address, the firewall will frees (pause) vpnA in favor of vpnB, which becomes active again. These switches are done rather fast and work fine as long as the traffic is not to heavy and there are not to much users with the same remote IP-address. But because companies standardize on internet equipment for home users, we are getting in the situation that more than 2 users have the same remote IP-address at the same time!
When several users start working at the same time they might have problems, because returning packets are send to the wrong sessions and replies are timing out!

To avoid this situation I want to assign as much as possible, a unique IP address to each Pc involved with a secureclient VPN.
PC's that get their IP address from the internet are not impacted, because they get a unique IP address.

.....
Dan nog een hoop blabla over het feit dat alle home users aangepast moeten worden.
----------------

Dit lijkt me een mooie uitleg maar houdt voor mij totaal geen steek.
Want als ik het NAT verhaaltje goed snap, wordt je intern IP address toch vertaalt naar je extern IP address door een extra pakketje rond je IP pakket te zetten?
Dus je gaat toch buiten met je publiek adres? In principe weet de company firewall toch niet af van het ipadres van de client?

Graag jullie commentaar hieromtrent.

je zegt wel dat je met het publieke ip adres naar buiten gaat, maar dat is natuurlijk niet helemaal waar. op de router die door het mailtje wordt bedoelt( deie dus switched en frres-t) wordt wel het private adres gezien, namelijk dat adres dat in de vpn wordt gebruikt voor communicatie. zolang die router het onderrscheid tussen adres 1 in vpn a en adres 1 in vpn b kan houden is er niks loos, maar zodra dat te ingewikkeld,wordt, en te snel moet, gaat het mis.

je zou dus voor je vpn's kunnen proberen andere ips te gebruiken dan de standaard ranges van je router.

1.x.x.x (vaak gebruikt 1.0.0.1 en verder)
of
168.192.x.x (vaak gebruikt 192.168.0.1 en verder)

probeer ranges te maken met 1.0.16.x of 168.192.16.x

dat is ook in de private ranges, maar niet in het segment waar de anderemensen hun pc's een naam geven.

bij een vpn communiceren immers pc op basisi van hun private ipadressen, zoals in het mailtje wordt gezegd. dus wat jij zegt over dat pc vanaf jou netwerk met een publiek adres communiceren gaat absoluut -juist niet!- op bij een vpn.

[engelbertus]

wij gebruyiken een vpn icm windows 2003 server. clients van een extern bedrijf verbinden geoon via de ingebouwde windows xp vpn wizard. dat heeft dan dus niets te maken met checkpoints die iets omzetten. alle tussenliggende punten in het netwerk moeten dan wel vpn verbindingen ondersteunen en gre-pakketjes kunnen afhandelen. soms is dat niet het geval.

verder werkt dat perfect. we hebben dan wel xs4all, met dus een vast ipadres op de adsl verbinding, zodat onze server kan worden gevonden door de clients.

[Equator]

engelbertus schreef op donderdag 27 april 2006 @ 08:08:
[...]

1.x.x.x (vaak gebruikt 1.0.0.1 en verder)
of
168.192.x.x (vaak gebruikt 192.168.0.1 en verder)

probeer ranges te maken met 1.0.16.x of 168.192.16.x

dat is ook in de private ranges, maar niet in het segment waar de anderemensen hun pc's een naam geven.
.

Je bedoelt hopelijk:
10.0.0.0 / 8 (255.0.0.0)
172.16.0.0 / 16 (255.255.0.0)
192.168.0.0 / 16 (255.255.0.0)
Dat zijn de ranges die je thuis kan gebruiken..

* Equator kwam laats bij een klant waar iemand een server had ingericht met een IP adres 100.100.1.100 / 8
Nee dat heeft nut

[engelbertus]

ja dat bedoel ik maar die met 172 wordt bijne nooit gebruikt door home routers als bedoeld in engelstalige e-mail, voor zover ik weet.

maar goed. wat denk jij dan dat ik bedoelde?

volgens mij is de schrijfwijze inclusief mask "ouderwets" , en met /8 oid modern voor hetzelfde.

en wat ik bedoelde is dat waar de x stond, je zelf iets kunt invullen..

het heeft misschien niet veel zin om een ip adres 100.100.1.100 te gebruiken, maar 10.100.1.100 kan een "makkelijk" adres zijn.
en soms verdeelt met het beschikbare deel van een ipdares in stukjes met het derde getal in het adres om bijvoorbeeld servers, werkstation, printers en modems en routers uit elkaar te houden, en de dhcp server bijvoorbeeld weer adressen uit een ander gebied te laten toekennen aan vpn verbindingen oid.
dat is dan voor de leesbaarheid van de ipadressen op schrijfnivo. op bit nivo schrijf je het met enen en nullen en dan lijkt zo'n adres indeling niet zo logisch.

[CmdrKeen]

Zelfde soort probleem gehad. Laat je gebruikers eens "Standaard-gateway in het externe netwerk gebruiken" aanvinken, kijken of dat helpt. Ze sturen dan ál hun verkeer over de VPN-verbinding en de VPN-server heeft dan geen weet van hun interne IP (voor zo ver ik het kan beredeneren - voor mij was dit de oplossing).

[Destn]

Vorkbaard schreef op donderdag 27 april 2006 @ 14:44:
Zelfde soort probleem gehad. Laat je gebruikers eens "Standaard-gateway in het externe netwerk gebruiken" aanvinken, kijken of dat helpt. Ze sturen dan ál hun verkeer over de VPN-verbinding en de VPN-server heeft dan geen weet van hun interne IP (voor zo ver ik het kan beredeneren - voor mij was dit de oplossing).

[afbeelding]

Goede tip, thx

[alt-92]

Destn schreef op woensdag 26 april 2006 @ 23:33:
Ik heb wat opzoeking gedaan en kan me wel vinden in je uitleg. Alleen, dit is de enige klant bij wie dit fenomeen optreedt

Waarom hebben al de andere dan dit probleem niet?

omdat die 192.168.2.x, 10.0.1.x, 192.168.3.x enzo gebruiken?
Controleer dat dan eens.

Trouwens zijn oplossing vind ik echt 'not done'.

Hoezo?

Hij geeft je een 100% zeker werkende oplossing.

Ik doe niet anders voor m'n werk.
Klant wil een werkende VPN, die krijgt ie ook, al moet ie daarvoor zijn thuisnetwerk voor overhoop gooien.

Elke thuiswerkplek heeft trouwens daarom ook een remote managed router staan.
Wij managen dat ding, das ook de enige manier om een managed VPN oplossing aan het werk te houden.

[ Voor 14% gewijzigd door alt-92 op 27-04-2006 20:46 ]

[engelbertus]

Vorkbaard schreef op donderdag 27 april 2006 @ 14:44:
Zelfde soort probleem gehad. Laat je gebruikers eens "Standaard-gateway in het externe netwerk gebruiken" aanvinken, kijken of dat helpt. Ze sturen dan ál hun verkeer over de VPN-verbinding en de VPN-server heeft dan geen weet van hun interne IP (voor zo ver ik het kan beredeneren - voor mij was dit de oplossing).

[afbeelding]

de vpn server heeft altijd kennis van het interne ip adres, anders zou er ook via het vpn nooit een pakket naar het juiste adres gerouteerd kunnen worden.

maar wat bedoel je met vpn server?

een ding dat ergens op internet staat en daar wordtbeheerd door derden?

probeer eens een directe vpn verbinding op te zetten? heeft dat bedrijf geen eigen server?

[Destn]

BackSlash32 schreef op donderdag 27 april 2006 @ 20:44:
[...]

omdat die 192.168.2.x, 10.0.1.x, 192.168.3.x enzo gebruiken?
Controleer dat dan eens.

[...]

Hoezo?

Hij geeft je een 100% zeker werkende oplossing.

Ik doe niet anders voor m'n werk.
Klant wil een werkende VPN, die krijgt ie ook, al moet ie daarvoor zijn thuisnetwerk voor overhoop gooien.

Elke thuiswerkplek heeft trouwens daarom ook een remote managed router staan.
Wij managen dat ding, das ook de enige manier om een managed VPN oplossing aan het werk te houden.

Wat als de gebruiker op hotel, e.d. zit?

Misschien werkt die oplossing wel, maar ik vind het niet de juiste manier.

[alt-92]

Destn schreef op zaterdag 29 april 2006 @ 18:34:
Wat als de gebruiker op hotel, e.d. zit?

Dan heeft ie pech
Of hij moet een Ipsec VPN client hebben die NAT-T support en eventueel aggressive mode aan hebben staan.
En zelfs dan ben je nog afhankelijk van
1) de routing (same IPrange werkt niet)
2) de filtering @ firewall van $hotel (geen 500 UDP/4500 UDP is geen verbinding. punt.)

Misschien werkt die oplossing wel, maar ik vind het niet de juiste manier.

Kan je wel vinden, maar het is toch echt zo.

[ Voor 19% gewijzigd door alt-92 op 29-04-2006 20:36 ]