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

Question

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

Christophe_M 40

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.

I created NAT exemption rules on FTD for SSLVPN traffic.
All Security Groups have ICMP any any allow rule for a test.
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.
FTD capture-traffic feature doesn't see sslvpn traffic. TShoot tracer shows ALLOWED/NO NAT points.
Added SSLVPN subnet to VNet of FTD.

I belive that I missed cloud routing or something like this.

Thank you and Happy New Year!

azure

Konstantinos Passadis 19,571 Reputation points MVP

2024-01-01T20:33:20.9466667+00:00

hello @Christophe_M

Welcome to Microsoft QnA!

When you set up Peering , did you enabled the allow remote gateway traffic ?

I can see some routing rules also but i am not aware of the whole thing

So i am starting with that basic Question

Thank you !

I hope this helps!

Kindly mark the answer as Accepted and Upvote in case it helped!

Regards
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-03T09:19:55.4+00:00
@Christophe_M

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you are using a 3rd party Virtual Appliance in Azure VNET to connect your remote devices to "Azure vFTD"

Community members in Microsoft Q&A would have expertise over Microsoft/Azure Products. But the same may not be the case for third party solutions such as the above.

I'd suggest you to reach out to the third party vendor and their community channels to get more information on the configuration.

With that said,

Is it possible to deploy a VM in the FTD VNet?

If so, can you ping it?

Are you seeing the traffic reaching the FTD NVA

Is there any document you are following to configure this?

Cheers,

Kapil
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-04T11:29:14.0433333+00:00

@Christophe_M

May I know if you got a chance to review my previous comment?

Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them.

Thanks,

Kapil
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-05T10:34:14.33+00:00

@Christophe_M

Reaching out to check if there are any questions on this.

Please let us know if we can be of any further assistance here.

Thanks,

Kapil
Christophe_M 40 Reputation points

2024-01-05T12:08:18.3433333+00:00

Dear @KapilAnanth-MSFT ,

Sorry for delay and thank you for your post and time.

Is it possible to deploy a VM in the FTD VNet?

I deployed test FTD in the same VNet as linux TEST VM the very first time. It did not work for Anyconnect connections also. However, situation with everything except Anyconnect was the same good.

If so, can you ping it?

I was able ping everything except Anyconnect (through it). As now - the same situation.

Are you seeing the traffic reaching the FTD NVA

Sure. I'm able to connect to it with Anyconnect. I also can successfully ping from/to FTD INSIDE, OUTSIDE and MGMT interfaces from/to all inside and remote (S2S) resources.

Is there any document you are following to configure this?

I've worked a lot with ASA and FTD devices, many years. It's typical task to setup Anyconnect/Secure Client and ASA/FTD totally. I tried to find articles about Azure routing + Anyconnect + FTD/ASA but every manual stops on "You successfully set the Anyconnect! Perfect!" and no one shows how it works in the cloud environment. Unfortunately.

Dear @Konstantinos Passadis ,

Sorry for delay and thank you for your post and time.

Did you ask about this (the same vice versa rule on the other side):

Thank you!

BTW: I asked the same question on Cisco community but there are no answers. To be honest I believe that it's not a Cisco problem (if it's not a bug but I tried the ASAv with the same result).
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-05T12:59:24.0433333+00:00
@Christophe_M

When you say,

"I was able ping everything except Anyconnect (through it). As now - the same situation."

I did not understand this part.

Are you saying you are able to ping the 3rd party NVA "Azure vFTD" from this testLinuxVM ?

And all other VMs in the same subnet.

But not the remote devices connected to the AnyConnect.

Q1. Is the above correct?

When you say,

". I also can successfully ping from/to FTD INSIDE, OUTSIDE and MGMT interfaces from/to all inside and remote (S2S) resources."

I take it that you are talking about Server1 and Server2 in CORP1 and CORP2 respectively.

Correct me if I am wrong.

Q2. Is the above correct?

If 2 is correct,

That means NVA in VNET-FTD is able to connect VMs in VNET-Cloud

If that is the case,

Doesn't that mean the NVA should be responsible for routing the packets from the Point to Site remote devices to the VMs

What I am highlighting is that routing should be done in the OS and not in Azure Platform

Same goes for Servers in CORP Networks

Q3. I would suggest you to first make sure you are able to make this set up working for VMs in the VNET-Cloud.

Make sure NVA can ping VMs in the VNET-Cloud. (you had already confirmed this)

Make sure the devices connected to your NVA via AnyConnect are able to connect to the VMs in the VNET-Cloud

Let me know if this works.

If not, I believe you must check the OS configuration and understand why the NVA is not forwarding the traffic to VMs in the VNET-Cloud

