[Win2K] TS achter VPN

[Verwijderd]

Mijn Windows 2000 server heeft 2 nic's. Een nic heeft een publiek IP doordat ik SIP-spoofing op mijn Alcatel ST-510 heb gedaan. De andere nic hangt aan een switch en heeft IP 192.168.0.1. Andere PC's hangen aan dezelfde switch en krijgen van de Win2k server (DHCP) een IP in de range 192.168.0.2 tot 192.168.0.254. De Win2k server is tevens mijn (enige) domain controller.
Tevens heb ik NAT op de server geconfigureerd zodat de workstations kunnen internetten.
Ook heb ik een VPN opgezet op de server. Dit alles werkt prima en ik kan van buitenaf een VPN verbinding opzetten.
Nu wil ik echter dat de Terminal Service alleen van binnenuit benaderbaar is. Dus via VPN en/of via de private IP-range 192.168.0.x.
Als ik echter bij de interface aangeef dat alleen de nic met de private range TS mag afhandelen dan werkt dit wel binnen de private range (192.168.0.x) maar niet vanaf de VPN.
Hoe krijg ik dit voor elkaar?
Oh ja, detail nog, vreemd genoeg krijgt de computer welke via VPN verbindt een IP in de 169.254.110.x range hoewel ik heb aangegeven dat RRAS gebruik moet maken van de DHCP server.

[y2kbug]

zoals je al aangeeft gaat er wat fout met de ip's en daar ligt je probleem ook direct.
je configged het zo dat alleen 192.168.0.x pc's een TS connectie mogen en als je vpn pc's dan een 196.254.110.x krijgen gaat dat niet werken dus.

je zou kunnen kijken of je die range ook toe kan voegen zodat ze op de TS mogen connecten maar dat is natuurlijk niet heel netjes.
Ik zou eerder uitzoeken waar het fout gaat met het uitdelen van adressen door je dhcp

[Verwijderd]

y2kbug schreef op 03 maart 2004 @ 12:47:
zoals je al aangeeft gaat er wat fout met de ip's en daar ligt je probleem ook direct.
je configged het zo dat alleen 192.168.0.x pc's een TS connectie mogen en als je vpn pc's dan een 196.254.110.x krijgen gaat dat niet werken dus.

Nou, ik config het zo dat de nic met die range alleen TS-sessies mag aanmaken zodat van buitenaf geen TS-sessie meer gemaakt mag worden; komt dus bijna op hetzelfde neer maar is toch net iets anders.

je zou kunnen kijken of je die range ook toe kan voegen zodat ze op de TS mogen connecten maar dat is natuurlijk niet heel netjes.

Dat kan dus helaas niet want je kunt alleen een NIC kiezen, geen range.

Ik zou eerder uitzoeken waar het fout gaat met het uitdelen van adressen door je dhcp

DHCP heeft slechts een pool (192.168.0.x) dus het is me nu nog een raadsel. Kennelijk heeft RRAS zelf ook iets van een DHCP pool, kan alleen nog niet vinden waar ik dat kan uitzetten. Heb i.i.g. wel aangegeven dat ik gebruik wil maken van de DHCP die luistert op nic met range 192.168.0.x

[y2kbug]

de range 169.254.110.x is er eentje die windows automatisch toe wijst aan een kaart als de dhcp server niet gevonden wordt. als dit aan 2 zijden van een verbinding gebeurt dan werkt het dus wel maar niet helemaal netjes

het lijkt er dus op dat het ergens mis gaat met je dhcp relay over je rras

en dan het probleem dat je een nic moet selecteren over welke TS moet lopen is ook best wel lastig want het lijkt mij dus dat het met je vpn dan nog niet echt gaat werken gezien die op de andere nic zit(begrijp ik uit jouw verhaal).

dus hoe je dat dan weer op moet lossen weet ik zo 123 ook niet, misschien met een virtuele adapter en die ook toevoegen aan je TS.
Of het verkeer van je vpn op een of andere manier aan je interne nic koppelen(hmm dat klinkt best vaag)

[elevator]

Ik denk dat je je oplossing moet zoeken in het actief blokkeren van de inkomende poort 3389 op je NAT server.

Overigens hoop ik dat je sowieso al alles binnenkomend reject op die server behalve specifieke opengestelde poorten?

[Verwijderd]

Verwijderd schreef op 03 maart 2004 @ 12:38:
Oh ja, detail nog, vreemd genoeg krijgt de computer welke via VPN verbindt een IP in de 169.254.110.x range hoewel ik heb aangegeven dat RRAS gebruik moet maken van de DHCP server.

Dat is APIPA. Automatic Private IP Addressing. Ofterwijl een ip in de range die jij aangaf als de DhCP client geen IP adres krijgt.

Bekijk je settings eens, want ik denk dat je remote client geen IP adres krijgt over VPN.

edit:
sorry beetje laat

[ Voor 4% gewijzigd door Verwijderd op 03-03-2004 13:17 ]

[Verwijderd]

elevator schreef op 03 maart 2004 @ 13:10:
Ik denk dat je je oplossing moet zoeken in het actief blokkeren van de inkomende poort 3389 op je NAT server.

Maar wat moet ik dan als Destination invullen?

Overigens hoop ik dat je sowieso al alles binnenkomend reject op die server behalve specifieke opengestelde poorten?

Nee, mijn server staat dus gewoon volledig open. Ik laat wel automatisch alle updates installeren. Tevens heb ik File- and Printsharing uitgezet op de NIC welke aan het ADSL-modem hangt.
Hoe kan ik snel alle poorten blokkeren behalve degene die ik open wil hebben dan (VPN en eventueel nog wat andere poorten)?
Deze server is al een flink aantal weken 24/7 verbonden met i'net dus. Tot nu toe geen problemen gehad.

[ Voor 8% gewijzigd door Verwijderd op 03-03-2004 14:53 . Reden: Syntax foutje ]

[Verwijderd]

Het werkt nu. Voor de duidelijkheid zal ik nog even uitleggen hoe ik het werkend heb gekregen.
Eerst Disable Routing and Remote Access.
Vervolgens Configure Routing and Remote Access->Manual Configuration.
Eerst heb ik mijn NAT-server weer opnieuw ingesteld. Het bleek dat deze ook nog een IP-range had dus dit was waarschijnlijk een conflict met de DHCP server.
Vervolgens VPN (Remote Access) weer ingeschakeld.
Toen ik opnieuw een VPN verbinding opzette bleek dat ik nu wel een IP in de 192.168.0.x range kreeg.
Vervolgens heb ik TS dusdanig ingesteld dat deze alleen op de nic luistert welke aan het internet hangt; als ik nu nl. via mijn VPN Terminal Service zou starten dan zou deze het niet mogen doen. Dit bleek zo te zijn; tevens heb ik dit gedaan zodat ik altijd nog via i'net mijn TS anders kon instellen. Vervolgens heb ik TS dusdanig ingesteld dat deze alleen nog maar op nic van private range (192.168.0.x) zou luisteren.
Publiek was TS niet meer te benaderen. Via VPN wel. Precies wat ik wou!
PS. Ik sta nog wel open voor suggesties om server dichter te timmeren.

[ Voor 5% gewijzigd door Verwijderd op 03-03-2004 16:15 ]