paloaltonetworks:vmseries:aws_transit_gateway
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| paloaltonetworks:vmseries:aws_transit_gateway [2021/01/05 12:14] – [Spoke VPC to TGW] bstafford | paloaltonetworks:vmseries:aws_transit_gateway [2022/11/23 12:49] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 240: | Line 240: | ||
| Peer Group – Create one peer group on each firewall virtual router | Peer Group – Create one peer group on each firewall virtual router | ||
| * Name: pg-aws-tgw. | * Name: pg-aws-tgw. | ||
| + | * Enabled : True | ||
| + | * Aggregated Confed AS Path : True | ||
| + | * Soft Reset With Stored Info : False | ||
| * Type: eBGPG. | * Type: eBGPG. | ||
| * Import Next Hop: Use Peer | * Import Next Hop: Use Peer | ||
| * Export Next Hop : Use Self | * Export Next Hop : Use Self | ||
| + | * Remove Private AS : No | ||
| - | When configuring the BGP Peering, we will create a peer group for each peer. This is so that we can explicitly control what routes are imported from each peer. The peer group names should match the name of the peer, as set out in the tables below. | + | On each firewall, configure two peers within |
| - | * For each peer below, create a peer group with the same name. For each group, set | + | |
| - | * Enabled - Yes | + | |
| - | * Aggregated Confed AS Path - Yes | + | |
| - | * Soft Reset With Store Info - No | + | |
| - | * Type - EBGP | + | |
| - | * Import Next Hop - Original | + | |
| - | * Export Next Hop - Resolve | + | |
| - | * Remove Private AS – No | + | |
| - | + | ||
| - | When configuring a peer, the " | + | |
| * Auth Profile: None (not supported on AWS) | * Auth Profile: None (not supported on AWS) | ||
| * Keep Alive Interval (Sec) : 10 | * Keep Alive Interval (Sec) : 10 | ||
| Line 265: | Line 259: | ||
| Redistribution: | Redistribution: | ||
| - | We need two export rules to the same peer group. The default is done without any path pre-pending. The internal routes are prepended on the secondary firewall. The secondary firewall uses BGP prepending to make sure the neighbouring VPCs prefer the primary firewall for routing. In the PAN-OS GUI, this is set this under < | + | We have one import rule that is used by the peer group. Set action to allow and list the specific prefixes. 10.0.0.0/ |
| + | |||
| + | We need two export rules where both are to the same peer group. The default is done without any path pre-pending. That rule exports the default route and the public subnet route. Note that both firewalls will need to be unique. Firewall 1's first rule will export 0.0.0.0/0 and 10.0.11.0/ | ||
| + | |||
| + | The second export rule exports 10.0.0.0/8. The internal routes are prepended on the secondary firewall. The secondary firewall uses BGP prepending to make sure the neighbouring VPCs prefer the primary firewall for routing. In the PAN-OS GUI, this is set this under < | ||
| ===== Create Spoke VPCs ===== | ===== Create Spoke VPCs ===== | ||
| Line 301: | Line 299: | ||
| The Spoke VPCs are attached to a separate route table so you can select which routes are propagated to them to control east/west traffic flow. If you are not doing east-west security, you could use one transit gateway route table. | The Spoke VPCs are attached to a separate route table so you can select which routes are propagated to them to control east/west traffic flow. If you are not doing east-west security, you could use one transit gateway route table. | ||
| - | This means that spoke1 and spoke2 VPCs are " | + | This means that spoke1 and spoke2 VPCs are " |
paloaltonetworks/vmseries/aws_transit_gateway.1609848899.txt.gz · Last modified: (external edit)
