ISA2006 multiple weblisteners?

[Verwijderd]

Huidige situatie:
ISA 2006 server (single adapter config, domain member)
Ik heb één weblistener tbv OWA via port 443, deze is voorzien van een commercieel certificaat. OWA draait prima vanaf zowel intern als extern.

Nu wil ik graag een nieuwe (secure) website publiseren via ISA, namelijk t.b.v. de RDP web connection service.

Ik heb op een seperate server in het domein RDP webconnection geïnstalleerd en dat draait goed, ik kan daar vanaf het LAN gebruik van maken.

Nu wil ik de site ook extern beschikbaar maken en dus publiseren via ISA. Ik heb ondertussen een certificaat aangemaakt via mijn eigen CA (dit wordt ondersteund voor de rdp webconnection service) en deze geëxporteerd naar pfx en op de ISA server geïmporteerd tezamen met het root CA. Uiteraard DNS bij mijn provider aangepast zodat requests naar https://tsweb.mijndomeinnaam.nl correct aankomen (en uiteraard heeft het certificaat de public name tsweb.mijndomeinnaam.nl).

Als ik nu een tweede weblistener aanmaak op ISA, met dezelfde poort (namelijk 443 voor SSL) en hetzelfde ipadres (omdat het een single adapter config is) dan gaat dit niet werken.
Heeft iemand suggesties hoe mijn doel te bereiken? Kan ik dit met twee weblisteners instellen en toch SSL blijven gebruiken voor zowel OWA als de RDP Web connection?
Of kan ik één weblistener gebruiken voor beide services en zo ja, hoe configureer ik dat dan?

Op mijn DC na (W2K8) draait alles op W2K3 R2 X64.

Alvast bedankt voor het meedenken.
MB

[mbaltus]

Met Host headers moet dit prima kunnen.

[ZeRoC00L]

Extra IP-Adres op je netwerkkaart zetten, je DNS aanpassen naar het nieuwe IP-adres en je weblistener aanpassen naar het nieuwe adres.

[Verwijderd]

ZeRoC00L schreef op donderdag 22 mei 2008 @ 14:14:
Extra IP-Adres op je netwerkkaart zetten, je DNS aanpassen naar het nieuwe IP-adres en je weblistener aanpassen naar het nieuwe adres.

Ja dat zou ik wel kunnen proberen, alleen vindt ik het dan netter om een extra nic te plaatsen. Misschien dat ik dat wel ga doen en dan meteen maar een DMZ maken (stond toch al op de planning). Bedankt voor het meedenken!

[ZeRoC00L]

Verwijderd schreef op donderdag 22 mei 2008 @ 17:52:
[...]


Ja dat zou ik wel kunnen proberen, alleen vindt ik het dan netter om een extra nic te plaatsen. Misschien dat ik dat wel ga doen en dan meteen maar een DMZ maken (stond toch al op de planning). Bedankt voor het meedenken!

Een extra NIC plaatsen maakt het alleen maar ingewikkelder, het is echt geen probleem meerdere ip-adressen toe te kennen aan 1 nic.

[Verwijderd]

ZeRoC00L schreef op donderdag 22 mei 2008 @ 19:09:
[...]

Een extra NIC plaatsen maakt het alleen maar ingewikkelder, het is echt geen probleem meerdere ip-adressen toe te kennen aan 1 nic.

Het toekennen van een extra IP adres is niet het probleem. Maar op het moment dat ik dat doe werkt het nog steeds niet

Ik heb nu twee ip adressen op mijn Nic geconfigureerd.

Binnen ISA heb ik twee listeners geconfigureerd:
1x tbv mijn webmail (webmail.mijndomeinnaam.nl) met een commercieel certificaat
1x tbv RDP webconnection (tsweb.mijndomeinnaam.nl) met een private certificaat (via eigen CA)

Ik heb twee web publishing rules aangemaakt, 1x voor webmail en 1x voor tsweb
Webmail werkt prima maar tsweb niet.

Als ik browse naar de site https://tsweb.mijndomeinnaam.nl dan geeft IE een error (naast de adresbalk):"Certificate error: Mismatch Address"
En verschijnt in de browser zelf de error:
Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)

