FTDv in Azure

[andy_4578]

We've deployed an FTDv in Azure which appears to be working okay and has internet access through the associated Azure public IP on the outside interface.

The VM's only seem to work when the default routes are supplied via Azure and use the Azure Internet.

As soon as we set a UDR on the Azure server subnet e.g 0.0.0.0/0 next hop NGFW- 10.150.4.4 all of the traffic on the server subnet (10.150.5.0/24) stops and we lose access to the servers until we take out the UDR and let the traffic route through the Azure internet route again.

Not sure where this is going wrong? I would have though an Azure UDR forcing all of the server traffic to the inside interface of the NGFW would work?

Just for info, the servers can ping the FTDv inside interface and vice versa even when the UDR is in place.

[nspasov]

Hard to tell without getting more info and probably best to reach out to TAC. But a few things to check:

1. NAT

2. Routing on FTD (E.g. does FTD know where to route for the .5 subnet)

3. Access Control Policy

Thank you for rating helpful posts!

[Mohammed al Baqari]

Hi,

We have a similar deployment and got it working fine. Do a capture on the
inside of FTD to confirm that traffic is reaching the firepower.

Also, make sure that you have a route on FTD for .5 subnet pointing to
Azure Fabric (you don't want firepower to drop the traffic because of
uRPF).

If that is good, check your ACPs to make sure traffic is allowed. Then you
need to tell us where the VPN connection terminated? Is it on FTD, Azure or
other devices (like CSR).

**** please remember to rate useful posts

[andy_4578]

Hi All,

Traffic to the .5 subnet was routed correctly, we could ping the inside interface of the FTD from the Azure VM's and vice versa.

The NAT rules to be honest there was just the single dynamic rule translating any inside address to the outside interface which should have been fine to get internet access for the VM's, there weren't any VPN's at this stage.

We believe the problem was likely on the Azure user defined routes side of things but as this is a proof of concept we dont have Cisco or Microsoft support using demo licenses.

As we ran out of time trying to get the vFTD working, we resorted to using route-based VPN tunnels using the native Azure virtual gateway which is working fine.

We'll revisit the FTDv if the proof of concept is signed off and goes into full production.

Thanks

[Mohammed al Baqari]

Hi, The problem with your dynamic nat. You should have nat exempt to
exclude LAN to LAN traffic from dynamic NAT. Did you have it?

***** please remember to rate useful posts

[andy_4578]

Hi,

Initially, we were simply trying to get the Azure VM's to go through the vFTD for there internet access so the dynamic NAT rule should have been fine, there wasn't any VPN's configured at that stage so no need for LAN to LAN traffic being exempt.

We'll try again in the future.