New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify use of 'Allow forwarded traffic' #1051
Comments
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:
Is it in fact required and his test was somewhat incorrect? Or the documentation needs to updated?
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 AIf 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 BConfigure 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, 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. |
In the VNet Peering section, the doc states:
You can also configure spokes to use the hub VNet gateway to communicate with remote networks. To allow gateway traffic to flow from spoke to hub, and connect to remote networks, you must:
The third bullet is wrong. 'Allow forwarded traffic' is not required to transit traffic through a VPN gateway (I just tried it).
I believe 'Allow forwarded traffic' is only required in the scenario described in the preceding paragraph, where traffic is routed via an NVA in a hub-spoke architecture.
The doc should be clarified to properly explain the use of 'allow forwarded traffic' in each scenario.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: