cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
445
Views
1
Helpful
3
Replies

Azure network and vFTD and Cisco Anyconnect (Secure Client) issue

ChristopheMi
Level 1
Level 1

Hi!

Please, I need help with the Cisco Anyconnect (Cisco Secure Client) and Azure vFTD. I've tried a bunch of options and feel like I'm missing something. May be some one made the same things.

I attached a schema of my test connection lab. The root of idea is unite few networks in one: two on-prem offices, cloud resources and FTD (for Anyconnect only). I managed to implement everything except the connectivity of Anyconnect. All branches can ping each other and also can work cloud resources (linux vm and FTD INSIDE iFace) and vice versa. However, when someone connect to vFTD by Cisco Secure Client all resources are unreachable.

  1. I created NAT exemption rules on FTD for SSLVPN traffic.
  2. All Security Groups have ICMP any any allow rule for a test.
  3. I tested ping to a cloud linux VM and to one branch server (started tcpdump on these VMs) from sslvpn client and saw that VMs got ICMP request and sent replies! But these replies never reached the remote sslvpn enpoint.
  4. FTD capture-traffic feature doesn't see sslvpn traffic. TShoot tracer shows ALLOWED/NO NAT points.
  5. Added SSLVPN subnet to VNet of FTD.

I believe that I missed cloud routing or something like this.
Thank you and Happy New Year!

azure.png

2 Accepted Solutions

Accepted Solutions

JP Miranda Z
Cisco Employee
Cisco Employee

Hi ChristopheMi,

Without diving too deep on your Azure configuration could be a bit complicated to point the problem but as you said sounds like a routing issue in your Azure (UDR), i will say is probably better to get in touch with Azure so they can help you with their environment, but i also found the following documentation that could help since the design is a bit similar to yours:

https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/srw-azure-design-guide.pdf

 

-JP-

Hope this helps!

View solution in original post

Hi again,

I won that round!

If you have a virtual net in Azure I mean some net inside VM (linux, windows, fw, etc.) the global Azure system does not know about it. You MUST add route to this net to any object that interacts with that network. In my case it was RouteTables on FTD interfaces for this Anyconnect network: AC net -> GW (INSIDE FTD iface) + on linux VM machine RouteTable AND Virtual Gateway subnet (GatewaySubnet) - made the same RouteTable and attached it to GatewaySubnet with the same route.

First tables help Azure Cloud objects to understand where the net lives.
Second table (GW) helps packets from on-prem devices find this net inside cloud.

RouteTable looks like: Destination Type: IP Address -> Destination IP Addresses -> AC net -> Next hop type: Virtual Appliance -> Next hop address: FTD Inside IP address.

Hope it helps someone.

View solution in original post

3 Replies 3

JP Miranda Z
Cisco Employee
Cisco Employee

Hi ChristopheMi,

Without diving too deep on your Azure configuration could be a bit complicated to point the problem but as you said sounds like a routing issue in your Azure (UDR), i will say is probably better to get in touch with Azure so they can help you with their environment, but i also found the following documentation that could help since the design is a bit similar to yours:

https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/srw-azure-design-guide.pdf

 

-JP-

Hope this helps!

Hi @JP Miranda Z !

Sorry for the late reply, I wanted to make sure that my question was fully answered. Thank you for your awesome answer! Yes, it was UDR! I injected a new route to 10.5.250.0/24 net to all user route tables. Like: 10.5.250.0/24 -> 10.5.2.4 (INSIDE FTD iface). Anyconnect users started seeing cloud resources. But the on-prem resources still not be able to be reached.

I got the dumps from on-prem server and Azure Vitrual GW for IN/OUT packets: pings from AC client to the server. I saw that ICMP requests flowed through VNet peering to Virtual Gateway, then dived to S2S tunnel (ICMP request on Virtual GW was captured), then I saw it on server in traffic dump. Then server generated ICMP response back (I saw this reply in server and then in Virtual GW traffic dump) but then something happened, and packet never reached the FTD/AC client. I could not be able to find Virtual GW route table but I believe that the situation is like with the UDR.

I also asked the question on MS forums but there is not luck. I wanted to publish the full aswer for people who also want to do the same connectivity. This is why I still have not closed the case. I asked my service provider to open a case for MS support and probably I would have the answer soon. I created nginx tcp stream proxy in cloud for AC and on-prem resources connectivity as a point which is visible for all schema members. However, I hope this is the temporary solution.

Thank you.

Hi again,

I won that round!

If you have a virtual net in Azure I mean some net inside VM (linux, windows, fw, etc.) the global Azure system does not know about it. You MUST add route to this net to any object that interacts with that network. In my case it was RouteTables on FTD interfaces for this Anyconnect network: AC net -> GW (INSIDE FTD iface) + on linux VM machine RouteTable AND Virtual Gateway subnet (GatewaySubnet) - made the same RouteTable and attached it to GatewaySubnet with the same route.

First tables help Azure Cloud objects to understand where the net lives.
Second table (GW) helps packets from on-prem devices find this net inside cloud.

RouteTable looks like: Destination Type: IP Address -> Destination IP Addresses -> AC net -> Next hop type: Virtual Appliance -> Next hop address: FTD Inside IP address.

Hope it helps someone.