To reduce the number of 502 bad gateway requests that are served up Application Gateway should have a retry policy for failed requests, allowing it to move the the next available server. This would be especially useful when used in front of Service Fabric where services are moved between servers.14 votes
Allow users to create microsoft peering using IPv6 and receive/advertise IPv4 subnets over it. This will save some IPv4 subnets for us.3 votes
For business purpose, we wanna offer an idea of selecting peering IP from non-GW subnet while using Azure VPN BGP. this IP was currnetly allocated from ge subnet. but we wanna change to specific IP . let's say our address space range is 10.0.0.0/16, but our GW subnet is 10.0.0.0/24, Peering IP is 10.0.0.254. but one of subnet is 10.13.100.70/28, we wanna change peering IP to 10.13.100.70. but this is impossible, could we make some changes in further?1 vote
Thanks for the suggestion – we will look into this request. But this is currently not on the roadmap.
Since many DNS providers do not allow you to export your zone files create a utility that will harvest them in a format that could be used to import them into Azure DNS.1 vote
This is in our long term backlog but not currently planned. You may want to look at OctoDNS (https://github.com/github/octodns) as an alternative.
Can you describe the technical reason why you decide not to offer this option when creating a s2s vpn and you offer only the phase1 pre-shared key method? The communications in Madrid HC Region are administered by Cesus and they follow directives from the Security Group of Madrid Digital (former ICM). In their form to require a s2s vpn only cert based is accepted for ipsec tunnels and without a clear technical reason it is almost impossible to negotiate an exception to shift to pre-shared key based phase 1 vpn1 vote
Thank you for the suggestion. The key reasons for not offering cert-based IKE authentication is due to the additional compliance requirements and validations related to handling certificates. As a result, this is currently not on the roadmap.
If certificate-based authentication is a requirement, currently customers will need to leverage a VPN appliances available from Azure Marketplace.
I would like to set up a packet filter for VPN GW.
It is the same as RRAS packet filter setting.
Inbound IP address and port range filter, and outbound IP address and port range filter.
Our VNET is connecting between sites with customers' VNET and VNET GW. Even if it is attacked from outside the customer's VNET, I do not want to endanger our VNET. I would like to filter traffic arriving at VNET with source IP and destination port number.
How can it be realized?
Thanks for the feedback. This is currently not planned. To protect your virtual network, one suggestion is to setup Network Security Group on your subnets or NICs to filtered out unwanted traffic.
Just like ios and andoroid's Azure app, I want the Azure Portal to be able to start and stop Application gateway.0 votes
Not planned as of now.
- Don't see your idea?