- CheckMates
- :
- Products
- :
- Quantum
- :
- Remote Access VPN
- :
- RDP to VPN Mobile clients doesn´t work
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RDP to VPN Mobile clients doesn´t work
Hi,
Is there any problem to do a RDP session to VPN Mobile clients?
Everything works as normal with the RDP connection until the remote user is allowing remote access to their computer (clicking OK to allow it), then the VPN connection gets disconnected and no RDP session is possible.
We have rules that allow RDP to do remote sessions to VPN Mobile clients on the Office Mode IP-adresses.
We are using a domain administrator account for the RDP session.
What could be wrong or is this a security feature that should disconnect this type of remote session?
Regards
Anders
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have this property enabled to allow back connections?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, we have that property enabled and we have other gateway to client communication that works, it's just RDP that won't work.
We have ManageEngines Desktop Central as computer management system, but the remote session consol is a little bit complicated to use so we want to use RDP instead for easier access to VPN connected clients and give help to our remote users. I hope there is a solution for this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Best bet would be to run a fw monitor -F capture of the RDP traffic on the firewall, this will allow you to see if it is being dropped by the firewall, dropped or not returned by the client, or is some kind of routing problem. Just be careful and double-check your fw monitor -F syntax as making a mistake will give you a completely unfiltered capture. If it appears to be getting dropped on the firewall, fw ctl zdebug drop would be the next command to run to see why.
Could it be that this RDP traffic is getting inappropriately NATted by the firewall prior to being put into the RA VPN tunnel and then returning in the clear? You may need an anti-NAT rule for these types of RDP connections.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have now done the fw monitor -F command with a filter to only see RDP traffic between a computer from my company to a remote VPN Mobile client. This is the last logging before the connection is broken (172.X.X.221 is the computer at my company and the "10.X.X.21" is the remote VPN Mobile clients IP:
TCP: 64381 -> 3389 ...PA. seq=97965d68 ack=9dc065be
[vs_0][ppak_0] eth1-01.2:i[40]: 172.X.X.221 -> 10.X.X.21 (TCP) len=40 id=9533
TCP: 64381 -> 3389 ..R.A. seq=979661ca ack=9dc065be
[vs_0][fw_2] eth1-01.2:I[40]: 172.X.X.221 -> 10.X.X.21 (TCP) len=40 id=9533
TCP: 64381 -> 3389 ..R.A. seq=979661ca ack=9dc065be
[vs_0][fw_2] eth1:o[40]: 172.X.X.221 -> 10.X.X.21 (TCP) len=40 id=9533
TCP: 64381 -> 3389 ..R.A. seq=979661ca ack=9dc065be
[vs_0][ppak_0] eth1:Oe[40]: 172.X.X.221 -> 10.X.X.21 (TCP) len=40 id=9533
TCP: 64381 -> 3389 ..R.A. seq=979661ca ack=9dc065be
And here are the first "drop" loggings after the VPN connection is down with the fw ctl zdebug + drop | grep '10.X.X.12'
@;1584313098;[cpu_0];[SIM-209104189];sim (vpn_encrypt): drop due vpn_ipsec_encrypt returns PKT_DROP(3), conn: <172.X.X.221,63511,10.X.X.12,3389,6>;
@;1584313098;[cpu_0];[SIM-209104189];handle_vpn_encryption: ipsec_encrypt failed: failed to find SA. Dropping packet... conn: <172.X.X.221,63511,10.X.X.12,3389,6>;
@;1584313098;[cpu_0];[SIM-209104189];sim_pkt_send_drop_notification: (0,2) received drop, reason: Encryption Failed, conn: <172.X.X.221,63511,10.X.X.12,3389,6>;
@;1584313098;[cpu_0];[SIM-209104189];sim_pkt_send_drop_notification: sending packet dropped notification drop mode: 0 debug mode: 1 send as is: 0 track_lvl: -1, conn: <172.X.X.221,63511,10.X.X.12,3389,6>;
@;1584313098;[cpu_0];[SIM-209104189];sim_pkt_send_drop_notification: sending single drop notification, conn: <172.X.X.221,63511,10.X.X.12,3389,6>;
@;1584313099;[cpu_0];[SIM-209104189];do_packet_finish: SIMPKT_IN_DROP vsid=0, conn:<172.X.X.221,63511,10.X.X.12,3389,6>;
We have no NAT between the Office Mode IP addresses and the internal network so I don't think it's a NAT problem.
Can anyone help me interpret these logs above?
In my opinion I think it's the remote VPN Mobile client that imediately closes the connection when the new admin user from the company computer is taking over (logging on) the loggedon users remote computer. It seems that the VPN Mobile client session only "follows" the for moment loggedon user.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Anders, can u find a solution for this issue?