Cheers,

Kapil.
Christophe_M 40 Reputation points

2024-01-05T20:39:40.1133333+00:00
@KapilAnanth-MSFT ,

Thank you for your time.

Q1. Is the above correct?

I can't ping enything from Anyconnect endpoints. For example: Home PC connects to Azure FTD with Anyconnect, get IP from SSLVPN pool and tries to ping server in the same as Azure FTD Vnet (the same net of the INSIDE interface of the Azure FTD) OR ping device from another VNet. I saw that my ping requests reached the remote server (from home pc to remote server) and server sent ICMP replies. But these answers never reached the home PC back.

Q2. Is the above correct?

All devices are able to ping each other. Include Azure FTD VM from all its interfaces: Management - from/to internet, Outside - from/to internet, Inside - from/to internal cloud and remote s2s vpn devices. But if I want to ping home_pc -> anyconnect -> azure_ftd -> server/remote_net_server - it does not work.

I have two routes inside FTD:

0.0.0.0/0 -> OUTSIDE interface -> Gateway of the outside net.

10.7.0.0/16, 10.3.0.0/16, 10.8.0.0/16 -> INSIDE interface -> Gateway of the inside net.

It should be enough for normal routing of the device. All SSLVPN packets flow through OUTSIDE interface -> tunnel and known nets kick traffic to INSIDE interface.

Please rate my thoughts on this issue:

My idea is a SSLVPN 10.5.250.0/24 network is a virtual network. It's not "physically" connected to the VNet. We have only MANAGEMENT and INSIDE, OUTSIDE interfaces which have IPs in 10.5.0.0/24 and 10.5.2.0/24, 10.5.1.0/24 networks. 10.5.250.0/24 lives only inside Azure FTD VM. It's a synthetic network. How Azure/VNets know where this packet should be delivered?

Just figure out: SSLVPN packet reaches the FTD through the internet by VPN tunnel, then flows from FTD INSIDE interface to VNets to destination server because of INSIDE route of the FTD and because of Azure "knows" where destination server lives (because it has interface and IP from published internal network - 10.8.1.5 and Azure "knows" it). As I wrote above I saw with tcpdump that server got the request ICMP packets from Anyconnect client and it even sent ICMP replies. This packets (replies) start their way back to FTD INSIDE interface BUT how Azure "knows" that the net 10.5.2500/24 lives after the interface INSIDE? How should I set that?
Christophe_M 40 Reputation points

2024-01-05T21:17:12.1733333+00:00

Yes, I did that :D

I got the answer on Cisco Community site:

Hi Christophe, 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

I quickly read the article and found the page with UDR RouteTables. As an example from the man I just added the route:

10.5.250.0/24 -> Virtual Appliance -> 10.5.2.4 (FTD INSIDE interface) to all route tables from all resource groups. And now it works for cloud resources!

But it's still not work for Virtual Gateway remote (S2S) clients:

on-prem server -> on-prem router -> S2S tunnel -> Azure Virtual/Local Gateway -> VNet -> VNets Peering -> VNet -> FTD -> Anyconnect client.

I checked with tcpdump on servers in that remote offices and they got the ICMP requests from Anyconnect clients and send ICMP replies. But they have never reached the Anyconnect client (back way). I inserted routes to on-prem devices (10.5.0.0/16 which includes SSLVPN pool - 10.5.250.0/24) to their VTI interfaces. Like 10.5.0.0/16 -> Tun3 and able to ping INSIDE FTD interface for example from on-prem router. But not the SSLVPN client. I believe something wrong with Virtual/Local Gateway route tables OR VNet peering settings. Could it be?

Thanks.
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-10T11:06:06.6233333+00:00
@Christophe_M

Thanks for keeping us updated.

From your latest comment, I take it that

Remote clients from AnyConnect VPN is able to ping all Azure resources (VMs in VNETs VNET-Ftd and VNET-Cloud) and vice versa

However, OnPrem clients are not able to ping/reach Remote clients connected to AnyConnect VPN.

Please correct me if I am wrong.

Observation:

I think this is because the OnPrem servers are not aware of the address range "10.5.250.0/24"

This makes sense as the VPN Gateway will not be aware of the address range "10.5.250.0/24" and will not advertise it via the S2S Tunnel.

To workaround this, please consider using Azure Route Server.

In order to advertise the range "10.5.250.0/24" to the VPN Gateway,

You must deploy the ARS

And establish BGP Peering between the ARS and your NVA

NVA would advertise the "10.5.250.0/24" to the ARS

