Question RDP with Site-to-Site VPN

[cartman0208]

Hi guys,

this is probably not the first place to ask this, but I'm hoping to get a first hint from our experienced members to pinpoint my issue before asking my colleagues next week, so here goes:

I'm connecting two offices with fixed IPs over IPSec VPN.

At Office 1 is a Windows RDP Server located.

From Office 2 I can ping, telnet port 3389 and even start the RDP connection to the RDP Server.
However after entering the credentials after some short time (30 secs more or less) I get "Internal Error"

On the other hand if I connect from my home to Office 1 via L2TP/IPSec, I can RDP to that server just fine.

First I thought I had the routing wrong, but then I wouldn't get any reply via Ping or RDP, right?

So it must be something with the authentication or the encryption or ... ???

Any advises are welcome.

 

[DQ]

Hi guys,

this is probably not the first place to ask this, but I'm hoping to get a first hint from our experienced members to pinpoint my issue before asking my colleagues next week, so here goes:

I'm connecting two offices with fixed IPs over IPSec VPN.

At Office 1 is a Windows RDP Server located.

From Office 2 I can ping, telnet port 3389 and even start the RDP connection to the RDP Server.
However after entering the credentials after some short time (30 secs more or less) I get "Internal Error"

On the other hand if I connect from my home to Office 1 via L2TP/IPSec, I can RDP to that server just fine.

First I thought I had the routing wrong, but then I wouldn't get any reply via Ping or RDP, right?

So it must be something with the authentication or the encryption or ... ???

Any advises are welcome.

