Oorzaak?
RDgateway gaat toch verbinding maken op poort 443 ookal wordt er aangegeven voor een andere poort te gebruiken.
(Mij is niet duidelijk waarom hij precies gaat proberen verbinden op 443, cert controle?)
Waarom de delay in verbinden?
In mijn firewall heb ik geconfigureerd om alle pakkets die binnenkomen op een gesloten poort silent te droppen.
De de timers van RTO doen zijn werk omdat er geen ACK of REJECT terugkomt.
Hierdoor krijg je 4 transmissions met steeds dubbel aantal seconden dat hij wacht.
1 sec
2 sec
4 sec
8 sec
Nieuwe RTO start
..
Met als gevolg een flinke vertraging.
Oplossing?
De rule van de firewall aangepast dat hij op poort 443 een reject stuurt in plaats van de pakkets te droppen.
-
Goedemiddag,
Wij maken gebruik van RD Gateway om connectie te maken via RDP.
Wanneer wij hiermee verbinding maken duurt het 30 a 60seconden voordat hij "Initiating remote connection" voorbij is.
Daarna lukt het verbinden snel.
(Let niet op de afbeelding deze is verouderd, dit is eentje van het internet)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/CWgrpq7QLMe6x5uHeAKn3ZrK.jpg?f=user_large)
-
Als we verbinding maken via RDP rechtstreeks op IP en port 3389 is er geen probleem.
-
Wanneer ik ga kijken via wireshark zie ik dat de vertraging komt door "TCP Retransmisison".
(Wireshark client side)
:strip_exif()/f/image/o1pgslr03UW7WHYgWGqixhBP.jpg?f=fotoalbum_large)
De oorzaak ligt niet op het netwerk van de Clients.
(Iedereen heeft hier last van + is op meerdere netwerken getest)
-
Als ik naar RTT en Packet loss ga kijken op de firewall is dit ook dik in orde.
Ik weet niet als dit een goede referentie is voor Network Congestion?
Firewall WAN:
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/kCuJc33XLTDWNrp9ICIfkMNF.jpg?f=user_large)
Firewall LAN:
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/HoRYpEHbgD81nCbOTaNjgthQ.jpg?f=user_large)
Ping van Werkstation naar RDS.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/9gmQviNFRTk9HQ4PvjHNm9Jr.jpg?f=user_large)
-
Hoe ziet het netwerk uit?
External IP
Firewall WAN
LAN IP (172.16.10.1/24)
Fysieke Switch geen vlans
LAN IP (172.16.10.101/24) -> WAN Gateway voor deze firewall is 172.16.10.1/24
Firewall LAN
vSwitch (HyperV) geen vlan
LAN IP (192.168.13.1/24)
vSwitch (HyperV) met vlan
RDP Server (192.168.13.110/24)
-
Enkel zaken dat ik geprobeerd heb:
1. Deactivatie Large Send Offload
2. enablecredsspsupport:i:0
3. Self signed server cert geïnstalleerd op client PC
4. RDP gestart via LAN (172.16.10.0/24) zodat men niet over het internet gaat -> Vertraging blijft
5. Uitgaand wordt er niks geblokkeerd (Geen protocollen, poorten of IP's)
6. Firewall op RDS staat uit. (Privé, domain & public)
-
Edit:
Oorzaak van retransmission komt omdat hij op poort 443 verbinding wil maken.
Deze poort staat dicht en wordt niet gebruikt.
Er komt ook geen ACK op pakket 124.
RDgateway gaat over poort 60000.
Nu nog vinden waarom deze poort wordt aangesproken.
:strip_exif()/f/image/lqpXLedZkn8IRT7ZiRgwpGI1.jpg?f=fotoalbum_large)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/qIFT0WTS3XBNX6Kw7QJmnU24.jpg?f=user_large)
RDgateway gaat toch verbinding maken op poort 443 ookal wordt er aangegeven voor een andere poort te gebruiken.
(Mij is niet duidelijk waarom hij precies gaat proberen verbinden op 443, cert controle?)
Waarom de delay in verbinden?
In mijn firewall heb ik geconfigureerd om alle pakkets die binnenkomen op een gesloten poort silent te droppen.
De de timers van RTO doen zijn werk omdat er geen ACK of REJECT terugkomt.
Hierdoor krijg je 4 transmissions met steeds dubbel aantal seconden dat hij wacht.
1 sec
2 sec
4 sec
8 sec
Nieuwe RTO start
..
Met als gevolg een flinke vertraging.
Oplossing?
De rule van de firewall aangepast dat hij op poort 443 een reject stuurt in plaats van de pakkets te droppen.
-
Goedemiddag,
Wij maken gebruik van RD Gateway om connectie te maken via RDP.
Wanneer wij hiermee verbinding maken duurt het 30 a 60seconden voordat hij "Initiating remote connection" voorbij is.
Daarna lukt het verbinden snel.
(Let niet op de afbeelding deze is verouderd, dit is eentje van het internet)
-
Als we verbinding maken via RDP rechtstreeks op IP en port 3389 is er geen probleem.
-
Wanneer ik ga kijken via wireshark zie ik dat de vertraging komt door "TCP Retransmisison".
(Wireshark client side)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/o1pgslr03UW7WHYgWGqixhBP.jpg?f=user_large)
De oorzaak ligt niet op het netwerk van de Clients.
(Iedereen heeft hier last van + is op meerdere netwerken getest)
-
Als ik naar RTT en Packet loss ga kijken op de firewall is dit ook dik in orde.
Ik weet niet als dit een goede referentie is voor Network Congestion?
Firewall WAN:
Firewall LAN:
Ping van Werkstation naar RDS.
-
Hoe ziet het netwerk uit?
External IP
Firewall WAN
LAN IP (172.16.10.1/24)
Fysieke Switch geen vlans
LAN IP (172.16.10.101/24) -> WAN Gateway voor deze firewall is 172.16.10.1/24
Firewall LAN
vSwitch (HyperV) geen vlan
LAN IP (192.168.13.1/24)
vSwitch (HyperV) met vlan
RDP Server (192.168.13.110/24)
-
Enkel zaken dat ik geprobeerd heb:
1. Deactivatie Large Send Offload
2. enablecredsspsupport:i:0
3. Self signed server cert geïnstalleerd op client PC
4. RDP gestart via LAN (172.16.10.0/24) zodat men niet over het internet gaat -> Vertraging blijft
5. Uitgaand wordt er niks geblokkeerd (Geen protocollen, poorten of IP's)
6. Firewall op RDS staat uit. (Privé, domain & public)
-
Edit:
Oorzaak van retransmission komt omdat hij op poort 443 verbinding wil maken.
Deze poort staat dicht en wordt niet gebruikt.
Er komt ook geen ACK op pakket 124.
RDgateway gaat over poort 60000.
Nu nog vinden waarom deze poort wordt aangesproken.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/lqpXLedZkn8IRT7ZiRgwpGI1.jpg?f=user_large)
[ Voor 27% gewijzigd door Chris-1992 op 10-10-2022 23:37 ]
:strip_exif()/u/182753/crop56e3e220ad638_cropped.gif?f=community)
:strip_icc():strip_exif()/u/85308/mirko.jpg?f=community)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/8vN51OKzdd5XeoXLlhqB7ypL.jpg?f=user_large)
:strip_icc():strip_exif()/u/55250/crop5bfe6e8b5ddb6_cropped.jpeg?f=community)