And ARS will in turn advertise the "10.5.250.0/24" range's next Hop as NVA to all the resources in the VNET.

This way, traffic to "10.5.250.0/24" gets routed to the NVA

This also eliminates the need of UDRs in the VNET.

This is documented step by step here : Azure Route Server support for ExpressRoute and Azure VPN.

Cheers,

Kapil
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-12T17:03:38.8833333+00:00

@Christophe_M
May I know if you got a chance to review my previous comment? Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them. Thanks, Kapil
Christophe_M 40 Reputation points

2024-01-14T06:20:19.5166667+00:00

Hello @KapilAnanth-MSFT

Thank you for the answer.

I made the dump on Virtual Gateway and found that it pushed ICMP packets to on-prem servers and got the ICMP replies back. I also saw that ICMP reached the server and it generated the ICMP replies.

I do not use the BGP but I have the static routes on on-prem side (on physical routers) where all 10.5.0.0/16 net pushes to VTI tunnel. I really know that packets flow through the tunnel to the on-prem server, it generates the answers and answers reach the Virtual GW (I wrote before that I gathered tcpdump on this virtual device for IN/OUT packets). But then something happen with them. It's like the VirtualGW should have its own route table somewhere it order to be able to say: "Hey, 10.5.250.0/16 is a virtual net. It lives here 10.5.250.0/16 -> .GW:.."
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-14T18:35:20.29+00:00
@Christophe_M

Let's keep:

Forward traffic : AnyConnect Remote Users to OnPrem

Reverse traffic : OnPrem to AnyConnect Remote Users

Wrt

"I made the dump on Virtual Gateway and found that it pushed ICMP packets to on-prem servers and got the ICMP replies back."

I take it that the source here is the AnyConnect Remote Users.

This is expected.

As the VPN Gateway is aware of the destination address range, forward traffic reaches the OnPrem.

The reverse traffic uptil the VPN Gateway also makes sense as you have static routing configured in the OnPREM servers.

It's like the VirtualGW should have its own route table somewhere it order to be able to say: "Hey, 10.5.250.0/16 is a virtual net. It lives here 10.5.250.0/16 -> .GW:.."

Yes, this would be in the OS of the VPN GW instances.

(The entire VNET Range)

We can further influence this at Platform level by using Route Tables and UDR.

Next Steps

Can you please try attaching a UDR at GatewaySubnet with

Route : 10.5.250.0/24

NextHop : Internal NIC's IP of the NVA

Cheers,

Kapil
Christophe_M 40 Reputation points

2024-01-15T20:53:22.1666667+00:00

@KapilAnanth-MSFT YEP! You are genius! I even did not know that it's possible to attach UDR to GW. Thank you! If you have the schema like my, you have to publish route of virtual FTD SSLVPN network to all UDR tables. Including GW. For Virtual GW you should make a new RouteTable and attach it to GWs subnet. All your routes must pointed to FTD inside iface which hide you AC net.
Christophe_M 40 Reputation points

2024-01-16T07:49:20.2333333+00:00

Long story shot:

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.

Accepted answer

0 additional answers

Your answer

Konstantinos Passadis 19,571 Reputation points MVP

2024-01-01T20:33:20.9466667+00:00

hello @Christophe_M

Welcome to Microsoft QnA!

When you set up Peering , did you enabled the allow remote gateway traffic ?

I can see some routing rules also but i am not aware of the whole thing

So i am starting with that basic Question

Thank you !

I hope this helps!

Kindly mark the answer as Accepted and Upvote in case it helped!

Regards
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-03T09:19:55.4+00:00

@Christophe_M

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you are using a 3rd party Virtual Appliance in Azure VNET to connect your remote devices to "Azure vFTD"

Community members in Microsoft Q&A would have expertise over Microsoft/Azure Products. But the same may not be the case for third party solutions such as the above.

I'd suggest you to reach out to the third party vendor and their community channels to get more information on the configuration.

With that said,

Is it possible to deploy a VM in the FTD VNet?

If so, can you ping it?

Are you seeing the traffic reaching the FTD NVA

Is there any document you are following to configure this?

Cheers,

Kapil
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-04T11:29:14.0433333+00:00

@Christophe_M

May I know if you got a chance to review my previous comment?

Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them.

Thanks,

Kapil
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-05T10:34:14.33+00:00

@Christophe_M

Reaching out to check if there are any questions on this.

Please let us know if we can be of any further assistance here.

Thanks,

Kapil
Christophe_M 40 Reputation points

2024-01-05T12:08:18.3433333+00:00

Dear @KapilAnanth-MSFT ,

Sorry for delay and thank you for your post and time.