Als ik de error verder bekijk dan valt me op dat ie probeert gebruik te maken van het certificaat webmail.mijndomeinnaam.nl en niet van tsweb.mijndomeinnaam.nl?
Dat vindt ik wel erg vreemd omdat ik er zeker van ben dat ik de certificaten juist geconfigureerd heb
en aan de juiste listener gekoppeld heb.

Ik zie binnen ISA monitoring het verzoek wel binnenkomen, echter is het hier weer vreemd dat ik een Denied Connection op de default rule krijg. Het verzoek lijkt dus niet eens aan te komen bij de juiste rule.

Suggesties zijn welkom en alvast dank daarvoor!

[ Voor 11% gewijzigd door Verwijderd op 26-05-2008 12:20 ]

[Verwijderd]

mbaltus schreef op donderdag 22 mei 2008 @ 13:04:
Met Host headers moet dit prima kunnen.

Bullshit

met hostheaders kan je meerdere sites scheiden, echter per ip kan je slechts 1 ssl cert hebben.
Je kan dus 2de site aanmaken met ssl, maar die krijgt dan altijd een certificaat error dat de domain name niet klopt (tenminste in isa2004, in 2006 zou dit wel eens echt een probleem kunnen zijn )

Wat wel kan is een wildcard cert gebruiken. *.domain.name voor zowel www1.domain.name als www2.domain.name. Of die certs worden uitgegeven als commercieel cert betwijfel ik overigens...

edit: ah je hebt intussen een 2de ip, maar je lijkt nu problemen te hebben met incorrecte hostheaders. Zorg dat je isa de naam "externe" dns naam resolved naar de interne webserver en dus je verkeer doorstuurt met dezelfde dns naam als die je buiten gebruikt (vaak is hostfile editen het makkelijkst).

[ Voor 19% gewijzigd door Verwijderd op 27-05-2008 11:30 ]

[Verwijderd]

