Describe the bug
There's a hardcoded static-route in your bootstrap XML file where the next hop is 10.0.0.1 - this means anyone using a different CIDR block will have trouble. Your input parameters allow a user to use different CIDR blocks.
Expected behavior
I expect that if I follow the instructions and choose a different CIDR block for security VNET, the solution will still work
Current behavior
The Azure GWLB health checks will fail to the Palo Alto VM if they CIDR block of the Security VNET is not 10.0.0.0/16.
This is because there is a hardcoded route where the next hop is 10.0.0.1, so that health checks from the Azure LB will be responded to correctly. But if your VNET is not 10.0.0.0/16, you'll have to find this yourself.
Possible solution
I have written automation to dynamically update the XML file based on the chosen CIDR block of the VNET. I would recommend you find a way to do the same.
The problem is here in your XML file:
<static-route>
<entry name="default">
<path-monitor>
<enable>no</enable>
<failure-condition>any</failure-condition>
<hold-time>2</hold-time>
</path-monitor>
<nexthop>
<ip-address>10.0.0.1</ip-address>
</nexthop>
<bfd>
<profile>None</profile>
</bfd>
<interface>ethernet1/1</interface>
<metric>10</metric>
<destination>168.63.129.16/32</destination>
<route-table>
<unicast/>
</route-table>
</entry>
</static-route>
Steps to reproduce
- Deploy this solution where the Security VNET is not the default 10.0.0.0/16
Screenshots


Context
Your Environment
- Version used:
- Environment name and version (e.g. Chrome 59, node.js 5.4, python 3.7.3):
- Operating System and version (desktop or mobile):
- Link to your project:
Describe the bug
There's a hardcoded static-route in your bootstrap XML file where the next hop is 10.0.0.1 - this means anyone using a different CIDR block will have trouble. Your input parameters allow a user to use different CIDR blocks.
Expected behavior
I expect that if I follow the instructions and choose a different CIDR block for security VNET, the solution will still work
Current behavior
The Azure GWLB health checks will fail to the Palo Alto VM if they CIDR block of the Security VNET is not 10.0.0.0/16.
This is because there is a hardcoded route where the next hop is 10.0.0.1, so that health checks from the Azure LB will be responded to correctly. But if your VNET is not 10.0.0.0/16, you'll have to find this yourself.
Possible solution
I have written automation to dynamically update the XML file based on the chosen CIDR block of the VNET. I would recommend you find a way to do the same.
The problem is here in your XML file:
Steps to reproduce
Screenshots
Context
Your Environment