156-561 · Question #120
What MS Azure feature needs to be configured to allow traffic to the gateway?
The correct answer is C. IP Forwarding. IP Forwarding must be enabled on an Azure virtual machine's network interface (NIC) when that VM acts as a network virtual appliance (NVA) or gateway. By default, Azure drops traffic where the destination IP doesn't match the NIC's own IP - enabling IP Forwarding tells Azure to…
Question
What MS Azure feature needs to be configured to allow traffic to the gateway?
Options
- AUser defined routes
- BSource/Destination Check
- CIP Forwarding
- DIP Check
How the community answered
(14 responses)- A14% (2)
- B7% (1)
- C71% (10)
- D7% (1)
Explanation
IP Forwarding must be enabled on an Azure virtual machine's network interface (NIC) when that VM acts as a network virtual appliance (NVA) or gateway. By default, Azure drops traffic where the destination IP doesn't match the NIC's own IP - enabling IP Forwarding tells Azure to allow the NIC to receive and forward packets destined for other addresses, which is essential for any routing/gateway role.
Why the distractors are wrong:
- A. User Defined Routes (UDRs) control where traffic is directed (routing tables), but UDRs alone don't allow the gateway VM to accept forwarded packets - IP Forwarding is still needed on the NIC itself.
- B. Source/Destination Check is an AWS concept (used on EC2 instances), not an Azure feature - it doesn't exist in Azure networking.
- D. IP Check is not a real Azure feature at all - a distractor meant to sound plausible alongside the other options.
Memory tip: Think of IP Forwarding as "unlocking" the NIC - Azure locks NICs to only accept traffic addressed to them by default. A gateway needs to receive traffic addressed to others, so you must unlock it with IP Forwarding. If you see "gateway VM" or "NVA" in a question, think IP Forwarding.
Topics
Community Discussion
5The correct answer is C, IP Forwarding. In Azure, every NIC drops packets that are not addressed to its own IP by default, so when you have a gateway or network virtual appliance sitting in the path of your traffic, you have to enable IP Forwarding on that NIC to let it pass packets along to other destinations. A lot of people mix this up with User Defined Routes, but UDRs just tell Azure where to send traffic, they do not actually allow the gateway VM to forward it onward. Source/Destination Check in option B is an AWS concept, not Azure, so if you see that on this exam it is a trap answer. Anyone in the group want to weigh in on how this pairs with UDRs in a typical hub-and-spoke setup? I feel like that combination shows up in lab scenarios pretty often and it would be good to nail down both pieces together.
Anjali nailed the AWS trap but worth adding that the UDR next-hop has to point to the NVA's private IP, not the subnet, otherwise the NIC-level IP Forwarding flag does nothing useful in prod.
Took me a second on this one because I kept second-guessing myself between A and C, but then I remembered that a gateway by definition has to receive packets not addressed to it and then send them somewhere else, so the NIC has to have IP Forwarding enabled or Azure just drops that traffic. Seen this exact thing bite a network engineer I worked with years back when he spun up a virtual appliance and could not figure out why nothing was routing through it, turned out IP Forwarding was sitting there disabled the whole time.
IP Forwarding on the NIC is the non-negotiable part, but worth adding for anyone who gets burned again: you also have to pair it with a user-defined route in the subnet route table pointing traffic at that appliance, or packets never reach it in the first place.
IP Forwarding lets the NIC pass traffic not destined for its own IP, right?