Is it possible to deploy a VM in the FTD VNet?

I deployed test FTD in the same VNet as linux TEST VM the very first time. It did not work for Anyconnect connections also. However, situation with everything except Anyconnect was the same good.

If so, can you ping it?

I was able ping everything except Anyconnect (through it). As now - the same situation.

Are you seeing the traffic reaching the FTD NVA

Sure. I'm able to connect to it with Anyconnect. I also can successfully ping from/to FTD INSIDE, OUTSIDE and MGMT interfaces from/to all inside and remote (S2S) resources.

Is there any document you are following to configure this?

I've worked a lot with ASA and FTD devices, many years. It's typical task to setup Anyconnect/Secure Client and ASA/FTD totally. I tried to find articles about Azure routing + Anyconnect + FTD/ASA but every manual stops on "You successfully set the Anyconnect! Perfect!" and no one shows how it works in the cloud environment. Unfortunately.

Dear @Konstantinos Passadis ,

Sorry for delay and thank you for your post and time.

Did you ask about this (the same vice versa rule on the other side):

Thank you!

BTW: I asked the same question on Cisco community but there are no answers. To be honest I believe that it's not a Cisco problem (if it's not a bug but I tried the ASAv with the same result).
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-05T12:59:24.0433333+00:00

@Christophe_M

When you say,

"I was able ping everything except Anyconnect (through it). As now - the same situation."

I did not understand this part.

Are you saying you are able to ping the 3rd party NVA "Azure vFTD" from this testLinuxVM ?

And all other VMs in the same subnet.

But not the remote devices connected to the AnyConnect.

Q1. Is the above correct?

When you say,

". I also can successfully ping from/to FTD INSIDE, OUTSIDE and MGMT interfaces from/to all inside and remote (S2S) resources."

I take it that you are talking about Server1 and Server2 in CORP1 and CORP2 respectively.

Correct me if I am wrong.

Q2. Is the above correct?

If 2 is correct,

That means NVA in VNET-FTD is able to connect VMs in VNET-Cloud

If that is the case,

Doesn't that mean the NVA should be responsible for routing the packets from the Point to Site remote devices to the VMs

What I am highlighting is that routing should be done in the OS and not in Azure Platform

Same goes for Servers in CORP Networks

Q3. I would suggest you to first make sure you are able to make this set up working for VMs in the VNET-Cloud.

Make sure NVA can ping VMs in the VNET-Cloud. (you had already confirmed this)

Make sure the devices connected to your NVA via AnyConnect are able to connect to the VMs in the VNET-Cloud

Let me know if this works.

If not, I believe you must check the OS configuration and understand why the NVA is not forwarding the traffic to VMs in the VNET-Cloud

Cheers,

Kapil.
Christophe_M 40 Reputation points

2024-01-05T21:17:12.1733333+00:00

Yes, I did that :D

I got the answer on Cisco Community site:

Hi Christophe, 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

I quickly read the article and found the page with UDR RouteTables. As an example from the man I just added the route:

10.5.250.0/24 -> Virtual Appliance -> 10.5.2.4 (FTD INSIDE interface) to all route tables from all resource groups. And now it works for cloud resources!

But it's still not work for Virtual Gateway remote (S2S) clients:

on-prem server -> on-prem router -> S2S tunnel -> Azure Virtual/Local Gateway -> VNet -> VNets Peering -> VNet -> FTD -> Anyconnect client.

I checked with tcpdump on servers in that remote offices and they got the ICMP requests from Anyconnect clients and send ICMP replies. But they have never reached the Anyconnect client (back way). I inserted routes to on-prem devices (10.5.0.0/16 which includes SSLVPN pool - 10.5.250.0/24) to their VTI interfaces. Like 10.5.0.0/16 -> Tun3 and able to ping INSIDE FTD interface for example from on-prem router. But not the SSLVPN client. I believe something wrong with Virtual/Local Gateway route tables OR VNet peering settings. Could it be?

Thanks.
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-10T11:06:06.6233333+00:00

@Christophe_M

Thanks for keeping us updated.

From your latest comment, I take it that

Remote clients from AnyConnect VPN is able to ping all Azure resources (VMs in VNETs VNET-Ftd and VNET-Cloud) and vice versa

However, OnPrem clients are not able to ping/reach Remote clients connected to AnyConnect VPN.

Please correct me if I am wrong.

Observation:

I think this is because the OnPrem servers are not aware of the address range "10.5.250.0/24"

This makes sense as the VPN Gateway will not be aware of the address range "10.5.250.0/24" and will not advertise it via the S2S Tunnel.

To workaround this, please consider using Azure Route Server.

