The information you are about to copy is INTERNAL!
DO NOT share it with anyone outside Check Point.
CloudGuard for AWS - Transit VPC Architecture
Solution ID
sk120534
Product
vSEC for AWS, CloudGuard for AWS
Version
R80.10, R80.20
OS
Gaia
Platform / Model
AWS
Date Created
2017-10-17 00:00:00.0
Last Modified
2019-01-02 01:22:24.0
Show more details
Show less details
Solution
Table of Contents
Overview
Solution Components
Deploying Check Point Security Management Server
Creating the Transit VPC
Configure AWS
Deploy CloudGuard Gateways for AWS
Configure VPN Tunnel Interface on the on-premises Security Gateway
Configure VPN Tunnel in Check Point SmartConsole
Configure BGP on CloudGuard Gateway for AWS
Connecting Transit VPC to Spoke VPCs
Configure AWS
Configure connection between Spoke VPC to Transit VPC
Configure Gaia OS on CloudGuard Gateways for AWS
Configure VPN in Check Point SmartConsole
Configuring Remote Access VPN to the Transit VPC
Troubleshooting
Related Documentation
Related Solutions
Revision History
Click Here to Show the Entire Article
The article below provides manual deployment instructions for the Transit VPC architecture. The Security Transit VPC automated solution is now available.
The Amazon Global Transit Network is used to perform transitive routing between spoke networks through a central hub. Use this document to deploy a hub-and-spoke network topology that routes all traffic through a network transit center, a Transit VPC.
The Transit VPC simplifies network management and minimizes the number of connections needed to connect multiple Amazon VPCs and remote networks. You can create as many virtual networks as necessary and design different options for connecting the networks to each other.
Use Check Point CloudGuard together with the Transit VPC. CloudGuard delivers comprehensive security for cloud workloads and assets with VPC perimeter security services, seamless security segmentation between VPCs, and automatically established IPsec VPN connectivity between cloud environments. The solution automatically connects spoke VPCs to a central security hub VPC for seamless security inspection, VPN and NAT services.
CloudGuard integrates simply with AWS. Once the Security Management Server and security hub are deployed, every new or existing VPC that is specifically tagged is automatically configured to route all traffic. The traffic is routed via an AWS managed VPN gateway into the security hub. The VPN gateways are also added as IPsec interoperable devices. The gateways are added to the automatically established route-based VPN process, (powered by Border Gateway Protocol (BGP)), to propagate network route changes to on-premises and in cloud tenants.
The solution provides the Check Point award winning Threat Prevention suite in a transit architecture. It offers industry leading Firewall (per NSS and Gartner), IPS, HTTPS Inspection, Anti-Bot and Anti-Virus, and Zero-day protection engines. These Threat Prevention features safeguard published applications, Internet-bound traffic, and inbound access to cloud assets with complete security visibility and event analysis.
The Transit VPC architecture is recommended for several common security use cases.
Hybrid cloud
With a hybrid cloud setup, you can connect your on-premises and cloud environments, and cloud assets can have secured access to on-premises assets. The connection is established via a secured VPN connection between your Check Point Security Appliance and a CloudGuard Gateway for AWS. You can also implement a secure connection with AWS Direct Connect tunnels. For example, a front-end server in the cloud can connect to an on-premises backend database to retrieve confidential data or business logic. (see Diagram 1 below).
Diagram 1: Centralized Cloud Perimeter with Direct Connect to On-Premises
A Hybrid Cloud setup enables cloud assets to have secured access to on-premises assets. For example, a front-end server in the cloud can connect to an on-premises backend database to retrieve confidential data or business logic.
In some cases a spoke VPC needs a direct internet access that does not traverse via the VPN connection (for example if the spoke hosts a public facing application with high throughput). In such cases, it is recommended to deploy an additional DMZ/Northbound Transit VPC that is connected by VPC peering to the relevant spokes. Please note that due to the fact that VPC peering is only possible within a region, an additional DMZ/Northbound Transit VPC must be deployed per region.
Diagram 2: Transit VPC with DMZ spokes
Cloud Perimeter
The Transit VPC, as a cloud perimeter, provides Threat Prevention and Access Control to the spoke VPCs. Each VPC can be deployed in multiple Availability Zones and provide security services to multiple spoke VPCs in the environment.
Only the center VPC has access to the Internet and the spokes are limited to private subnets. All traffic to and from the spoke VPCs, is steered via the center VPC and security controls are concentrated in a single central VPC.
Transparent Proxy
The transparent proxy provides secured proxy services to the spoke VPCs. It is transparent in that the security proxy services are seamless and do not require topological changes to the protected spoke VPCs. With this solution, you do not need a CloudGuard Gateway for AWS in each of the spoke VPCs. The solution relies on VPN connections to the center (hub) VPC for Internet-bound connections.
DevOps and application owners can use the transparent proxy to deploy solutions in designated VPCs, rely on AWS native security controls only, and have advanced Threat Prevention, Next Generation Firewall, and compliance, seamlessly from the center VPC. (see Diagram 1 above).
Important note on automatic failover:
To ensure automatic failover in case of CloudGuard Gateway for AWS failure or complete AZ failure, the recommended architecture described in this document relies on BGP dynamic routing protocol established between the AWS VPN gateways, CloudGuard Gateways for AWSs in the Transit VPC and the on-premises Security Gateway (if Hybrid Cloud is required). In case of such failure within the Transit VPC, the converged components use BGP to detect the failure and update routing tables automatically to recover connectivity. This process may take some time (between a few seconds to a few minutes) depending on BGP configurations and region.
This article covers the manual configurations and procedures for deploying the solution.
Transit VPC deployment consist of 3 primary segments (internal components may vary based on the exact use case required, specifically, if an on-premises connection is required for Hybrid Cloud, and in case Direct Connect service is used):
Check Point Security Management Server deployment - the management server is responsible for managing the CloudGuard Gateways for AWS, providing centralized policy control, logging, threat analysis, updates and more essential functions. The management server can be deployed on-premises or in the cloud, in a dedicated VPC or inside the Transit VPC. The deployment and configuration of Check Point management server is described in Section 3.
On-premises IPsec tunnels to AWS Transit VPC - static or dynamic routing based VPN connections to an unattached VPN Gateway (required for using Direct Connect) or to VPC attached VPN Gateway (for non-Direct Connect setup). This setup requires the creation of a star community as the Hybrid Cloud infrastructure. The configuration of IPsec tunnels between on-premises Security Gateway and AWS VPN gateway is described in Section 4.
Transit VPC IPsec tunnels to satellite (spoke) VPCs - static or dynamic routing based VPN connections between Check Point CloudGuard Gateways for AWS and VPN Gateways, or CloudGuard Gateways for AWS in Spoke VPCs. This setup requires the creation of a second star community as the Transit solution infrastructure. The configuration of IPsec tunnels between CloudGuard Gateways for AWS on the Transit VPC and AWS VPN gateway / CloudGuard Gateway for AWS in the spoke VPCs is described in Section 5.
Diagram 3: VPN Communities
The design patterns described in this document do not include VPC Peering and rely on standard VPN connections to allow flexibility and cross-region deployment. The design patterns focus on Route Based VPN communities with end to end BGP convergence using VTIs rather than Domain Based VPN to allow flexibility and large-scale deployments. When connecting a single VPC to an on-premises deployment, a Domain-Based VPN that offers simplified configurations may be used.
The following sections describe the deployment of Hybrid Cloud infrastructure with AWS withoutDirect Connect. Since the spoke VPCs are added dynamically, we must use dynamic routing protocols as well, which in turn means that we must use route based VPN connections between the transit and spoke VPCs. Additionally, to propagate the Spoke to corporate traffic and vice versa via the Transit VPC we again need to dynamic routing (since the spokes are not directly connected to the corporate network) Additional use cases and cloud formations for detecting and reacting on the creation of new satellite VPCs will be added to this article in the future.
(3) Deploying Check Point Security Management Server
The latest recommended version of Security Management Server / Multi-Domain Security Management Server as of Oct 2017, is Check Point R80.10. For version R80, make sure you are using R80 image Take 132 or higher. The Security Management Server / Multi-Domain Security Management Server can be deployed either in AWS, or on-premises.
In order to be able to control the CloudGuard Gateways for AWS:
The Management Server must be able to initiate connections to the CloudGuard Security Gateways.
The CloudGuard Security Gateways should be able to initiate connections to the Management Server (e.g., for sending logs).
The Management Server can communicate with the CloudGuard Gateways over either private IP addresses or public IP addresses. Communication over private IP addresses is possible in any one of the following cases:
The management is in the same VPC as the CloudGuard Security Gateways.
The management is in another VPC that is peered with the VPC, in which the CloudGuard Security Gateways are deployed.
The management is in an on-premises network that has connectivity to the VPC over Direct Connect.
The management is in an on-premises network that has connectivity to the VPC over a VPN connection.
In all other cases, the Management Server and CloudGuard Gateways communicate with each other using public IP addresses.
Procedures:
Deploying a Management Server in AWS
Follow the instructions in this section if you plan to deploy your Management Server in AWS.
Use the following AWS CloudFormation template to deploy the management:
R80.10 Installation and Upgrade Guide (chapter "Installing Security Management Server on Gaia" or chapter "Installing Multi-Domain Security Management")
Before performing these steps, prepare unique IP addresses to be assigned to the VPN Tunnel interfaces.
Procedure:
Connect with a web browser to the Gaia Portal of your on-premises Security Gateway.
In the Network Management section, click on the Network Interfaces page.
In the Interfaces section, click on the Add button, and in the drop-down menu click on the VPN Tunnel option (also known as VTI).
Configure the VPN Tunnel interface.
Make sure the box Enable is checked.
In the VPN Tunnel ID field, select any unique value (e.g., 1).
In the Peer field, enter the name of teh CloudGuard for AWS Security Gateways deployed in the Transit VPC as it appears in the SmartConsole.
In the VPN Tunnel Type section, select the option Numbered.
In the Local Address field, enter a unique IP address. Note: This IP address must be on a different subnet than the IP addresses configured on the CloudGuard Gateway itself and can be any unique IP. Note: When you configure the other VTI terminus on the CloudGuard for AWS Gateway deployed in the Transit VPC this will match the value of the Remote Address.
In the Remote Address field, enter another unique IP address. Note: When you configure the other VTI terminus on the CloudGuard for AWS Gateway deployed in the Transit VPC this will match the value of the Local Address.
Example:
Click OK.
Repeat the steps (4-B) and (4-C) for the VPN tunnel connecting the second CloudGuard for AWS Gateway:
In the Peer field, enter the name of the 2nd CloudGuard for AWS Security Gateway deployed in the Transit VPC as it appears in the SmartConsole.
Connect with a web browser to the Gaia Portal of your CloudGuard for AWS Security Gateway.
Repeat steps 2-4 for your CloudGuard for AWS Gateway.
In the Peer field, enter the name of the on-premises Security Gateway as it appears in the SmartConsole
In the Local Address field, enter the value used in the on-premises Remote Address field.
In the Remote Address field, enter the value used in the on-premises Local Address field.
This can alternatively be configured from clish:
For the on-premises Security Gateway:
add vpn tunnel #1 type numbered local <LOCAL-ADDRESS#1> remote <REMOTE-ADDRESS#1> peer <CloudGuard-A>
add vpn tunnel #2 type numbered local <LOCAL-ADDRESS#2> remote <REMOTE-ADDRESS#2> peer <CloudGuard-B>
set interface vpnt#1 state on
set interface vpnt#2 state on
save config
For the CloudGuard for AWS Security Gateways:
add vpn tunnel #1 type numbered local <REMOTE-ADDRESS#> remote <LOCAL-ADDRESS#> peer <ON-PREM>
set interface vpnt#1 state on
save config
(4-D) Creating the Transit VPC - Configure VPN Tunnel in Check Point SmartConsole
Configure BGP on your on-premises Security Gateway:
Description and Comments
Syntax
1. Configure the local AS number
The Border Gateway Protocol (BGP) uses the Autonomous System Number to identify a routing domain that is administered as a unit that presents a unified routing policy to the outside world. You can read more about Autonomous System Number at IANA or APNIC FAQ.
set AS <COPORATE_AS_VALUE>
2. Configure eBGP and the remote AS (The AS that is configured on the CloudGuard for AWS Gateway)
set bgp external remote-as <REMOTE_AS_VALUE> on
3. Define the new BGP peer - CloudGuard Gateway for AWS, based on the tunnel IP addresses that were configured earlier.
<REMOTE_VTI_IP> is the IPv4 of the BGP peer Enable the specified external BGP peer group. A peer group must be enabled before any peer in the group can be configured.
Routing information is exchanged with another BGP router by establishing a peer connection. This peer connection must be configured on both routers. If both peers have the same Autonomous System (AS) number, then the peers must be configured as internal peers. Otherwise, the peers must be configured as external peers.
set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> on
4. (Optional) Configure to detect if the BGP peer is down with ping (it can help in case fast recovery is needed).
Enable or disable ping for this peer using 'on' or 'off'. If ping is enabled and an established BGP peer stops responding to pings, then after a configured number of missed pings (set using 'set bgp ping count #'), the BGP peer will be forced from an established state to reconnect manually. Peers with this feature enabled must be able to receive and respond to echo requests, or they will not function correctly. If this feature is disabled for this peer, it will continue to handle BGP connections according to the protocol without any assistance from pings to verify connectivity.
set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> ping on
5. Accept med (metric) attributes recived from external peer.
set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> accept-med on
Configure the route maps for BGP route redistribution and import route filtering on your on-premises Security Gateway:
NOTE: Incoming BGP routes are not installed into the routing kernel by default. To install incoming routes, a route map is needed.
Description and Comments
Syntax
1. Create a route map to filter inbound routes
set routemap <NAME_IN> id <ID_NUMBER> on
2. Specify which networks will be matched.
<REMOTE_NETWORK> is the received network that we want to install into the routing table (this is what the Perimeter advertises.
set routemap <NAME_IN> id <ID_NUMBER> match network <REMOTE_NETWORK> [all | between | exact | off]
3. Associate the inbound routemap to the BGP peer (which routes are expected to be received from the BGP peer).
set bgp external remote-as <REMOTE_AS_VALUE> peer <remote VTI IP> import-routemap <NAME_IN> preference <1- 65535> on
4. Configure redistribution using a route map (This is what the perimeter advertises)
set routemap <NAME_OUT> id <ID_NUMBER> on
5. Configure matched routing protocol. If this match condition is not specified the default in this case is to export only BGP routes to the BGP protocol.
set routemap <NAME_OUT> id <ID_NUMBER> match protocol <PROTOCOL>
6. Specify which networks will be matched.
<LOCAL_NETWORK> is the specific network to advertise into BGP
set routemap <NAME_OUT> id <ID_NUMBER> match network <LOCAL_NETWORK> [all | between | exact | off]
7. Associate the outbound routemap to the BGP peer (which routes are expected to be advertised to the BGP peer).
set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> export-routemap <NAME_OUT> preference <1-65535> on
NOTE: Additional fine tuning can be done using routmap commands.
Save the configuration:
save config
Verify the BGP neighborship:
show bgp peers
Note: The "State" column should show "Established". Any other state means that BGP neighborship is down.
Example output:
Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
PeerID AS Routes ActRts State InUpds OutUpds Uptime
1.1.193.1 65001 2 2 Idle 2 1 00:01:35
Repeat steps (4-E) 1-3 to configure the BGP and routemap for each of your CloudGuard for AWS Security Gateways.
At the end of this process the output of the 'show bgp peers' command should show the status as Established.
The following procedure is required for connecting spoke VPCs (in Check Point VPN terminology referred to as satellites) to the Transit hub VPC (in Check Point VPN terminology referred to as center). This procedure configures the AWS VPN gateways as interoperable VPN device in Check Point Security Management Server, establishes the VPN tunnels, and sets the BGP between the center CloudGuard Gateways for AWS and the VPN Gateways in the Spoke VPCs.
The suggested architecture is also valid for Spoke VPCs in different regions. BGP configuration is also required to allow proper convergence of the topology and automatic failover in case of AZ or Gateway failures. To allow BGP convergence on top of IPsec tunnels, VTI must be configured on the Check Point devices. Note this setup does not support load sharing for the same Spoke VPC connection or for communication between spokes. At any given time, only a single CloudGuard Gateway for AWS on the Transit VPC maintains the tunnels between spoke VPCs. This solution does support route based load sharing via BGP configuration.
Diagram 5: Example Topology
Procedure
(5-A) Connecting Transit VPC to Spoke VPCs - Configure AWS
Next, you must create the subnet, which is the actual network block where your EC2 instance resides..
Naturally, you can configure multiple subnets for the same VPC.
Example:
Create the Route Table:
Example:
Example:
Destination
Target
Status
Propagated
10.0.0.0/16
local
Active
No
Notes:
Do not forget to associate the subnet(s) to the routing tables.
Propagate the routes - it allows your virtual private gateway to automatically propagate routes to the route tables so that you do not need to enter VPN routes into your route tables manually.
Notes:
When defining your route table, make sure to route the relevant traffic via the VGW.
Do not forget to associate the subnet(s) to the routing tables.
Propagate the routes - it allows your virtual private gateway to automatically propagate routes to the route tables, so that you do not need to enter VPN routes into your route tables manually.
(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC
Configure VPN connection between your Spoke and each of the CloudGuard Gateways for AWS (that serve as the "customer gateways").
Notes:
Important - Creating AWS VPN Connection objects requires the user to define an inside IP address size /30 CIDR for each tunnel. While creating a VPN Connection, AWS can automatically generate those CIDRs. However, it is highly recommended to manually set, and also to maintain those private CIDRs. This is because AWS does not guarantee that the CIDRs will not collide cross accounts and cross regions. If Checkpoint Transit hub Gateways are connected to duplicate IP addresses, it might lead to an unexpected result and it is not supported.
In the example below, we will use Spoke-A VPC as the name of the VPC.
Repeat these steps for both CloudGuard Gateways in the Transit VPC.
Procedure:
In the VPC Dashboard, go to the Virtual Private Gateways and create a new Virtual Private Gateway ("Spoke-A-VGW").
Example:
Attach the Virtual Private Gateway to your VPC (VPC for "SpokeA").
Go to the VPN Connections section and select Create VPN Connection:
In the Virtual Private Gateway field, select the Virtual Private Gateway you created in the previous step.
In the Customer Gateway row, select New.
In the IP Address field, enter the public IP address of the Customer Gateway ("CloudGuard_A").
In the BGP ASN field, enter an ASN, or leave the default value.
In the Routing Options row, select Dynamic (requires BGP).
Under Tunnel Option, make sure to set manual and unique values of IP addresses /30 CIDR ranges for the Inside IP CIDR fields.
Click on Yes, Create button.
Note: For redundancy, AWS Virtual Private Gateways have two IP addresses and generate two VPN tunnels per gateway.
Example:
In the VPN Connections, select the newly created VPN connection and click on the Download Configuration:
In the Vendor field, select Generic.
In the Platform field, select Generic.
In the Software field, select Vendor Agnostic.
Click the Yes, Download button.
Example:
Open the downloaded configuration file and fill the following table.
These parameters will be used later to configure the CloudGuard Gateway side.
Example of configuration for Tunnel 1 Example:
Name
Example
TUN1-IKE-SA-PRE-SHARED-KEY
O7X4GgkHgGeeT_.j5CiljBEEF1lXPJ6y
TUN1-OUTSIDE-VIRTUAL-PRIVATE-GATEWAY
52.21.15.173
TUN1-OUTSIDE-CUSTOMER-GATEWAY
52.26.75.35
TUN1-INSIDE-CUSTOMER-GATEWAY
169.254.44.170
TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY
169.254.44.169
Example of configuration for Tunnel 2:
Name
Example
TUN2-IKE-SA-PRE-SHARED-KEY
SDFeVGmEedr7_xjTBcawdutE_tTWmetS
TUN2-OUTSIDE-VIRTUAL-PRIVATE-GATEWAY
52.21.218.247
TUN2-OUTSIDE-CUSTOMER-GATEWAY
52.26.76.52
TUN2-INSIDE-CUSTOMER-GATEWAY
169.254.44.182
TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY
169.254.44.181
Example of configuration common to both tunnels:
Name
Example
CUSTOMER-GATEWAY-IP-ADDRESS
198.51.100.10
CUSTOMER-GATEWAY-ASN
65000
VIRTUAL-PRIVATE-GATEWAY-ASN
7224
NEIGHBOR-HOLD-TIME
30
IPSEC-DPD-INTERVAL
10
IPSEC-DPD-RETRIES
3
TCP-MSS-ADJUSTMENT
1387
TUNNEL-INTERFACE-MTU
1500
(5-C) Connecting Transit VPC to Spoke VPCs - Configure Gaia OS on CloudGuard Gateways for AWS
(5-C-i) Configure Virtual Tunnel Interface (VTI) and initial BGP
Connect to the command line (over SSH) to your CloudGuard Gateway for AWS.
Log in to the Gaia Clish.
Run the following commands:
Notes:
Replace the variables in the commands surrounded by {} with the values you filled in the tables in the section "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC".
"AWS_VPC_Tun1" and "AWS_VPC_Tun2" are the names of the interoperable devices in SmartConsole (make sure they match when you create the VTI, or when you create the peer's gateway in SmartConsole).
The numbers #1 and #2 represent available tunnel numbers. Run 'show interfaces' to see the currently configured vpnt interfaces (if any exist), and use the next consecutive number.
Clish commands are provided to facilitate easier automation. It is also possible to configuring the VTI via the Gaia Web-UI as described in section "(4-C) Creating the Transit VPC - Configure VPN Tunnel Interface on the on-premises Security Gateway"
add vpn tunnel #1 type numbered local {TUN1-INSIDE-CUSTOMER-GATEWAY} remote {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} peer AWS_VPC_Tun1
add vpn tunnel #2 type numbered local {TUN2-INSIDE-CUSTOMER-GATEWAY} remote {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} peer AWS_VPC_Tun2
set interface vpnt#1 state on
set interface vpnt#1 mtu {TUNNEL-INTERFACE-MTU}
set interface vpnt#2 state on
set interface vpnt#2 mtu {TUNNEL-INTERFACE-MTU}
save config
(5-C-ii) Configure BGP on the CloudGuard for AWS Security Gateway
Similar to section "(4-E) Creating the Transit VPC - Configure BGP on the on-premises Security Gateway and on the CloudGuard for AWS Security Gateway" , this section shows how to configure BGP between the CloudGuard Gateway for AWS and the AWS VGW.
The commands provided below have to be issued in Gaia Clish.
Configure BGP on your CloudGuard for AWS Security Gateway:
set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} on
set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} holdtime {NEIGHBOR-HOLD-TIME}
set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} keepalive 10
(optional) set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} ping on
set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} on
set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} holdtime {NEIGHBOR-HOLD-TIME}
set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} keepalive 10
(optional) set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} ping on
save config
Configure the route maps for BGP route redistribution and import route filtering on your on-premises Security Gateway:
Description and Comments
Syntax
1. Create a route map to filter inbound routes
set routemap <NAME_IN> id <ID_NUMBER> on
2. Specify which networks will be matched.
<REMOTE_NETWORK> is the received network that we want to install into the routing table (this is what the Perimeter advertises.
set routemap <NAME_IN> id <ID_NUMBER> match network <REMOTE_NETWORK> [all | between | exact | off]
3.Associate the inbound routemap to the BGP peer (which routes are expected to be received from the BGP peer).
set bgp external remote-as <REMOTE_AS_VALUE> peer <remote VTI IP> import-routemap <NAME_IN> preference <1- 65535> on
4. Configure redistribution using a route map (This is what the perimeter advertises)
set routemap <NAME_OUT> id <ID_NUMBER> on
5. Configure matched routing protocol. If this match condition is not specified the default, in this case, is to export only BGP routes to the BGP protocol.
set routemap <NAME_OUT> id <ID_NUMBER> on set routemap <NAME_OUT> id <ID_NUMBER> match network 0.0.0.0/0 exact
set routemap <NAME_OUT> id <ID_NUMBER #2> match protocol static
6. Specify the aspath-prepend-count value for this route.
The <VALUE>, in this case, is used to define the active member for the specific spoke. The CloudGuard for AWS with the lower value will be the active member for this spoke.
Causes the local Autonomous System (AS) number to be affixed to the beginning of the AS path when routes matching the Route Map are advertised via BGP.
Value: 1 - 25
The provided value indicates the number of times the local AS number should be prepended.
This action only applies to BGP, and only applies when exporting routes via the "export-routemap" command. The action is otherwise ignored.
set routemap <NAME_OUT> id <ID_NUMBER> action aspath-prepend-count value <VALUE>
7. Associate the outbound routemap to the BGP peer.
set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> export-routemap <NAME_OUT> preference <1-65535> on
NOTE: Additional fine tuning can be done using routmap commands.
Save the configuration:
save config
Verify the BGP neighborship:
show bgp peers
Note: The "State" column should show "Established". Any other state means that BGP neighborship is down.
Example output:
Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
PeerID AS Routes ActRts State InUpds OutUpds Uptime
169.254.64.125 7224 1 1 Established 1 1 00:01:35 169.254.63.52 7224 1 0 Established 1 1 00:02:21
In cases where spoke to spoke communication is a requirement the exported routemap must be updated.
set routemap <NAME_OUT> id <ID_NUMBER #2> on
set routemap <NAME_OUT> id <ID_NUMBER #2> match network <TARGET_SPOKE_VPC> all
set routemap <NAME_OUT> id <ID_NUMBER #2> action aspath-prepend-count <VALUE>
<NAME_OUT> - Is the same routemap configured in step 2.
<VALUE>- This value will designate the active/standby CloudGuard for AWS members. This value must be consistent across all spokes to avoid asymetric routing.
For spokes in the same AS (share a region), the user should allow autonomous system override (as_override) on each CloudGuard Gateway for AWS in the Transit VPC: set bgp external remote-as <REMOTE_AS> peer <REMOTE_PEER> as-override on
save config
(5-D) Connecting Transit VPC to Spoke VPCs - Configure VPN in Check Point SmartConsole
Connect with SmartConsole to Security Management Server / Domain Management Server.
Create a new Interoperable Device:
Go to the Objects menu - go to the More object types menu - go to the Network Object menu - go to the More menu - click on the New Interoperable Device...
Configure the general properties of this Interoperable Device:
In the Name field, enter the exact peer used for the first VTI (e.g., AWS_VPC_Tun1).
In the IPv4 Address field, enter the {TUN1-OUTSIDE-VIRTUAL-PRIVATE-GATEWAY} (refer to section "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC")
Example:
Configure the topology of this Interoperable Device:
Click on the Topology pane.
In the VPN Domain section, select the option Manually defined.
In the right corner of this field, click on the ellipsis [...]
If you have already created an empty group in a previous section, you can use that group and skip the next four steps.
Click on the New...
Go to the Group menu.
Click on the Simple Group...
Example:
Enter some unique name and click on OK (do not add any objects to this group)
Example:
In the right corner of this field, click on the ellipsis [...] - select the new empty Group object
Example:
Click OK
Create additional Interoperable Devices for the second tunnel and the tunnels from the second CloudGuard for AWS Security Gateway. (refer to section "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC").
Configure your Transit VPC CloudGuard for AWS Security Gateway objects:
Open the object of your Transit VPC CloudGuard for AWS Security Gateway.
Click on the Topology pane.
Click on the Get Interfaces with Topology button to update the topology with the information on the vpnt interfaces.
In the VPN Domain section, select the option Manually defined.
In the right corner of this field, click on the ellipsis [...] - select the empty Group object you created earlier in Step 2 (in the Interoperable Device properties).
Expand the IPsec VPN group and click on Link Selection.
Click on the Statically NATed IP: radial button and enter your {TUN1-OUTSIDE-CUSTOMER-GATEWAY} (CloudGuard for AWS Gateway EIP)
Click OK.
Create a new Star VPN community:
On the left Navigation Toolbar, click on the SECURITY POLICIES app.
In the lower Access Tools section, click on the VPN Communities.
At the top, click on the [*] icon - click on the Star Community.
Example:
Enter the name of this VPN community.
In the left tree, click on the Gateways pane:
In the Center Gateways section, add your Transit VPC CloudGuard for AWS Security Gateways.
In the Satellite Gateways section, add your Interoperable Devices.
Example:
In the left tree, click on the Encryption pane:
In the Encryption Method section, select the option IKEv1 for IPv4 and IKEv2 for IPv6 only
In the Encryption Suite section, select the option Custom encryption suite and configure the encryption settings. Important Note: These settings must match the settings in the configuration file you downloaded from AWS (refer to "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC")
In the More section, check the box use Perfect Forward Secrecy and select Group 2 (1024 bit)
Example:
In the left tree, click on the Shared Secret pane:
Select the option Use only Shared Secret for all external members
The objects of the Interoperable Devices should already appear.
Configure the pre-shared secret as found in the configuration file you downloaded from AWS (refer to section "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC")
Example:
In the left tree, click on the Advanced pane:
In the IKE (Phase 1) section, in the Renegotiate IKE security associations every (minutes) field, enter the value 480
In the IKE (Phase 2) section, in the Renegotiate IPsec security associations every (seconds) field, leave the default value 3600
Example:
Click OK.
Add explicit rules to allow traffic between the Spoke networks and the Transit VPC.
On the left Navigation Toolbar, click on the SECURITY POLICIES app.
In the upper Access Control section, click on the Policy.
Add explicit relevant rules.
Publish the session and install the Access Policy on all relevant Security Gateways.
Optional: It is recommended to enable the Dead Peer Detection (DPD).
Important Note: If you change these settings, then it is necessary to install the Access Policy on all relevant Security Gateways.
Optional: It is recommended to enable TCP MSS Clamping.
Enabling TCP MSS Clamping is required in most instances. Depending on your ISP, the MSS value supplied by AWS may work correctly. However, internal testing has shown that sometimes it is necessary to adjust the MSS on Check Point Gateway as low as 1380 bytes.
Important Note: If you change these settings, then it is necessary to install the Access Policy on the on-premises Security Gateway.
Test the environment by initiating end-to-end connections according to the policy.
Note: At the end of this proceedure there should be four tunnels per spoke (each VGW has 2 tunnels for redundancy, connected to two differnt CloudGuard for AWS Security Gateway).
(6) Configuring Remote Access VPN to the Transit VPC
This section explains how to configure Remote Access VPN to a corporate gateway, so that it allows a Remote Access client to reach a spoke VPC network.
Note: The procedure below describes a basic working configuration that can be customized according to more specific needs.
Prerequisites
The environment is already configured with:
AWS CloudGuard Transit gateways with BGP routes to the spoke VPC
Site-to-Site VPN with BGP routes between transit gateways and corporate gateway
Users and (optional) user groups that should connect as VPN clients
Configuration on SmartConsole
Under 'Network Objects > Network', create the following objects:
Spoke VPC network
Corporate network
(optional) Network for Office Mode (you can also use the default Office Mode pool)
Under 'Network Objects > Groups > Network Groups', create a "Corporate Encryption Domain" group and add to it the spoke and corporate networks, as well as VTI address on corporate gateway.
Under VPN communities, edit RemoteAccess community (this community is created by default).
Add the corporate gateway as Participating Gateway.
(optional) Under Participate User Group, add the user group you want to use.
Edit the corporate gateway object.
Navigate to 'Network Management > VPN Domain', click on "Set domain for Remote Access Community ". Select RemoteAccess, click on "Set " and use the Corporate Encryption Domain group you created before.
Navigate to 'IPSec VPN > Link Selection', click "Source IP address settings " and verify that it is set to "Automatic".
Navigate to 'VPN Clients > Office Mode', select "Allow Office Mode to all users". Select option "Manual (using IP pool)" and set your Office Mode network object
Navigate to 'VPN Client > Remote Access', enable "Support Visitor Mode", and leave the service as "HTTPS".
Install policy on all gateways.
Configuration of BGP on the gateways
Connect to clish on the corporate gateway.
Add a static route from the Office Mode network to the external interface.
Add a route to the routemap exported to the transit gateways with the Office Mode network.
Connect to clish on the transit gateway.
Add a route to the routemap imported from the corporate gateway with the Office Mode network.
Configuration example:
(172.16.10.0/24 = Office Mode network range, eth0 = external interface of corporate gateway, ExportAWS = corporate routemap exported to transit, ImportCorp = AWS routemap imported from corporate)
On the corporate gateway:
corporate_gw> set static-route 172.16.10.0/24 nexthop gateway logical eth0 on
corporate_gw> show route static
[...]
S 172.16.10.0/24 via 0.0.0.0, eth0, cost 0, age 11136
corporate_gw> show configuration routemaps
[...]
set routemap ExportAWS id 10 on
set routemap ExportAWS id 10 allow
set routemap ExportAWS id 10 match network 172.16.10.0/24 all
set routemap ExportAWS id 10 match protocol static
# set bgp external remote-as 65002 peer 10.0.0.2 export-routemap ExportAWS preference 10 on
You should now see the Office Mode route advertised to the AWS BPG peers
Transit-A> show configuration routemaps
set routemap ImportCorp id 10 on
set routemap ImportCorp id 10 allow
set routemap ImportCorp id 10 match network 172.16.10.0/24 all
# set bgp external remote-as 65001 peer 10.0.0.1 import-routemap ImportCorp preference 10 on
You should see the Office Mode network route received from corporate
Transit-A> show bgp peers received
BGP Neighbor 10.0.0.1 eBGP (AS 65001)
IPv4 Route MED LocalPref Nexthop Communities
[ ]
172.16.10/24 None N/A (eBGP) 10.0.0.1
The configuration is done and you can now test if a Remote Access client connected to Corporate can reach AWS spoke networks.
In this section we will show an example of the clish configuration for an environment based on Diagram 6. Diagram 6: Test environment
Clish configuration from each Security Gateway:
On the Corporate Security Gateway: # Numbered VTI add vpn tunnel 1 type numbered local 169.255.254.100 remote 169.255.254.101 peer Spoke-A add vpn tunnel 2 type numbered local 169.255.254.102 remote 169.255.254.103 peer Spoke-B
# Configure the routemaps for the spokes set routemap Spoke-A-In id 10 on set routemap Spoke-A-In id 10 allow set routemap Spoke-A-In id 10 match network 10.10.0.0/16 all set routemap Spoke-B-In id 10 on set routemap Spoke-B-In id 10 allow set routemap Spoke-B-In id 10 match network 10.20.0.0/16 all set routemap Spoke-Out id 10 on set routemap Spoke-Out id 10 allow # We do not want the Corporate Security Gateway to act as the default gateway for the spokes. set routemap Spoke-Out id 10 match network 0.0.0.0/0 exact restrict on set routemap Spoke-Out id 10 match protocol static
# Local corporate static routes set routemap Spoke-Out id 20 on set routemap Spoke-Out id 20 allow set routemap Spoke-Out id 20 match network 192.168.0.0/16 all set routemap Spoke-Out id 20 match protocol static
# Configure BGP set bgp external remote-as 65002 on set bgp external remote-as 65002 peer 169.255.254.101 on set bgp external remote-as 65002 peer 169.255.254.101 accept-med on set bgp external remote-as 65002 peer 169.255.254.101 ping on set bgp external remote-as 65002 peer 169.255.254.101 export-routemap "Spoke-Out" preference 10 on set bgp external remote-as 65002 peer 169.255.254.101 import-routemap "Spoke-A-In" preference 10 on set bgp external remote-as 65002 peer 169.255.254.101 import-routemap "Spoke-B-In" preference 20 on set bgp external remote-as 65002 peer 169.255.254.103 on set bgp external remote-as 65002 peer 169.255.254.103 accept-med on set bgp external remote-as 65002 peer 169.255.254.103 ping on set bgp external remote-as 65002 peer 169.255.254.103 export-routemap "Spoke-Out" preference 10 on set bgp external remote-as 65002 peer 169.255.254.103 import-routemap "Spoke-A-In" preference 10 on set bgp external remote-as 65002 peer 169.255.254.103 import-routemap "Spoke-B-In" preference 20 on
On CloudGuard-A Security Gateway:
# Numbered VTI tunnels add vpn tunnel 1 type numbered local 169.255.254.101 remote 169.255.254.100 peer Corporate-GW add vpn tunnel 2 type numbered local 169.254.64.110 remote 169.254.64.109 peer CloudGuard-A_To_Spoke-A_Tun1 add vpn tunnel 3 type numbered local 169.254.65.174 remote 169.254.65.173 peer CloudGuard-A_To_Spoke-A_Tun2 add vpn tunnel 4 type numbered local 169.254.65.198 remote 169.254.65.197 peer CloudGuard-A_To_Spoke-B_Tun1 add vpn tunnel 5 type numbered local 169.254.65.154 remote 169.254.65.153 peer CloudGuard-A_To_Spoke-B_Tun2
# Configure the routemap # Routemap towards the Corporate Network set routemap Corporate-In id 10 on set routemap Corporate-In id 10 allow set routemap Corporate-In id 10 match network 192.168.0.0/16 all set routemap Corporate-Out id 10 on set routemap Corporate-Out id 10 allow # aspath-prepend-count value set to 1 to designate CloudGuard-A as the active member for network 10.10.0.0/16 (Spoke A) set routemap Corporate-Out id 10 match network 10.10.0.0/16 all set routemap Corporate-Out id 10 action aspath-prepend-count value 1 set routemap Corporate-Out id 20 on set routemap Corporate-Out id 20 allow
# aspath-prepend-count value set to 2 to designate CloudGuard-A as the standby member for network 10.20.0.0/16 (Spoke B) set routemap Corporate-Out id 20 match network 10.20.0.0/16 all set routemap Corporate-Out id 20 action aspath-prepend-count value 2 # Routemap towards Spoke-A
set routemap Spoke-A-In id 10 on set routemap Spoke-A-In id 10 allow set routemap Spoke-A-In id 10 match network 10.10.0.0/16 all set routemap Spoke-A-Out id 10 on set routemap Spoke-A-Out id 10 allow # Set CloudGuard-A as the active default gateway member for Spoke-A (This setting can alternate between spokes) set routemap Spoke-A-Out id 10 match network 0.0.0.0/0 exact set routemap Spoke-A-Out id 10 match protocol static set routemap Spoke-A-Out id 10 action aspath-prepend-count value 1 set routemap Spoke-A-Out id 20 on set routemap Spoke-A-Out id 20 allow
# Network 10.20.0.0 (Spoke B) is advertised to Spoke-A with an aspath-prepend-count value set to 1 to designate CloudGuard-A as the active member for spoke to spoke communication (Spoke-A will be the active member for spoke to spoke communication across all spokes) set routemap Spoke-A-Out id 20 match network 10.20.0.0/16 all set routemap Spoke-A-Out id 20 action aspath-prepend-count value 1 # Routemap towards Spoke-B set routemap Spoke-B-In id 10 on set routemap Spoke-B-In id 10 allow set routemap Spoke-B-In id 10 match network 10.20.0.0/16 all set routemap Spoke-B-Out id 10 on set routemap Spoke-B-Out id 10 allow # Set CloudGuard-A as the standby default gateway member for Spoke-B (This setting can alternate between spokes) set routemap Spoke-B-Out id 10 match network 0.0.0.0/0 exact set routemap Spoke-B-Out id 10 match protocol static set routemap Spoke-B-Out id 10 action aspath-prepend-count value 2 set routemap Spoke-B-Out id 20 on set routemap Spoke-B-Out id 20 allow
# Network 10.10.0.0 (Spoke A) is advertised to Spoke-B with an aspath-prepend-count value set to 1 to designate CloudGuard-A as the active member for spoke to spoke communication (Spoke-A will be the active member for spoke to spoke communication across all spokes) set routemap Spoke-B-Out id 20 match network 10.10.0.0/16 all set routemap Spoke-B-Out id 20 action aspath-prepend-count value 1
# Configure BGP set bgp external remote-as 7224 on set bgp external remote-as 7224 peer 169.254.64.109 on # Since Spoke A and Spoke B are both in the same AS this setting is required to allow spoke to spoke communication set bgp external remote-as 7224 peer 169.254.64.109 as-override on set bgp external remote-as 7224 peer 169.254.64.109 holdtime 30 set bgp external remote-as 7224 peer 169.254.64.109 keepalive 10 set bgp external remote-as 7224 peer 169.254.64.109 export-routemap "Spoke-A-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.64.109 import-routemap "Spoke-A-In" preference 10 on set bgp external remote-as 7224 peer 169.254.65.153 on set bgp external remote-as 7224 peer 169.254.65.153 as-override on set bgp external remote-as 7224 peer 169.254.65.153 holdtime 30 set bgp external remote-as 7224 peer 169.254.65.153 keepalive 10 set bgp external remote-as 7224 peer 169.254.65.153 export-routemap "Spoke-B-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.65.153 import-routemap "Spoke-B-In" preference 10 on set bgp external remote-as 7224 peer 169.254.65.173 on set bgp external remote-as 7224 peer 169.254.65.173 as-override on set bgp external remote-as 7224 peer 169.254.65.173 holdtime 30 set bgp external remote-as 7224 peer 169.254.65.173 keepalive 10 set bgp external remote-as 7224 peer 169.254.65.173 export-routemap "Spoke-A-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.65.173 import-routemap "Spoke-A-In" preference 10 on set bgp external remote-as 7224 peer 169.254.65.197 on set bgp external remote-as 7224 peer 169.254.65.197 as-override on set bgp external remote-as 7224 peer 169.254.65.197 holdtime 30 set bgp external remote-as 7224 peer 169.254.65.197 keepalive 10 set bgp external remote-as 7224 peer 169.254.65.197 export-routemap "Spoke-B-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.65.197 import-routemap "Spoke-B-In" preference 10 on set bgp external remote-as 65001 on set bgp external remote-as 65001 peer 169.255.254.100 on set bgp external remote-as 65001 peer 169.255.254.100 ping on set bgp external remote-as 65001 peer 169.255.254.100 export-routemap "Corporate-Out" preference 10 on set bgp external remote-as 65001 peer 169.255.254.100 import-routemap "Corporate-In" preference 10 on
On CloudGuard-B Security Gateway:
# Numbered VTI add vpn tunnel 1 type numbered local 169.255.254.103 remote 169.255.254.102 peer Corporate-GW add vpn tunnel 2 type numbered local 169.254.64.142 remote 169.254.64.141 peer CloudGuard-B_To_Spoke-A_Tun1 add vpn tunnel 3 type numbered local 169.254.66.38 remote 169.254.66.37 peer CloudGuard-B_To_Spoke-A_Tun2 add vpn tunnel 4 type numbered local 169.254.67.122 remote 169.254.67.121 peer CloudGuard-B_To_Spoke-B_Tun1 add vpn tunnel 5 type numbered local 169.254.65.218 remote 169.254.65.217 peer CloudGuard-B_To_Spoke-B_Tun2
# Configure the routemap # Routemap towards the Corporate Network set routemap Corporate-In id 10 on set routemap Corporate-In id 10 allow set routemap Corporate-In id 10 match network 192.168.0.0/16 all set routemap Corporate-Out id 10 on set routemap Corporate-Out id 10 allow
# aspath-prepend-count value set to 2 to designate CloudGuard-B as the standby member for network 10.10.0.0/16 (Spoke A) set routemap Corporate-Out id 10 match network 10.10.0.0/16 all set routemap Corporate-Out id 10 action aspath-prepend-count value 2 set routemap Corporate-Out id 20 on set routemap Corporate-Out id 20 allow
# aspath-prepend-count value set to 1 to designate CloudGuard-B as the active member for network 10.20.0.0/16 (Spoke B) set routemap Corporate-Out id 20 match network 10.20.0.0/16 all set routemap Corporate-Out id 20 action aspath-prepend-count value 1
# Routemap towards Spoke-A set routemap Spoke-A-In id 10 on set routemap Spoke-A-In id 10 allow set routemap Spoke-A-In id 10 match network 10.10.0.0/16 all set routemap Spoke-A-Out id 10 on set routemap Spoke-A-Out id 10 allow
# Set CloudGuard-B as the standby default gateway member for Spoke-A (This setting can alternate between spokes) set routemap Spoke-A-Out id 10 match network 0.0.0.0 exact set routemap Spoke-A-Out id 10 match protocol static set routemap Spoke-A-Out id 20 on set routemap Spoke-A-Out id 20 allow
# Network 10.20.0.0 (Spoke B) is advertised to Spoke-A with an aspath-prepend-count value set to 2 to designate CloudGuard-B as the standby member for spoke to spoke communication (Spoke-B will be the standby member for spoke to spoke communication across all spokes) set routemap Spoke-A-Out id 20 match network 10.20.0.0/16 all set routemap Spoke-A-Out id 20 action aspath-prepend-count value 2 # Routemap towards Spoke-B set routemap Spoke-B-In id 10 on set routemap Spoke-B-In id 10 allow set routemap Spoke-B-In id 10 match network 10.20.0.0/16 all set routemap Spoke-B-Out id 10 on set routemap Spoke-B-Out id 10 allow
# Set CloudGuard-B as the active default gateway member for Spoke-B (This setting can alternate between spokes) set routemap Spoke-B-Out id 10 match network 0.0.0.0/0 exact set routemap Spoke-B-Out id 10 match protocol static set routemap Spoke-B-Out id 10 action aspath-prepend-count value 1 set routemap Spoke-B-Out id 20 on set routemap Spoke-B-Out id 20 allow
# Network 10.10.0.0 (Spoke A) is advertised to Spoke-B with an aspath-prepend-count value set to 2 to designate CloudGuard-B as the standby member for spoke to spoke communication (Spoke-B will be the standby member for spoke to spoke communication across all spokes ) set routemap Spoke-B-Out id 20 match network 10.10.0.0/16 all set routemap Spoke-B-Out id 20 action aspath-prepend-count value 2
# Configure BGP set bgp external remote-as 7224 on set bgp external remote-as 7224 peer 169.254.64.141 on
# Since Spoke A and Spoke B are both in the same AS this setting is required to allow spoke to spoke communication set bgp external remote-as 7224 peer 169.254.64.141 as-override on set bgp external remote-as 7224 peer 169.254.64.141 holdtime 30 set bgp external remote-as 7224 peer 169.254.64.141 keepalive 10 set bgp external remote-as 7224 peer 169.254.64.141 export-routemap "Spoke-B-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.64.141 import-routemap "Spoke-B-In" preference 10 on set bgp external remote-as 7224 peer 169.254.65.217 on set bgp external remote-as 7224 peer 169.254.65.217 as-override on set bgp external remote-as 7224 peer 169.254.65.217 holdtime 30 set bgp external remote-as 7224 peer 169.254.65.217 keepalive 10 set bgp external remote-as 7224 peer 169.254.65.217 export-routemap "Spoke-A-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.65.217 import-routemap "Spoke-A-In" preference 10 on set bgp external remote-as 7224 peer 169.254.66.37 on set bgp external remote-as 7224 peer 169.254.66.37 as-override on set bgp external remote-as 7224 peer 169.254.66.37 holdtime 30 set bgp external remote-as 7224 peer 169.254.66.37 keepalive 10 set bgp external remote-as 7224 peer 169.254.66.37 export-routemap "Spoke-B-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.66.37 import-routemap "Spoke-B-In" preference 10 on set bgp external remote-as 7224 peer 169.254.67.121 on set bgp external remote-as 7224 peer 169.254.67.121 as-override on set bgp external remote-as 7224 peer 169.254.67.121 holdtime 30 set bgp external remote-as 7224 peer 169.254.67.121 keepalive 10 set bgp external remote-as 7224 peer 169.254.67.121 export-routemap "Spoke-A-Out" preference 10 on set bgp external remote-as 7224 peer 169.254.67.121 import-routemap "Spoke-A-In" preference 10 on set bgp external remote-as 65001 on set bgp external remote-as 65001 peer 169.255.254.102 on set bgp external remote-as 65001 peer 169.255.254.102 ping on set bgp external remote-as 65001 peer 169.255.254.102 export-routemap "Corporate-Out" preference 10 on set bgp external remote-as 65001 peer 169.255.254.102 import-routemap "Corporate-In" preference 10 on
The output of 'show bgp peers':
Corporate> show bgp peers Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer PeerID AS Routes ActRts State InUpds OutUpds Uptime 169.255.254.101 65002 2 1 Established 22 3 07:25:16 169.255.254.103 65002 2 1 Established 23 3 07:25:10
CloudGuard-A> show bgp peers Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer PeerID AS Routes ActRts State InUpds OutUpds Uptime 169.254.64.109 7224 1 1 Established 1 2 02:24:47 169.254.65.153 7224 1 1 Established 1 7 04:14:22 169.254.65.173 7224 1 0 Established 3 6 04:13:45 169.254.65.197 7224 1 0 Established 1 7 04:13:39 169.255.254.100 65001 1 1 Established 3 22 07:25:25
CloudGuard-B> show bgp peers Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer PeerID AS Routes ActRts State InUpds OutUpds Uptime 169.254.64.141 7224 1 1 Established 1 2 01:42:10 169.254.65.217 7224 1 1 Established 1 2 01:42:22 169.254.66.37 7224 1 0 Established 1 2 01:42:04 169.254.67.121 7224 1 0 Established 1 5 04:14:32 169.255.254.102 65001 1 1 Established 3 23 07:25:50
1711020601.png){kind=spacer}
1711020609.png){kind=spacer}
1711020628.png){kind=spacer}
1711020635.png){kind=spacer}
1711210419.png){kind=spacer}
