Architecture-center: Clarify use of 'Allow forwarded traffic'

Hi @jtuliani Thank you for reporting this issue! We will review and make any necessary changes.

+1, I would also add that we should note that when enabling forwarded traffic on the VNet, users need to consider that the Azure NICs also need to have forwarding enabled (we can simply link to here).

I spent lots of time trying to figure out why my Linux VM's couldn't reach each other in peered VNets following this guide until I realized there was an extra setting on the NICs to enable too.

Thank you so much - this item has been moved to our internal backlog for documentation refinement.

@doodlemania2 the documentation still states that "allow forwarded traffic" is required. Judging by @jtuliani testing it should not, and the documentation should be changed.

Here you answered that it is required:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment-506504344

This is a great question! We do that so the peers can talk to each other by way of routing via the hub. Without it, the packets would drop as they attempted to exit the spoke destined for the hub and vice-versa. Let us know if that still doesn't explain it well and we can look at re-wording!

Is it in fact required and his test was somewhat incorrect? Or the documentation needs to updated?

You can also configure spokes to use the hub gateway to communicate with remote networks. To allow gateway traffic to flow from spoke to hub, and connect to remote networks, you must:

• Configure the peering connection in the hub to allow gateway transit.
• Configure the peering connection in each spoke to use remote gateways.
• Configure all peering connections to allow forwarded traffic.

I also suggest that we don't close the issue here until it is done. The internal process doesn't matter to the community, otherwise we just run into situations like this.

thanks for sharing this feedback @jtuliani and @evandropomatti, we really appreciate this 😸

I think that this refers to the Virtual Network Peering section under Recommendations where based on my understanding, two different scenarios are being discussed.

Scenario A

If you require spokes to connect to each other without peering them.

For this case scenario, please let us share from the Create a peering docs the following:

_"If this checkbox is not checked for the peering between each spoke virtual network and the hub virtual network, traffic doesn't flow between the spoke virtual networks because the hub is not forwarding the traffic between the virtual networks."_

Additionally,

_"You don't need to check this setting if traffic is forwarded between virtual networks through an Azure VPN Gateway."_

Scenario B

Configure spokes to use the hub gateway to communicate with remote networks. For this very particular configuration, Allow forwarded traffic is not required.

That being said, please let us re-open this issue since I agree while reading the docs that this is good idea to make a distinction in here.

As part of this revision, please let's also consider to indicate on which peering these checks are really required (i.e. Scenario B, [x] Use remote gateways is required from spoke-hub peering, while [x] Allow gateway transit is required from hub-spoke peering, and [] Allow forwarded traffic could remain un-checked for both) provided that is the author's preference. A side by side view of this might be ideal.

Just to conclude and in all fairness, current configuration will work well for both scenarios A + B, so they are not conflicting each other. Given that, for the sake of simplicity we might want to keep the ARM(s) as-is for now.

@ferantivero I think you nailed it and we can close the issue now.