In order to advertise the range "10.5.250.0/24" to the VPN Gateway,

You must deploy the ARS

And establish BGP Peering between the ARS and your NVA

NVA would advertise the "10.5.250.0/24" to the ARS

And ARS will in turn advertise the "10.5.250.0/24" range's next Hop as NVA to all the resources in the VNET.

This way, traffic to "10.5.250.0/24" gets routed to the NVA

This also eliminates the need of UDRs in the VNET.

This is documented step by step here : Azure Route Server support for ExpressRoute and Azure VPN.

Cheers,

Kapil
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-12T17:03:38.8833333+00:00

@Christophe_M
May I know if you got a chance to review my previous comment? Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them. Thanks, Kapil
Christophe_M 40 Reputation points

2024-01-14T06:20:19.5166667+00:00

Hello @KapilAnanth-MSFT

Thank you for the answer.

I made the dump on Virtual Gateway and found that it pushed ICMP packets to on-prem servers and got the ICMP replies back. I also saw that ICMP reached the server and it generated the ICMP replies.

I do not use the BGP but I have the static routes on on-prem side (on physical routers) where all 10.5.0.0/16 net pushes to VTI tunnel. I really know that packets flow through the tunnel to the on-prem server, it generates the answers and answers reach the Virtual GW (I wrote before that I gathered tcpdump on this virtual device for IN/OUT packets). But then something happen with them. It's like the VirtualGW should have its own route table somewhere it order to be able to say: "Hey, 10.5.250.0/16 is a virtual net. It lives here 10.5.250.0/16 -> .GW:.."
KapilAnanth-MSFT 49,421 Reputation points Microsoft Employee Moderator

2024-01-14T18:35:20.29+00:00

@Christophe_M

Let's keep:

Forward traffic : AnyConnect Remote Users to OnPrem

Reverse traffic : OnPrem to AnyConnect Remote Users

Wrt

"I made the dump on Virtual Gateway and found that it pushed ICMP packets to on-prem servers and got the ICMP replies back."

I take it that the source here is the AnyConnect Remote Users.

This is expected.

As the VPN Gateway is aware of the destination address range, forward traffic reaches the OnPrem.

The reverse traffic uptil the VPN Gateway also makes sense as you have static routing configured in the OnPREM servers.

It's like the VirtualGW should have its own route table somewhere it order to be able to say: "Hey, 10.5.250.0/16 is a virtual net. It lives here 10.5.250.0/16 -> .GW:.."

Yes, this would be in the OS of the VPN GW instances.

(The entire VNET Range)

We can further influence this at Platform level by using Route Tables and UDR.

Next Steps

Can you please try attaching a UDR at GatewaySubnet with

Route : 10.5.250.0/24

NextHop : Internal NIC's IP of the NVA

Cheers,

Kapil
Christophe_M 40 Reputation points

2024-01-15T20:53:22.1666667+00:00

@KapilAnanth-MSFT YEP! You are genius! I even did not know that it's possible to attach UDR to GW. Thank you! If you have the schema like my, you have to publish route of virtual FTD SSLVPN network to all UDR tables. Including GW. For Virtual GW you should make a new RouteTable and attach it to GWs subnet. All your routes must pointed to FTD inside iface which hide you AC net.
Christophe_M 40 Reputation points

2024-01-16T07:49:20.2333333+00:00

Long story shot:

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.

Answer 1

@Christophe_M

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I'm glad that the issue was resolved.

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others", I'll repost your solution in case you'd like to "Accept" the answer. Environment:

You had 2 VNETs peered.
One had a Azure VPN Gateway (and S2S Connection) while the other had a 3rd party NVA establish connectivity to remote clients.
You wanted to establish the following connectivity
- 1. Remote clients should be able to ping Azure servers and vice versa
- 1. Remote clients should be able to ping OnPrem servers and vice versa via Azure VNET.
Observation:
Azure will not be aware of the remote clients address range as you are using a 3rd party NVA and the configuration is done in the OS
We have to make the platform aware of the routes by incorporating UDRs (Route Table)

Solution:

1.

For traffic from Azure to Remote Clients, We create a Route Table and added the nextHop for Remote VPN Client address pool as the NVA.
This way, all traffic destined to remote clients are routed to the NVA by Azure.
For return traffic, the NVA's OS already knows the routes of the VNET and thus, no need for additional configuration.

The same logic applies here, however the Route Table must be added at the GatewaySubnet.
You confirmed this resolved the issue.

Thanks for your continued contribution on Q&A and appreciate much for taking the time to share your feedback.

Thanks,

Kapil

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Share via

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

0 additional answers

Your answer