Trying to get a config operational to support Avaya Remote Worker in our Azure tenant, behind an FTDv.
The existing configuration has (2) interfaces, call then OUTSIDE and INSIDE.
This existing config necessitates activating and configuring an additional interface, dedicated to this Avaya setup, call it TCOUTSIDE.
The FTDv in Azure, not having any L2, doesn't really let NATs work normally - Azure is assigning RFC1918 IPs to the interfaces via DHCP, and Azure is handling the translation of public IP to the interface of the FTDv.
As such, our NAT looks like:
nat (TCOUTSIDE,INSIDE) source static any-IP interface destination static interface AvayaRemoteWorker
Now, this functions most of the way. Traffic hits the TCOUTSIDE interface, and is NAT'd through to the AvayaRemoteWorker (SYN).
It responds (SYN-ACK), and it gets back to the FTDv, which then drops it due to no adjacency/no route to host.
This seems to be because the default route points to the OUTSIDE interface.
A static route, configured for testing, to the public IP of the originating Internet host, gets the SYN-ACK to it's destination, and everything works.
Unfortunately, because we're going to have hundreds, if not thousands of dynamic clients hitting this, we can't create static routes, and even if we could, this would break items hosted via the OUTSIDE interface, which we can't do.
Shouldn't the firewall be able to send this traffic back to the TCOUTSIDE interface, due to it being stateful, and the fact that the NAT has the source interface configured?
TAC has not been of any assistance with this, and is at the stage of giving up without any satisfactory resolution.
Surely we can't be the only entity who's wanted to do something like this?
