SSL routen naar verschillende servers.

[Anoniem: 162841]

Dag medetweakers,

Misschien kunnen jullie mij helpen bij mijn probleem:

Ik heb twee servers die allebei een service aanbieden over SSL, poort 443 dus.
Deze poort is dan ook geforward op mijn router naar de betreffende servers.
Maar bij testen is er maar één server bereikbaar. Na wat zoeken blijkt dat portforwarding naar meerdere pc's niet mogelijk is omwille van de aard van het NAT protocol.

Zou er een manier zijn om hier rond te werken? Zelf dacht ik aan een soort van scheiding door middel van de url die gebruikt word.
Bv. => We forwarden 443 naar één server. Als https://domein word gebruikt handelt hij de request zelf af maar als https://domein/exchange word gebruikt forward hij de request naar de andere server.

Heeft er iemand een idee hoe je dit kan implementeren?

extra info:
services die aangeboden worden:
server1 => SSL explorer : een SSL vpn tunneling applicatie, gebruikt geen IIS.
server2 => Exchange outlook web access : gebruikt IIS

Alvast bedankt om mee te denken.

[sariel]

Tsja, je zou kunnen proxy'en, dat je ene server het verkeer voor /exchange naar de iisserver proxiet.
en anders zou je misschien kunnen denken aan een ssl loadbalancer

[Maurits van Baerle]

Bij mijn weten is het niet NAT die roet in het eten gooit maar SSL zelf. Die kan namelijk altijd alleen over poort 443 werken en per IP-adres is er altijd maar één poort 443. Normaal gesproken los je zoiets op met NAT of Host Headers. Echter, een router die er tussen zit kan de data niet bekijken om te zien naar welke machine het moet (de URL of Host Header Name dus) omdat de data encrypted is.

Volgens mij is de enige oplossing een intelligente router/firewall (denk bijv. aan ISA-Server) die zélf het SSL endpoint is. Die kan dan de data analyseren en besluiten naar welke machine in de back-end hij het verstuurt. Dat laatste gebeurt dan dus ook niet meer over SSL maar dat hoeft minder een probleem te zijn aangezien dat je eigen LAN is waar het verkeer overheen zal gaan.

Ik heb het zelf nooit gedaan maar heb wel eens begrepen dat dit mogelijk moet zijn. De kern is dus dat je de SSL functie scheidt van de webserver.

[Anoniem: 57365]

ssl kan prima op een andere port werken, maar de vraag is of je dat wil (gebruikers moeten dan het portnummer opgeven)

maar je kan maar 1 certificaat op een ip adres hebben. zijn het 2 totaal verschillende domeinen, dan heb je een probleem als je maar 1 extern ip adres hebt. Heb je 2 subdomeinen, dan zou je met hostheaders en een wildcard certificaat kunnen werken (*.domein.nl).

2x dezelfde port forwarden op 1 ip adres kan ook niet, reverse proxy is hier de oplossing. Meerdere pakketen zijn hiervoor te gebruiken, isa zoals al aangegeven, maar ook andere proxies kunnen dit vaak en bijv. apache heeft ook een reverse proxy module. je hoeft niet je firewall te vervangen, je kan best een reverse proxy achter je huidige firewall zetten.
MauritsvanBaerle zegt dat je intern dan geen ssl meer kan gebruiken, maar ook dat is onzin. Het is wel zo dat de reverse proxy een ssl endpoint is, maar je kan van de proxy naar de webserver ook gewoon weer een ssl sessie opzetten.

[ Voor 23% gewijzigd door Anoniem: 57365 op 23-02-2006 12:03 ]

[Regman_XP]

Op IIS kan je websites aanbieden op basis van header informatie en door laten sturen naar een ander url. Dit moet wel voor de gebruiker een toegankelijk url zijn.

Als je poort 443 naar IIS door stuurt hier een website defineren die al het verkeerd van domein2.com naar domein2.com:8443 stuurt. Poort 8443 stuur je dan naar de andere server. De website van domein2 moet dan wel op poort 8443 draaien of op zowel poort 443 als 8443 draaien. 443 zal echter dan vanaf extern niet benaderbaar zijn.

De gebruikers hoeven geen poort nummer op te geven maar zien dit wel staan in hun adresbalk.

[Anoniem: 162841]

Ik had al een licht vermoeden dat het de kant van een ISA server zou uitgaan maar wou het onbewust nog niet laten doordringen omdat dan toch het hele netwerk moet omgegooid worden om de isa server te implementeren. Ben ook niet zo bekend met isa.
Maar ja, als je secure wil zijn moet je er iets voor over hebben nietwaar

MauritsvanBaerle schreef op donderdag 23 februari 2006 @ 11:45:
Die kan dan de data analyseren en besluiten naar welke machine in de back-end hij het verstuurt. Dat laatste gebeurt dan dus ook niet meer over SSL maar dat hoeft minder een probleem te zijn aangezien dat je eigen LAN is waar het verkeer overheen zal gaan.

Dit terzijde maar ik denk dat ISA ook het deel naar de lokale client altijd encrypt door als een soort van man in the middle te werken.

internet = SSL sessie 1 => ISA => SSL sessie 2 => Lokale client

[Anoniem: 57365]

Anoniem: 162841 schreef op donderdag 23 februari 2006 @ 12:08:
Ik had al een licht vermoeden dat het de kant van een ISA server zou uitgaan maar wou het onbewust nog niet laten doordringen omdat dan toch het hele netwerk moet omgegooid worden om de isa server te implementeren. Ben ook niet zo bekend met isa.
Maar ja, als je secure wil zijn moet je er iets voor over hebben nietwaar

je hoeft niet je hele netwerk om te gooien om isa te gebruiken. de firewall functionaliteit is niet nodig en zoals ik al zei, er zijn meer reverse proxies...

Dit terzijde maar ik denk dat ISA ook het deel naar de lokale client altijd encrypt door als een soort van man in the middle te werken.

internet = SSL sessie 1 => ISA => SSL sessie 2 => Lokale client

niet altijd dit is instelbaar.

[lier]

Heb je eventueel de mogelijkheid om een tweede IP adres te krijgen via je provider ? Dan kan je op basis van IP adres routeren.

[Anoniem: 57365]

Regman_XP schreef op donderdag 23 februari 2006 @ 12:04:
Op IIS kan je websites aanbieden op basis van header informatie en door laten sturen naar een ander url. Dit moet wel voor de gebruiker een toegankelijk url zijn.

Als je poort 443 naar IIS door stuurt hier een website defineren die al het verkeerd van domein2.com naar domein2.com:8443 stuurt. Poort 8443 stuur je dan naar de andere server. De website van domein2 moet dan wel op poort 8443 draaien of op zowel poort 443 als 8443 draaien. 443 zal echter dan vanaf extern niet benaderbaar zijn.

De gebruikers hoeven geen poort nummer op te geven maar zien dit wel staan in hun adresbalk.

met deze workaround blijf je een certificaat mismatch houden. buiten dat is dit gewoon lelijk

[ Voor 3% gewijzigd door Anoniem: 57365 op 23-02-2006 12:31 ]

[Anoniem: 162841]

Een reverse (ssl) proxy lijkt inderdaad de oplossing te zijn waar ik naar zoek.
Ik ga dit al eens proberen te implementeren. Zal mijn ervaringen hier later posten.
Alvast bedankt voor de reacties