Ik heb idd een 2e ip.
DNS zal ik nog een keertje goed nalopen, maar ik dacht dat je de hostheaders in de Web Publish Rule insteld? Ik geef namelijk in mijn rule (via tabblad "TO") de interne naam op van de webserver (dus hoe ik de site ook vanaf het LAN benader http://servernaam/tsweb) en ik geef als public name de extrene naam op, tsweb.mijndomeinnaam.nl.

[Verwijderd]

Verwijderd schreef op dinsdag 27 mei 2008 @ 11:27:
[...]
edit: ah je hebt intussen een 2de ip, maar je lijkt nu problemen te hebben met incorrecte hostheaders. Zorg dat je isa de naam "externe" dns naam resolved naar de interne webserver en dus je verkeer doorstuurt met dezelfde dns naam als die je buiten gebruikt (vaak is hostfile editen het makkelijkst).

Ik heb DNS nagelopen en volgens mij is hier niks mis mee. Vanaf ISA wordt DNS goed doorgelaten, het werkt immers ook op deze manier voor mijn webmail, hiervoor heb ik verder niks in DNS of de hostfile hoeven wijzigen....(of doel je op SplitDNS?)

Voor zover ik ISA begrijp en zoals ik het vaker geimplementeerd heb (bijv. met mijn webmail omgeving), geef je in de Web Publish Rule aan welke hostheaders gebruikt worden. De rule zal dan het verzoek herkennen wat afkomstig is vanaf een externe client welke tsweb.mijndomeinnaam.nl intypt en zal het doorsturen naar de interne webserver....

[ Voor 9% gewijzigd door Verwijderd op 28-05-2008 09:24 ]

[deadlock2k]

-

[ Voor 100% gewijzigd door deadlock2k op 06-08-2021 15:47 ]

[deadlock2k]

Je kan trouwens toch ook publishen zonder listener? Waarom probeer je dat niet eerst?

[Verwijderd]

deadlock2k schreef op woensdag 28 mei 2008 @ 16:12:
[...]

Bullshit zoals je zelf al zo mooi zegt.

Hoezo zou dat niet kunnen. Je kan certificaten aanvragen op hostname of op IP. Het een sluit het ander niet uit. Als je bijvoorbeeld één certificaat gebruikt voor een grote serverfarm en je werkt met round robin, dan heb je dus één certificaat voor meerdere IP's maar dezelfde hostname.

Nee hoor. Je vraagt altijd een cert aan op dnsname (ip zou kunnen, maar dan is de naam slechts gelijk aan het ipnummertje ). Alleen wordt je cert wel degelijk aan een ip gekoppeld.
In de situatie die jij schetst heb je meerdere kopie-en van 1 certificaat op meerdere ip's. Dat is mogelijk, maar het is onmogelijk om op 1 ip 2 certs te hebben... Oftewel hostheaders werkt niet (hostheaders werkt alleen vanaf http versie 1.1 en niet met een vorm van encryptie die in principe los staat van http, ssl in dit geval)

[ Voor 4% gewijzigd door Verwijderd op 28-05-2008 16:38 ]

[Verwijderd]

Verwijderd schreef op woensdag 28 mei 2008 @ 09:19:
[...]


Ik heb DNS nagelopen en volgens mij is hier niks mis mee. Vanaf ISA wordt DNS goed doorgelaten, het werkt immers ook op deze manier voor mijn webmail, hiervoor heb ik verder niks in DNS of de hostfile hoeven wijzigen....(of doel je op SplitDNS?)

Voor zover ik ISA begrijp en zoals ik het vaker geimplementeerd heb (bijv. met mijn webmail omgeving), geef je in de Web Publish Rule aan welke hostheaders gebruikt worden. De rule zal dan het verzoek herkennen wat afkomstig is vanaf een externe client welke tsweb.mijndomeinnaam.nl intypt en zal het doorsturen naar de interne webserver....

ik weet het niet zeker bij 2006, maar het was altijd het geval dat je de interne dnsnaam gelijk moet zijn aan de externe dns naam. aangezien dit vaak niet het geval is, moet je een truck uithalen (split dns idd of hostfile editen).

Zo werkt het iig:

extern connecten naar ssl.web.site
weblistener requests doorsturen naar ssl.web.site (http/https wat je wilt) en dus eventueel zorgen dat ISA deze url resolved naar het ip van de interne webserver.
ssl.web.site geconfigureerd hebben in iis als hostheader van de website.

Mocht het nog niet lukken geef even de logregels van IIS en van ISA. (iis vnl om te zien of er uberhaupt wel requests heen gaan )

[Verwijderd]

deadlock2k schreef op woensdag 28 mei 2008 @ 16:17:
Je kan trouwens toch ook publishen zonder listener? Waarom probeer je dat niet eerst?

Ik heb dat nooit eerder gedaan en vraag me ook af of dat werkt, hoe weet ISA wat ie moet doorsturen en naar wie?? Maar als jij een manier weet....

[BlaTieBla]

Enige manier om dit op te lossen is om de tweede ssl listener op een andere poort te laten luisteren (444 bijvoorbeeld) en voor die url een apart certificaat te nemen.
je url wordt dan https://tsweb.domein.nl:444/etc.
Iedere andere manier vereist een tweede publiek IP adres.
Hostheader werken alleen bij http verkeer, omdat de host info verpakt zit in de payload en die is bij SSL versleuteld, dus de webservice kan niet zien waar het afgeleverd moet worden.

En qua certificaten en prijzen: voor versleuteling van de informatie over het internet net maakt het niet uit of je een certificaat van 30 USD heb of 1500 USD. Ze versleutelen allemaal even goed (2048bit public key / 128bit SSL). Het verschil zit in het vertrouwen en het verzekerde bedrag. In de omgeving van de TS voldoet een 30 USD (godaddy) perfect.
En als de TS de enige gebruiker is of de gebruikersgroep beheersbaar is, dan kan een eigen MS CA ook gewoon gebruikt worden. Kwestie van de root onder de 'deelnemers' verspreiden om 'vage' ssl waarschuwingen te voorkomen.

[ Voor 43% gewijzigd door BlaTieBla op 28-05-2008 19:37 ]

[Verwijderd]

BlaTieBla schreef op woensdag 28 mei 2008 @ 19:30:
Enige manier om dit op te lossen is om de tweede ssl listener op een andere poort te laten luisteren (444 bijvoorbeeld) en voor die url een apart certificaat te nemen.
je url wordt dan https://tsweb.domein.nl:444/etc.

Ik heb dit zojuist geprobeerd maar nu komt het verzoek niet eens binnen op ISA?
De URL met toevoeging :444 begrijp ik en ik heb een nieuw certificaat aangemaakl met als SSL poort 444 geconfigureerd. Hoe stel ik de listener en publish rule in?

[BlaTieBla]

de listener hoort op 444 te staan. Hoe de koppeling voor de RDP aan de binnenkant verloopt... geen idee. Ik neem aan dat je connect naar de ISA server op basis van SSL (poort 444) en dat de ISA dat doorzet (al dan niet reverse proxy-achtig) naar de betreffende RDP host. Die laatste koppeling geen idee.
Misschien moet je eens buiten je publish wizards omdenken en het regel-voor-regel in de ISA kloppen.

[alt-92]

BlaTieBla schreef op woensdag 28 mei 2008 @ 20:34:
de listener hoort op 444 te staan. Hoe de koppeling voor de RDP aan de binnenkant verloopt... geen idee.

Daarvoor moet je op een SBS doos 4125 gebruiken, en 'normale' TS 3389.

Tenzij je Terminal Server Gateway gebruikt maar dan wil je 443 weer kunnen gebruiken.

[axis]

Heb bij een klant ook een oplossing staan waarbij een ISA 2006 een stuk of 10 ip's op zijn stack heeft staan, met 3 SSL listeners op een apart ip, geen probleem. (OWA2007, TS-Gateway en custom webapp)

BlaTieBla schreef op woensdag 28 mei 2008 @ 20:34:
de listener hoort op 444 te staan.

HTTPS is toch echt poort TCP/443..

deadlock2k schreef op woensdag 28 mei 2008 @ 16:12:
Hoezo zou dat niet kunnen. Je kan certificaten aanvragen op hostname of op IP. Het een sluit het ander niet uit. Als je bijvoorbeeld één certificaat gebruikt voor een grote serverfarm en je werkt met round robin, dan heb je dus één certificaat voor meerdere IP's maar dezelfde hostname.

Zoals hierboven al opgemerkt heb je inderdaad meerdere kopien voor 1 cert..

Het is inderdaad (nog) niet mogelijk om op basis van host headers te differentieren tussen SSL sites, omdat de host header mee ge-encrypt wordt in de HTTP request. En die HTTP request moet door 1 specifieke site met SSL cert decrypt worden. Dus kun je maar 1 cert op 1 combinatie ip/poort laten luisteren..

Gelukkig kun je ISA inderdaad gewoon zoveel IP's op alle netwerkkaarten geven als je wilt..

[BlaTieBla]

axis schreef op donderdag 29 mei 2008 @ 08:51:
Heb bij een klant ook een oplossing staan waarbij een ISA 2006 een stuk of 10 ip's op zijn stack heeft staan, met 3 SSL listeners op een apart ip, geen probleem. (OWA2007, TS-Gateway en custom webapp)


[...]

HTTPS is toch echt poort TCP/443..


[...]

Zoals hierboven al opgemerkt heb je inderdaad meerdere kopien voor 1 cert..

Het is inderdaad (nog) niet mogelijk om op basis van host headers te differentieren tussen SSL sites, omdat de host header mee ge-encrypt wordt in de HTTP request. En die HTTP request moet door 1 specifieke site met SSL cert decrypt worden. Dus kun je maar 1 cert op 1 combinatie ip/poort laten luisteren..

Gelukkig kun je ISA inderdaad gewoon zoveel IP's op alle netwerkkaarten geven als je wilt..

Ik weet dat https op 443 zit, maar die is al in gebruik, dus zal je bij gebrek aan een extra PUBLIEK IP adres dus een andere poort moeten nemen om de SSL verbinding op te kunnen zetten.
Dus de TS zal of een extra Publiek IP adres moeten aanvragen bij zijn provider, of een andere poort moeten gebruiken aan de buitenkant.

[Verwijderd]

axis schreef op donderdag 29 mei 2008 @ 08:51:
Heb bij een klant ook een oplossing staan waarbij een ISA 2006 een stuk of 10 ip's op zijn stack heeft staan, met 3 SSL listeners op een apart ip, geen probleem. (OWA2007, TS-Gateway en custom webapp)

Ok maar hoe heb je deze dan geconfigureerd?
Certificaten?
Rules?
Listener settings?

Ik waardeer je reaktie op mijn post waarin je verteld dat je dit bij je klant ook zo hebt staan alleen zou ik het nog meer waarderen als je ook iets meer verteld over hoe je dit voor elkaar gekregen hebt

PS. Voor iedereen......Als er screenshots gewenst zijn hoe ik mijn rules, listener etc ingericht heb dan hoor ik het wel en mail ik ze door aan jullie!


Thnx!

[deadlock2k]

-

[ Voor 100% gewijzigd door deadlock2k op 06-08-2021 15:47 ]

[Verwijderd]

Ja ok maar dit gaat niet werken in mijn situatie....
Want waar voeg ik dan mijn certificaat toe? Die heb ik toch echt nodig als ik een https site publiseer.... binnen ISA geef je dit op in de listener voor zover ik weet

[axis]

BlaTieBla schreef op donderdag 29 mei 2008 @ 11:52:
[...]

Ik weet dat https op 443 zit, maar die is al in gebruik, dus zal je bij gebrek aan een extra PUBLIEK IP adres dus een andere poort moeten nemen om de SSL verbinding op te kunnen zetten.
Dus de TS zal of een extra Publiek IP adres moeten aanvragen bij zijn provider, of een andere poort moeten gebruiken aan de buitenkant.

Dat is helemaal correct.. Daarom zeg ik ook in de post hierboven dat die klant 10 ip's op zijn stack heeft.. En op 3 van die ip's een https listener met eigen certificaat..

Als je maar 1 publiek ip hebt dan wordt dat erg lastig ja

Verwijderd schreef op donderdag 29 mei 2008 @ 14:59:
[...]
Ok maar hoe heb je deze dan geconfigureerd?
Certificaten?
Rules?
Listener settings?

Ik waardeer je reaktie op mijn post waarin je verteld dat je dit bij je klant ook zo hebt staan alleen zou ik het nog meer waarderen als je ook iets meer verteld over hoe je dit voor elkaar gekregen hebt

Heb geen remote access bij die klant, dus kan ff geen screenshots maken. Weet ook niet meer hoe ik het heb gedaan, maar ik weet dat ik intuitief met wat klikken de eerste keer goed zat. Eerst een boel ip's toegevoegd aan de externe netwerkkaart (bij de advanced tcp properties, kun je daarna verifieeren met ipconfig).

Daarna 3 keer op een of andere web publishing wizard geklikt (heb zelf verder geen ISA's meer in beheer, dus kan daar ook geen screenshots van maken), en alle keren een nieuwe https listener gemaakt, die op een specifiek ip luistert. De default setting is volgens mij op alle ip's op een interface te luisteren, dus dat moet je zelf specificeren.

Dat werkte al prima, daarna nog een boel gefriemeld met authenticatiegezet om OWA aan de praat te krijgen. Uiteindelijk werkte dat ook prima, en verder niet meer naar gekeken..

[Verwijderd]

Heb geen remote access bij die klant, dus kan ff geen screenshots maken. Weet ook niet meer hoe ik het heb gedaan, maar ik weet dat ik intuitief met wat klikken de eerste keer goed zat. Eerst een boel ip's toegevoegd aan de externe netwerkkaart (bij de advanced tcp properties, kun je daarna verifieeren met ipconfig).

Daarna 3 keer op een of andere web publishing wizard geklikt (heb zelf verder geen ISA's meer in beheer, dus kan daar ook geen screenshots van maken), en alle keren een nieuwe https listener gemaakt, die op een specifiek ip luistert. De default setting is volgens mij op alle ip's op een interface te luisteren, dus dat moet je zelf specificeren.

Dat werkte al prima, daarna nog een boel gefriemeld met authenticatiegezet om OWA aan de praat te krijgen. Uiteindelijk werkte dat ook prima, en verder niet meer naar gekeken..

Volgende keer maar meteen documenteren

[axis]

Verwijderd schreef op dinsdag 03 juni 2008 @ 17:06:
[...]
Volgende keer maar meteen documenteren

Neuh, weet zeker dat als ik de volgende keer een ISA2006 voor mijn neus heb, dat ik het weer binnen een kwartiertje werkend zal hebben..