Hi Patricia,
Here's an example with a typical deployment scenario. I'm assuming FTDv is registered with FMCv (if not, we can provide some additional info).
FTDv
inside outside Azure
VM -------- gig0/0 gig0/1 ------Internet GW----- Internet
ipVM ipIN ipOUT
..........ipPublic
Configure the gig0/0 and gig0/1 interfaces with the Private IP addresses that are assigned to them in Azure (ipIN and ipOUT). ( FTDv gig0/0 maps to the 3rd NIC in Azure. FTDv gig0/1 maps to the 4th NIC in Azure). Name them ( "inside" and "outside" for example). And give them zones ("inside" and "outside" for example").
Then create a new Public IP in Azure and associated it with your "outside" interface. This will be the effective Public IP for your backend server.
Once that's done, packets coming from internet will get NATed by Azure to your FTDv outside Private IP (ipOUT). You would then configure a NAT rule in FTDv (via FMCv gui) to NAT the traffic to the backend IP (ipVM in the diagram).
In FMC->Devices->NAT, create a "Threat Defense NAT" policy and add a rule like this:
This example will send HTTP to the backend server (ipVM):
NAT Rule: Manual NAT Rule
Type: Static
Enable: enabled
Interface objects: source interface: "outside" destination interface: "inside"
Translation:
Original Source: any-ipv4(0.0.0.0/0)
Original Destination: Source Interface IP
Original Source Port: <blank>
Original Dest Port: HTTP
Translated Source: Destination Interface IP
Translated Destination: inside-server (an object you create for ipVM)
Translated Source Port: <blank>
Translated Destination Port: HTTP
Once that's done, Packets from the internet should be forwarded to your backend server - they will have a Source IP of FTDv's inside interface (ipIN) which is needed for the return path.
There are variations in how to do this but this is a good example.
(Also, Make sure no Network Security Groups on the NICs or Subnets are blocking your traffic of interest.)
