Firepower 1010 cannot RDP

[jjevans1]

Hello All,

I have setup VPN according to these instructions:

https://www.petenetlive.com/KB/Article/0001682

I have the default rule (Inside Zone Any Any to Outside Zone Any Any = Trust)

I have a just in case rule (Inside Zone Any Any to Inside Zone Any Any = Trust)

When I VPN in successfully and try to RDP to any PC’s on the local LAN (192.168.1.0/24) I cannot connect nor can I ping any of the internal IP addresses.

My VPN address is 192.168.1.250/24

What can I be missing?

Thank you for any insight,

JJ

[Rob Ingram]

@jjevans1 you probably need a NAT exemption rule to ensure your traffic from the internal network the RAVPN network is not unintentially translated. Example:

If that is not the case, please run packet-tracer from the CLI to simulate the traffic flow, provide the output for review.

[jjevans1]

Thank you for your example it was very helpful. This issue I had was it will only accept a network under: IPv4 Split Tunneling Networks. I tried to make a range but it would only allow me to add a network not a range. I was hoping that would work since my VPN range is just a couple of IP’s.

VPN Pool range object: 192.168.1.250-.254

VPN Pool to: 192.168.1.250 - 192.168.1.254

Created NAT Exception Rule for VPN Pool according to your example.

I can ping the inside PC when connected to VPN but not RDP to that PC. I can RDP internally just not through VPN.

I ran packet tracer and it looks like everything it is allowed?? Output is attached.

packet-tracer input inside icmp 192.168.1.250 8 0 192.168.1.5

192.168.1.250 (VPN Pool)

192.168.1.5 (PC on Eth1/2 VLAN 1)

Anything else I can try or is there something I am not doing correctly?

Thank you for your insight,

JJ

[Rob Ingram]

@jjevans1 if you notice the packet-tracer output confirms the input and output interfaces are both "inside", which is technically accurate (because they overlap) but not what you want. Don't use the same network for the VPN pool, use another separate network that isn't the inside network, i.e. 192.168.2.0/24. You can then create a network object as 192.168.1.0/24 that represents the inside network and reference this in the split-tunnel configuration. Use these 2 unique networks in the NAT exemption rules.

[MHM Cisco World]

192.168.1.250 (VPN Pool)

192.168.1.5 (PC on Eth1/2 VLAN 1)
this not work at all, 
the VPN pool must have different subnet than Inside hosts, 
the VPN Pool IP will add to route table as connect direct via OUT not IN interface. 

this is your issue I think 

[jjevans1]

Thank you all for your insight it is really appreciated. I have done the following:

Created New VPN Pool Network: 192.168.2.0/24 – Deleted the old

Added both Internal and VPN Pool to Group Policy and NAT Exempt.

Created two NAT exception rules: one for Internal Network and one for VPN Pool.

Ran packet tracer: packet-tracer input inside icmp 192.168.2.1 8 0 192.168.1.5

VPN Client = 192.168.2.1/24 Gateway of: 192.168.2.2

192.168.1.5 (PC on Eth1/2 VLAN 1)

Packet tracer shows allowed?

I cannot ping PC on inside. I feel like everything is in order and I am close but just missing one thing? I included snapshots to assist.

[Rob Ingram]

@jjevans1 the AnyConnect VPN network is on the OUTSIDE, not inside. So your packet-tracer is incorrect, the source interface would be OUTSIDE if the source is 192.168.2.0/24

Your split-tunnel is incorrect, you need to allow the internal network (192.168.1.0/24)

[MHM Cisco World]

waiting your new packet-tracer after you change the interface from inside to outside, 
share packet-tracer here.

[jjevans1]

Thank you all,

Changed the Split Tunneling to Allow. Nice catch! Different then on the PeteNetLive example.

Ran new packet trace which is attached.

It looks like the packet is dropped by the default rule on Phase 4. So I think I have to create an Access Control Rule for the VPN Traffic allowing ICMP and RDP???

I really appreciate your patience and insight.

JJ

[MHM Cisco World]

No need any ACL, 
now use anyconnect user and ping inside and access RDP, all I see is OK now. 
try and share result.

[Rob Ingram]

@jjevans1 your Access Control Policy is also incorrect, you don't have a rule from outside to inside.

You need to permit from outside (192.168.2.0/24) to inside (192.168.1.0/24) aswell as the rule from inside (192.168.1.0/24 to outside (192.168.2.0/24).

@MHM Cisco World you do need Access Control rules on FTD, VPN traffic is not permitted as default unlike the ASA.

[MHM Cisco World]

thanks 

[jjevans1]

AnyConnect User: 192.168.2.1

Cannot ping PC on inside: 192.168.1.5 (PC) or 192.168.1.1 (Inside interface VLAN 1)

[jjevans1]

Created two new Access Rules: Allow VPN IN: Outside to Inside and Allow VPN Out: Inside to Outside.

Looks like ICMP was dropped in Phase 8 due to WEBVPN SVC in packet trace

[Rob Ingram]

@jjevans1 are you actually connected to the VPN on 192.168.2.1? If so use an IP address in the VPN pool that is not in use and try packet-tracer again - "packet-tracer input outside icmp 192.168.2.22 8 0 192.168.1.5" or just generate real traffic.