[MS ISA 2004] VPN client access

[smoking2000]

De Omgeving
Om een aantal van onze homeworkers toegang te kunnen geven tot hun email, bestanden en dergelijke hebben we een VPN opgezet dmv IPCop Linux router/firewalls die toegang verschaffen tot ons netwerk op kantoor.
Op ons kantoor hebben wij 3 netwerk segmenten waar zij toegang tot moeten krijgen, welke geroute worden door een machine met MS ISA Server 2004 SP1 op Windows Server 2003 SP1.
De VPN werkt zonder problemen en men kan vanaf hun thuis netwerk op het netwerk segment tussen de IPCop router en de ISA Server komen.
Onderaan deze post staat een beknopte grafische weergave van ons netwerk.

Het Probleem
Nu zit ik met het probleem dat de gebruikers niet door de ISA Server kunnen komen. Al het verkeer met source addressen in een van de VPN netwerk segmenten word ge-denied.
Nou begreep ik uit de documentatie van ISA Server dat MS ISA in de routing table kijkt om te verifieren of verkeer via de correcte Interface komt om oa spoofing te detecteren.

Hoewel de VPN netwerk segmenten via de default gateway route gehandled zouden moeten worden, heb ik dit gepoogt op te lossen door expliciet een route aan te maken op de ISA Server voor de VPN netwerk segmenten, dit mocht helaas niet baten.

Ook heb ik geprobeerd door de VPN netwerk segmenten anders te definieren in de ISA Server. In eerste instantie waren zij aangemaakt als zijnde een "External Network", maar dit werkte niet. Daarna heb ik geprobeerd de segmenten aan te maken "Internal Network" en "Perimeter Network", ook dit mocht niet baten.

Een andere optie die wij bedacht hebben is een lelijke hack: het plaatsen van een NAT router tussen de ISA Server en de IPCop die al het verkeer van de VPN clients NAT, om de access control van de ISA server om de tuin te leiden. Dit implementeer ik liever niet, een hack is geen goede lange termijn oplossing.

Helaas is het voor ons geen optie om gebruik te maken van de VPN functionaliteit in de ISA server, omdat voor het gehele bedrijfsnetwerk besloten is om IPCop firewalls te gebruiken voor de VPN.

De Vraag
Mijn vraag is dus, hoe kan ik de ISA server configureren om clients, die vanuit een "Network behind a network" connecten naar een host in een netwerk ge-route door de ISA Server, toegang te geven tot die netwerk segmenten?

Moeten wij andere IP addressranges gaan gebruiken? Of is het mogelijk om iets in de ISA te configureren die dit mogelijk maakt (deze optie heeft mijn voorkeur)? Of is er een totaal andere oplossing waar wij nog niet aan gedacht hebben?

Network overview

[Verwijderd]

Ik neem maar even aan dat je het volgende wilt doen.

De externe computers in 10.31.3.x worden via een gateway to gateway vpn in het 10.31.4.x segment achter de IP Cop firewall geplaatst. Je ISA server routeert netjes alle pakketten naar 10.31.40.x en 10.31.44.x. Lijkt mij op zich geen enkel probleem.

Maar kunnen de computers die rechtstreeks in het 10.31.4.x segment zitten wél bij de resources achter de ISA Server?

[smoking2000]

Verwijderd schreef op donderdag 09 juni 2005 @ 12:10:
Ik neem maar even aan dat je het volgende wilt doen.

De externe computers in 10.31.3.x worden via een gateway to gateway vpn in het 10.31.4.x segment achter de IP Cop firewall geplaatst. Je ISA server routeert netjes alle pakketten naar 10.31.40.x en 10.31.44.x. Lijkt mij op zich geen enkel probleem.

Maar kunnen de computers die rechtstreeks in het 10.31.4.x segment zitten wél bij de resources achter de ISA Server?

Dat is inderdaad wat wij willlen berijken.

De computers in het 10.31.4.0/24 segment kunnen slechts beperkt bij de resources komen, gezien het 10.31.4.0/24 segment in de ISA onder het ingebouwde "External Network" valt, wat de bedoeling is.
We hebben daar nog wat servers en andere hosts staan die wij geen toegang willen geven tot de 2 segmenten achter de ISA server, slechts enkele hosts/services zijn daarvoor beschikbaar. Dit was ons oude interne netwerk, en alles wat daar nog in staat wordt door ons beschouwd als Untrusted Traffic, dus slecht services die publiekelijk beschikbaar zijn ook voor het 10.31.4.0/24 segment beschikbaar. Dit werkt naar behoren.

Wat mij opviel in de ISA monitorring was dat het verkeer vanuit 10.31.3.0/24 werd ge-denied maar er werd niet aangegeven werke Firewall Rule getriggerd werd. In de Firewall rules zijn voor het 10.31.3.0/24 segment veel meer services vrij gegeven dan voor het "External Network", dus aan de rules zou het niet moeten liggen.

[Verwijderd]

De default Netwerk relatie tussen internal en external is een NAT relatie. Hier zit waarschijnlijk je probleem, de route terug.
Verander de route relatie naar Route en je creeert door middel van die ISA bak een volwaardige Router, poorten openzetten op basis van subnet zou voldoende moeten zijn.

[smoking2000]

Verwijderd schreef op zaterdag 11 juni 2005 @ 12:42:
De default Netwerk relatie tussen internal en external is een NAT relatie. Hier zit waarschijnlijk je probleem, de route terug.
Verander de route relatie naar Route en je creeert door middel van die ISA bak een volwaardige Router, poorten openzetten op basis van subnet zou voldoende moeten zijn.

We hebben in de ISA geen NAT relaties gedefinieerd, alles is ingesteld op een router relatie.

Wat je zegt over subnets klinkt als wat ik ben tegen gekomen in het artikel Network Behind A Network (2004) - v1.1, alle remote netwerken dienen in hetzelfde netwerk object gedefinieerd te worden als het interne netwerk van de ISA server (10.31.4.0/24 in ons geval)

Deze setup gaan wij nu testen.

PS, excuses voor de late reply, inet storing thuis

[smoking2000]

Het is getest en deze manier blijkt te werken

Ipv een netwerk object aan te maken voor de VPN segmenten, die je deze als subnets te definieren. Deze subnet objecten kunnen dan in de Firewall policy gebruikt worden en werkt een network behind network wel.

[Verwijderd]

Deze subnet objecten kunnen dan in de Firewall policy gebruikt worden en werkt een network behind network wel.

Grappig, dat is namelijk precies wat ik ik poste.....:

poorten openzetten op basis van subnet zou voldoende moeten zijn.