Able to ping but not RDP over ikev1 VPN established between ASA

[S.U.H.E.L]

Need to allow remote peer to RDP my Server. We need not access their devices.

Successfully established an IKEv1 VPN tunnel between two ASA. Private IP of Server is Translated to public IP and sent over the VPN tunnel. The remote user is able to ping my server using the public translated IP but when tries to telnet the same public IP using port 3389, connection times out.

Allowed interesting traffic : 

VPN ACL (source: local server translated ip destination: remote server public ip)

Inbound on inside interface (source: local server destination: remote server)

Inbound on outside interface (source: remote server public IP destination: local server private ip)

[Rob Ingram]

Hi, Can you run packet-tracer, e.g "packet-tracer input inside tcp <private ip> 3000 <remote ip> 3389" and provide the output for review.

[S.U.H.E.L]

Hi,

When I run the packet-tracer input inside command "packet-tracer input inside tcp <local server private ip> 3000 <remote server public ip> 3389" it successfully passes through. The following is the last phase of the output

Phase: 12
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 487265, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

However, when I execute packet-tracer input outside command "packet-tracer input outside tcp <remote ip (public)> 3000 <local server ip (private)> 3389" it drops at the following phase:

Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[Rob Ingram]

Are you natting both the source and destination through the VPN tunnel? Your second packet-tracer would need to reference the public IP address not the private.

Are you able to take a packet capture on the remote end?

[S.U.H.E.L]

Here is the scenario:

My server real private IP (e.g. 192.168.1.1) translated to public IP (e.g. 1.1.1.1). Remote user has just provided one Public IP (e.g. 2.2.2.2)

Remote User is able to ping 1.1.1.1 from his server, but unable to telnet 1.1.1.1 3389

VPN nat statement is as follows:

nat (inside,outside) source static 192.168.1.1 1.1.1.1 destination static 2.2.2.2 2.2.2.2 no-proxy-arp

VPN ACL:

access-list VPN permit ip host 1.1.1.1 host 2.2.2.2

Inside ACL (inbound):

permit ip any any

Outside ACL(inbound)

access-list OUT permit ip host 2.2.2.2 host 192.168.1.1

As suggested, I run the packet tracer input outside " packet-tracer input outside tcp <remote side public ip> 3000 <local public ip> 3389 but it still drops at VPN phase.

Phase: 6
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

I do not have access to remote side. The only output I got from the remote user is failed to telnet my public ip port 3389

I just want to make sure everything is fine at my end.

[Sheraz.Salim]

if you both are using public ip addresses than why dont you narrow it down to ACL instead of vpn-tunnel. 

packet tracer from outside to inside for vpn-tunnel does not work. better you share the whole output of packet tracer from inside to side.

also you mentioned doing telnet 1.1.1.1 3389?

[S.U.H.E.L]

Yes, the remote user needs to be able to RDP my server. Since the tunnel was up and working fine, even I tried to look at the ACL.

But ACL permits interesting traffic on both:
Inside interface inbound ACL (permit ip any any)

Outside interface inbound ACL (permit ip host <remote public IP> host <local private ip>)

Is there any other ACL I need to be looking at?

[Rob Ingram]

Do you have a VPN Filter applied?

If the connection is inbound to you on 3389, take a packet capture on your ASA.

Does the Windows Server have the firewall turned on that could be blocking this traffic?

[Cristian Matei]

Hi,

     Except ICMP, is there any other traffic functional between those devices, like telnet for example? Try to temporarily remove MPF inspection and see if it works; you could also use "clear asp drop", initiate the RDP session and look at "show asp drop", maybe you spot something.

     Pasting the relevant config might also help, maybe there is something misconfigured though.

Regards,

Cristian Matei.

[S.U.H.E.L · Accepted solution]

The issue was at the server end. RDP was not permitted for the VPN peer public IPs.

Thanks for your support everyone!