Couldn't you create another TGW 'behind' the Palo Altos and attach VPC1 and VPC2 to it. This way traffic would have to flow through the Palos which is what you are trying to achieve. Currently your topology looks as if you have placed all of your EC2 compute in the DMZ in front of the firewall perimeter, except maybe worse as traffic to those hosts is not secured by the firewall, so they are more like bastion hosts.  Granted this is all a private network so the above statement is probably not that alarming(!) but it makes more sense to place the compute logically behind the firewalls.   cheers, Seb. ... View more

Hi there, The TGW which the DX links are attached to will have been configured with an ASN. This ASN will be part of the AS_PATH attached to the /32 prefix which it is received by the Palo Altos. As such the TGW will not accept /32 being advertised from the Palo Alto as a loop avoidance measure. To mitigate this issue you need to have the TGW ASN only appear once in the routing path.   A possible solution would be to create a VPN tunnel from the on-premise hub site direct to the virtual Palo Alto, then allow the virtual Palo Alto to peer with the TGW via the VPN attachments. The TGW ASN would then only appear once in the AS_PATH.   cheers, Seb. ... View more

Hi there, Sounds like a standard branch site setup.   Create a Layer3 interface on the firewall and place it in a trusted security zone. Then either create a untagged Layer2 interface for this VLAN and connect the firewalls MGMT port to it via Ethernet cable. If you have additional switches, it makes sense to preserve your firewall interfaces and instead create a Layer2 trunk interface with sub-interfaces (including your new management VLAN) and connect that to the switch. You would then connect the MGMT interface to a switchport on the switch as an access port. You would then need to configure security policy to allow your management security zone to communicate with your outside untrust zone. The Layer3 interface in the untrust zone if it were connected to the public internet would be responsible for NAT'ing the management traffic which was trying to reach PAN update servers.   cheers, Seb.      cheers, Seb. ... View more

Hi there, An old post, but certainly worth unearthing!   The behaviour you are seeing is to be expected in an OSPF topology. For OSPF to function correctly each participating router in an area needs to have same LSDB contents. This, as you have seen can give sub-optimal routing paths as prefixes are advertised by seemingly distant routers.   You mention route suppression, but that will only work on an ABR, and as you said, all of the routers are in the same OSPF Area. However using redistribution profiles in this topology would be the wrong approach as to stop HA-B learning HA-A prefixes, HA-A would need to filter those routes. You end up in the paradox where all of the External routes are being filtered by HA-A (and HA-B) leaving the branch with no External routes in its LSDB   The remaining OSPF solution would be to place the branch firewall in a stub area. A stub area will not receive External routes (Type-5) and instead the HA firewalls will advertise a default route. The branch will continue to advertise Types 1,2 and 3 to the HA firewalls. This solution will result in the HA firewalls not viewing the branch router as a transit path.   Another option would be to use eBGP. The BGP path selection would ensure that prefixes being received by the HA firewalls which originate from the opposing HA firewall via the branch firewall would be ignored due to the local AS appearing the AS_PATH.   cheers, Seb. ... View more

Hi there, From the CLI try:   clear dhcp lease interface ethernet1/12 ip 192.168.200.102   cheers, Seb.  ... View more

Hi there, On the CLI, the ping command defaults to being sourced via the management interface. Can you try your test again but source it from the outside interface IP:   eg for PA-VM-01: ping source <PA-VM-01-outside_IP> host <PA-VM-02-outside_IP>   cheers, Seb. ... View more

Hi there,  What additional Options have you specified in the DHCP scope? DNS?   cheers, Seb. ... View more

Hi there, Looking at your output we can see that all of the prefixes with a next-hop of  172.19.197.130 are static routes. When we look at the output of the BGP RIB we can see that only a subset of the static routes are present (ie, the component prefixes of 172.25.0.0/16 are missing).  Obviously you must have a redistribution profile in place which selects static routes, however it can't just be filtering on next-hop as you are missing some of the static routes, so it must be filtering on destination prefix. In which case I imagine your 10.104.55.0/24 is not in the list. Can you share the output of    set cli config-output-format set configure show network virtual-router  XYZ-L3 protocol bgp redist-rules    ...for each of the redistribution rule names outputted above eg: FOO-01, feed those names into the command below:   eg: show network virtual-router XYZ-L3 protocol redist-profile FOO-01   cheers, Seb. ... View more