A retail company deploys an FTDv instance in an AWS VPC to route and NAT traffic between a public subnet and a private subnet. Routes, an Elastic IP on the outside interface, and security-group rules are in place. The appliance's own HTTPS page opens, while every session that tries to transit through it times out. Which AWS instance setting should the team change so the appliance can forward traffic for other hosts?

The FTDv’s HTTPS page is reachable, but that only demonstrates access to the appliance itself; it does not prove AWS will allow the appliance to forward packets whose source or destination is another host. Disable source/destination checking on the FTDv’s network interfaces. AWS enables this check by default, and it drops transit packets that do not have the interface’s own address as their source or destination. Enabling IP forwarding in the FTDv configuration can be necessary for routing, but it does not override AWS’s separate source/destination check, so transit sessions can still time out. An outbound NAT rule can provide translated source addresses and is commonly used for private-subnet egress, but NAT alone does not authorize the ENI to forward packets; the AWS check remains in force. Changing the private subnet’s default route to the inside ENI is a standard routing step when that route is missing, but the scenario already says routes are in place, and a route change does not disable source/destination checking. Exam caveat: distinguish an appliance’s own management-plane reachability from data-plane forwarding, and do not confuse guest routing or NAT configuration with the AWS ENI forwarding control. Practical check: verify source/destination checking is disabled on each relevant ENI, then inspect VPC route tables and flow logs to confirm transit packets reach the intended interface and are not rejected elsewhere.