Routing und RAS für HTTP(S) Traffic

Hallo,

wir haben ein Windows Server 2012 R2 Host-System, auf dem verschiedene PHP- und demnächst auch ASP.NET Anwendungen gehostet werden. Hierzu verwenden wir den IIS. Varnish soll als Fronted-Cache genutzt werden. Um das zu realisieren, haben wir virtualisiert mit zwei VMs, die sich in einem eigenen Subnetz befinden:

VM #1: Debian mit Varnish (192.168.0.2)
VM #2: Windows Server 2012 R2 mit IIS (192.168.0.3)

Port 80 des Host-Systems soll auf VM#1 (192.168.0.2) geleitet werden. Dort liefert Varnish den Request aus dem Cache aus sofern vorhanden. Ansonsten leitet er ihn an den IIS (192.168.0.3) weiter und cached die Antwort für zukünftige Anfragen.
Port 443 soll direkt an den IIS an VM2 gehen, da wir SSL nur für angemeldete Benutzer verwenden (nicht angemeldete werden auf HTTP geleitet, sofern die Seite über HTTPs aufgerufen wird). Hier wäre das Caching der kompletten Seite sowieso sinnfrei, da zu viele dynamische Inhalte wie Benutzername etc. vorhanden. Außerdem unterstützt Varnish kein HTTPS-Caching.

Lösen wollte ich das ganze über NAT mit Routing und RAS von Windows Server 2012. Das erfüllt meine Anforderungen vollkommen. Leider ist es extrem langsam. Die Ladezeit geht auf über 10 Sekunden hoch:


Mit einer normalen IIS-Installation auf dem Host-System lag die Ladezeit vorher bei 1,5 bis 1,8 Sekunden. Ich vermute das Problem darin, dass über Routing und RAS kein Keep-Alive möglich ist und somit für jeden Request eine komplett eigene Verbindung geöffnet wird.

Daher meine Fragen:
1. Ist es möglich, Routing und RAS für HTTP(S)-Traffic mit Keep-Alive zu nutzen, sodass vernünftige Ladezeiten entstehen?
2. Wenn nein was ich eher vermute: Was für Alternativen gibt es? Am liebsten wäre mir etwas das die Möglichkeiten von Routing und RAS bietet, also einen einzelnen Port auf einer einzelnen IP an eine eigene VM im Intranet leiten zu können. Bisher habe ich nur die Möglichkeit von Reverse Proxys gefunden. Testweise nutze ich nginx. Das ist aber eher suboptimal: Meine PHP-Anwendungen prüfen, ob der User SSL nutzt oder nicht und leiten den User entsprechend um: Nicht angemeldete User werden auf HTTP umgeleitet wenn sie über HTTPs reinkommen. Ich muss also im Nginx meine SSL-Zertifikate hinterlegen, und die Requests ebenfalls per SSL an den IIS weiterleiten. Heißt ich habe bei jedem Request Overhead. SSL einfach nur stumpf weiterleiten kann nginx scheinbar nicht, genau das bräuchte ich aber.
Außerdem gefällt mir bei dieser Lösung nicht, dass die Requests im dümmsten Fall über drei Server laufen: nginx => varnish => IIS