This could be an issue with MTU and or MSS. I see this often at work. When you have MTU issues ICMP and other small packet based activities work just fine but then some things do not. For me, this is sometimes due to tiny packets passing fine, larger ones getting dropped (for me it's typically when certificates are exchanged as that produces a couple of max sized packets).

RDP can/will use a mix of UDP and TCP. MTU applies to both but MSS applies only to TCP. Now RDP uses tiny rapid packets once a session is established but the establishment will use large ones. And that does include a certificate I do believe (large packets).

Another variable that makes this type of thing seem hit and miss is some applications set the DF bit. So if your packet is beyond MTU and DF (don't fragment) is set, a router will just drop the traffic.

I am not saying this is for sure the case, just putting that out there as it seems somewhat likely.

To know for sure I would run a packet capture on the PC and the Server at the same time just long enough to snag the issue. That should tell the tale.

If that is out of your wheelhouse you can PM me the captures, up to you.

 

[cartman0208]

Thanks DQ,

I fiddled around with various settings on both client and routers.
Eventually I got it to work, but I'm not sure about what setting was the issue.
I suspect the disabling of Netbios Naming Packets in the Site-to-site configuration was the solution ... so I wanted to confirm that ... but I seem to have messed up one othersetting and now I'm locked out ...
Have to get to Office 2 to gain access again

 

[DQ]

Thanks DQ,

I fiddled around with various settings on both client and routers.
Eventually I got it to work, but I'm not sure about what setting was the issue.
I suspect the disabling of Netbios Naming Packets in the Site-to-site configuration was the solution ... so I wanted to confirm that ... but I seem to have messed up one othersetting and now I'm locked out ...
Have to get to Office 2 to gain access again

Disabling netbios I don't see making any difference. This is certainly the case if you are trying to access another device by IP then there is no name resolution going on. I am not sure what settings you are referring to, netbios has no play in IPSEC unless you are talking about something Microsoft specific and I know you mentioned L2TP.

If you want to give more specific details about the topology and what's on each end that would help. I am more than happy to help but I would not post that for all to see so if you would like to talk more about it I suggest PM. Just hit me up.

 

[DQ]

Just shooting from the hip though, I would as a test drop MTU one end or both to 1300. You could also try dropping MSS to 1250 alternatively if that's easier. If nothing else, drop MTU on your NIC on your machine you are running the RDP client on.

RDP involves a self-signed certificate by default. If you can get your auth through but then it errors, that's a certificate that comes next and those are maxed sized packets. This is what makes me think this could be MTU related. This happens often with tunneling and ESPECIALLY with multiple layers of tunneling. Protocols can often guess what's going on with just a single tunnel. But when it's a tunnel under a tunnel nothing figures that out normally so things get confused.

 

[michixx1893]

Hey there!

It seems like you're dealing with a tricky VPN setup. Have you checked the firewall settings to make sure they're not blocking the RDP traffic? It could also be worth double-checking the VPN and RDP configurations to ensure they're compatible and correctly set up. If all else fails, getting a second opinion from your IT colleagues might be the best next step.

 

[cartman0208]

That L2TP/IPSec is just for user dial in ... the actual site-to-site between offices is a pure IPSec connection authenticated with IP and preshared key
But ... as I noted, I think I set the encryption settings to high and now I'm locked out of the second location, need to have someone there to get me access before I can proceed

 

[DQ]

That L2TP/IPSec is just for user dial in ... the actual site-to-site between offices is a pure IPSec connection authenticated with IP and preshared key
But ... as I noted, I think I set the encryption settings to high and now I'm locked out of the second location, need to have someone there to get me access before I can proceed

What do you mean too high? So long as it matches at both ends should be good so long as both ends are capable of it. I still think you might be having an MTU/MSS issue given your description. This is an easy test. Just drop the MTU on the network card of the machine you are doing the RDP from. That's assuming the tunnel it ok of course.

 

[cartman0208]

I changed IPsec Settings from

to

on router 2 and afterwards I was not able to even dial in.

Curiously the connection between both routers was established.
Then it hit me like a hammer ... I could just jump on a box in office 1 ... and lo and behold, i was able to connect to the webinterface of router 2
I set the security back to medium and now I'm able to reach router 2 via dial-in again...

Issue solved

I still don't know how my initial problem was resolved, but by now I can dial in to router 2 and jump from there to the terminal server in office 1... so I guess the routing is correct

 

[DQ]

I changed IPsec Settings from
View attachment 79343
to
View attachment 79344
on router 2 and afterwards I was not able to even dial in.

Curiously the connection between both routers was established.
Then it hit me like a hammer ... I could just jump on a box in office 1 ... and lo and behold, i was able to connect to the webinterface of router 2
I set the security back to medium and now I'm able to reach router 2 via dial-in again...

Issue solved

I still don't know how my initial problem was resolved, but by now I can dial in to router 2 and jump from there to the terminal server in office 1... so I guess the routing is correct

Yeah if you changed settings on one side but not the other they would mismatch and disagree and no tunnel would form. If I were you I would use high because medium includes DH group 5. But even on medium it should be going with the highest agreed upon group so probably not a huge deal.

It's possible your issue before was something odd with the tunnel, meaning a one off and reestablishing the tunnel cleared the problem. Windows does a lot of auto tuning on the fly in its TCP/IP stack. It's possible an oddity in the tunnel was causing windows to calculate something wrong. I have seen that before on occasion, particularly around TCP MSS negotiation and that is what your original issue behaved like.

The bad thing with problems that resolve themselves, they often come back. Just let me know if it does.

 

[DrXenos]

Curiously the connection between both routers was established.
Then it hit me like a hammer ... I could just jump on a box in office 1 ... and lo and behold, i was able to connect to the webinterface of router 2
I set the security back to medium and now I'm able to reach router 2 via dial-in again...

Issue solved

I still don't know how my initial problem was resolved, but by now I can dial in to router 2 and jump from there to the terminal server in office 1... so I guess the routing is correct

I love epiphany moments. I had one years ago about a networking software issue that brought our entire project to a stop for weeks. It was in the middle of our department meeting and I yelled out, "oh, sh*t!!!" My boss asked, "what's up?" and my colleague shakes her head, laughs, and says, "nope, just let him go!"

The annoying part was it took me a week to convince the guy who wrote the driver what the issue was, and when he finally implemented the fix, he got an award for it. Sigh.

 

[cartman0208]

The annoying part was it took me a week to convince the guy who wrote the driver what the issue was, and when he finally implemented the fix, he got an award for it. Sigh.

Had one of those as a co-worker ... I solved the issues, he got the glory ... and a raise

Yeah if you changed settings on one side but not the other they would mismatch and disagree and no tunnel would form. If I were you I would use high because medium includes DH group 5. But even on medium it should be going with the highest agreed upon group so probably not a huge deal.

Yep ... even though both routers had different security settings, they were talking fine with each other (both agreed to the higher security I guess).

But the VPN client I was using on my notebook, couldn't connect to the one with the higher security.
That for itself is no showstopper since I know now how to connect to it, but I would rather have some fallback VPN to office 2 if office 1 is completely down.

Are there issues with DH group 5?

 

[DQ]

Yep ... even though both routers had different security settings, they were talking fine with each other (both agreed to the higher security I guess).

But the VPN client I was using on my notebook, couldn't connect to the one with the higher security.
That for itself is no showstopper since I know now how to connect to it, but I would rather have some fallback VPN to office 2 if office 1 is completely down.

Are there issues with DH group 5?

DH5 is frowned on now because it is no longer considered secure, the recommend minimum group is 14 currently. But it would not have caused you any actual trouble. Now if you are VPN'ing into a site and then jumping across another IPSEC link to get to another remote site then you indeed have a 2 tunnel situation going on effectively. That can confuse things sometimes.