# AWS Outposts connectivity to AWS Regions Service link AWS Outposts supports wide area network (WAN) connectivity through the service link connection. **Topics** + [ # Connectivity through service link ](service-links.md) + [ # Service link public connectivity options ](sl-public-connectivity.md) + [ # Service link private connectivity options ](private-connectivity.md) + [ # Firewalls and the service link ](firewalls-sl.md) + [ # Outposts rack network troubleshooting checklist ](network-troubleshoot.md) # Connectivity through service link Connectivity The service link is a necessary connection between your Outposts and the AWS Region (or home Region). It allows for the management of the Outposts and the exchange of traffic to and from the AWS Region. The service link leverages an encrypted set of VPN connections to communicate with the home Region. After the service link connection is established, your Outpost becomes operational and is managed by AWS. The service link facilitates the following traffic: + Customer VPC traffic between the Outpost and any associated VPCs. + Outposts management traffic, such as resource management, resource monitoring, and firmware and software updates. ## Service link maximum transmission unit (MTU) requirements Maximum transmission unit (MTU) requirements The maximum transmission unit (MTU) of a network connection is the size, in bytes, of the largest permissible packet that can be passed over the connection. Note the following: + The network **must** support 1500-bytes MTU between the Outpost and the service link endpoints in the parent AWS Region. + The traffic that goes from an instance in Outposts to an instance in the Region has an MTU of 1300 bytes, which is lower than the required MTU of 1500 bytes due to packet overheads. ## Service link bandwidth recommendations Bandwidth recommendations For an optimal experience and resiliency, AWS requires that you use redundant connectivity of at least 500 Mbps for each compute rack and a maximum of 175 ms round trip latency for the service link connection to the AWS Region. You can use AWS Direct Connect or an internet connection for the service link. The minimum 500 Mbps and maximum round trip time requirements for the service link connection allows you to launch Amazon EC2 instances, attach Amazon EBS volumes, and access AWS services, such as Amazon EKS, Amazon EMR, and CloudWatch metrics with optimal performance. Your Outposts service link bandwidth requirements vary depending on the following characteristics: + Number of AWS Outposts racks and capacity configurations + Workload characteristics, such as AMI size, application elasticity, burst speed needs, and Amazon VPC traffic to the Region We strongly recommend consulting with your AWS sales representative or APN partner to evaluate available home Region options in your geography and seek a custom recommendation about the service link bandwidth and latency requirements for your workloads. ## Redundant internet connections When you build connectivity from your Outpost to the AWS Region, we recommend that you create multiple connections for higher availability and resiliency. For more information, see [Direct Connect Resiliency Recommendations](https://aws.amazon.com/directconnect/resiliency-recommendation/). If you need connectivity to the public internet, you can use redundant internet connections and diverse internet providers, just as you would with your existing on-premises workloads. ## Set up your service link The following steps explain the service link setup process. 1. Choose a connection option between your Outposts and the home AWS Region. You can choose either a [public](https://docs.aws.amazon.com/outposts/latest/network-userguide/sl-public-connectivity.html) or [private](https://docs.aws.amazon.com/outposts/latest/network-userguide/private-connectivity.html) connection. 1. After you order your Outposts racks, AWS contacts you to collect VLAN, IP, BGP, and infrastructure subnet IPs. For more information, see [Local network connectivity](https://docs.aws.amazon.com/outposts/latest/network-userguide/outposts-rack2ndgen-local-rack.html). 1. During installation, AWS configures service link on the Outpost based on the information you provided. 1. You configure your local networking devices, such as routers, to connect to each Outpost network device through BGP connectivity. For information on service link VLAN, IP, and BGP connectivity, see [Network connectivity requirements](outposts-rack2ndgen-requirements.md#facility-networking). 1. You configure your networking devices, such as firewalls, to enable your Outposts to access to the AWS Region or home Region. AWS Outposts utilizes the [service link infrastructure subnet IPs](https://docs.aws.amazon.com/outposts/latest/network-userguide/outposts-rack2ndgen-local-rack.html#service-link-subnet) to set up VPN connections and exchange control and data traffic with the Region. Service link establishment is always initiated from the Outpost. 1. **Note** You won't be able to modify the service link configuration or connectivity type after you complete the order. # Service link public connectivity options Public connectivity options You can configure the service link with a public connection for the traffic between the Outposts and home AWS Region. You can choose to use the public internet or Direct Connect public VIFs. If you plan on allow-listing only AWS Region public IPs (instead of 0.0.0.0/0) on your firewalls, you must ensure that your firewall rules are up-to-date with the current IP address ranges. For more information, see [AWS IP address ranges](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) in the *Amazon VPC User Guide*. The following image shows both options to establish a service link public connection between your Outposts and the AWS Region: ![\[The service link public connection options.\]](http://docs.aws.amazon.com/outposts/latest/network-userguide/images/outpost-rack2ndgen-sl-public-connection-options.PNG) **Note** Second-generation Outposts racks require a /24 or larger subnet for the service link infrastructure. This subnet is customer-provided IP address space used by Outpost networking devices to establish connectivity to AWS Region endpoints. ## Option 1. Public connectivity through the internet This option requires the AWS Outposts [service link infrastructure subnet IPs](https://docs.aws.amazon.com/outposts/latest/network-userguide/outposts-rack2ndgen-local-rack.html#service-link-subnet) to have access to the public IP ranges of your AWS Region or home Region. You must allow-list AWS Region public IPs or 0.0.0.0/0 on networking devices such as your firewall. ## Option 2. Public connectivity through Direct Connect public VIFs This option requires the AWS Outposts [service link infrastructure subnet IPs](https://docs.aws.amazon.com/outposts/latest/network-userguide/outposts-rack2ndgen-local-rack.html#service-link-subnet) to have access to the public IP ranges of your AWS Region or home Region over DX service. You must allow-list AWS Region public IPs or 0.0.0.0/0 on networking devices such as your firewall. # Service link private connectivity options Private connectivity options You can configure the service link with a private connection for the traffic between the Outposts and home AWS Region. You can choose to use Direct Connect private or transit VIFs. Select the private connectivity option when you create your Outpost in the AWS Outposts console. For instructions, see [Create an Outpost](https://docs.aws.amazon.com/outposts/latest/network-userguide/order-outpost-capacity.html#create-outpost). When you select the private connectivity option, a service link VPN connection is established after the Outpost is installed, using a VPC and subnet that you specify. This allows private connectivity through the VPC and minimizes public internet exposure. The following image shows both options to establish a service link VPN private connection between your Outposts and the AWS Region: ![\[The service link private connection options.\]](http://docs.aws.amazon.com/outposts/latest/network-userguide/images/outpost-rack2ndgen-sl-private-connection-options.PNG) **Note** Second-generation Outposts racks require a larger subnet size (/24 or larger) and a VPC Endpoint for the Outposts service. **IP Address Planning for Private Connectivity** When configuring private connectivity for the Outposts service link, plan your IP addressing carefully to avoid future conflicts. Service Link VIFs are immutable. You should avoid creating CoIP pools or DVR subnet ranges assigned to the Local Gateway (LGW) that overlap with existing Service Link address ranges or VPC CIDR ranges used for the dedicated private connectivity VPC. Overlapping prefixes across the Service Link and LGW networks may result in BGP routing conflicts on the upstream network and disrupt Service Link functionality. ## Prerequisites The following prerequisites are required before you can configure private connectivity for your Outpost: + You must configure permissions for an IAM entity (user or role) to allow the user or role to create the service-linked role for private connectivity. The IAM entity needs permission to access the following actions: + `iam:CreateServiceLinkedRole` on `arn:aws:iam::*:role/aws-service-role/outposts.amazonaws.com/AWSServiceRoleForOutposts*` + `iam:PutRolePolicy` on `arn:aws:iam::*:role/aws-service-role/outposts.amazonaws.com/AWSServiceRoleForOutposts*` + `ec2:DescribeVpcs` + `ec2:DescribeSubnets` For more information, see [AWS Identity and Access Management for AWS Outposts](https://docs.aws.amazon.com/outposts/latest/network-userguide/identity-access-management.html) + In the same AWS account and Availability Zone as your Outpost, create a VPC for the sole purpose of Outpost private connectivity with a subnet /24 or larger that does not conflict with 10.1.0.0/16. For example, you might use 10.3.0.0/16. **Important** Do not delete this VPC as it maintains the connection to your Outposts. + Configure the security group attached to the network interface to allow the following inbound traffic: + ICMP from your specified source + TCP port 443 from your specified source + UDP port 443 from your specified source **Note** Both TCP and UDP on port 443 are required for private connectivity to function properly. + Advertise the subnet CIDR to your on-premises network. You can use AWS Direct Connect to do so. For more information, see [Direct Connect virtual interfaces](https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html) and [Working with Direct Connect gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) in the *Direct Connect User Guide*. + Create a new VPC endpoint for AWS Outposts in your private connectivity VPC and subnet. Use the following VPC endpoint settings: + **Service**: Outposts (com.amazonaws.*region*.outposts) Example: `com.amazonaws.us-west-2.outposts` + **Endpoint type**: Interface + **Private DNS Enabled**: set to false (disabled) + **VPC**: the VPC you created for private connectivity + **Subnet**: the subnet you created for private connectivity Use the following **IAM policy document**: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "outposts:StartConnection", "outposts:GetConnection" ], "Effect": "Allow", "Resource": "*", "Principal": "*" } ] } ``` ------ + Create a security group for the endpoint and authorize **inbound** TCP port 443 and ICMP traffic with addresses of `0.0.0.0/0` and with no **outbound** rules. To select the private connectivity option when your Outpost is in **PENDING** status, choose **Outposts** from the AWS Outposts console and select your Outpost. Choose **Actions**, **Add private connectivity** and follow the steps. After you select the private connectivity option for your Outpost, AWS Outposts automatically creates a service-linked role in your account that enables it to complete the following tasks on your behalf: + Creates network interfaces in the subnet and VPC that you specify, and creates a security group for the network interfaces. + Grants permission to the AWS Outposts service to attach the network interfaces to a service link endpoint instance in the account. + Attaches the network interfaces to the service link endpoint instances from the account. For more information about the service-linked role, see [Service-linked roles for AWS Outposts](https://docs.aws.amazon.com/outposts/latest/network-userguide/using-service-linked-roles.html). **Important** After your Outpost is installed, confirm connectivity to the private IPs in your subnet from your Outpost. VPC configuration cannot be changed after order placement. If incorrect VPC specifications are provided during ordering, the Outpost must be decommissioned and a new order placed. ## Option 1. Private connectivity through Direct Connect private VIFs Create an AWS Direct Connect connection, private virtual interface, and virtual private gateway to allow your on-premises Outpost to access the VPC. For more information, see the following sections in the *Direct Connect User Guide*: + [Dedicated and hosted connections](https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithConnections.html) + [Create a private virtual interface](https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-private-vif.html) + [Virtual private gateway associations](https://docs.aws.amazon.com/directconnect/latest/UserGuide/virtualgateways.html) If the AWS Direct Connect connection is in a different AWS account from your VPC, see [Associating a virtual private gateway across accounts](https://docs.aws.amazon.com/directconnect/latest/UserGuide/multi-account-associate-vgw.html) in the *Direct Connect User Guide*. ## Option 2. Private connectivity through Direct Connect transit VIFs Create an AWS Direct Connect connection, transit virtual interface, and transit gateway to allow your on-premises Outpost to access the VPC. For more information, see the following sections in the *Direct Connect User Guide*: + [Dedicated and hosted connections](https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithConnections.html) + [Create a transit virtual interface to the Direct Connect gateway](https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-transit-vif-dx.html) + [Transit gateway associations](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html) # Firewalls and the service link This section discusses firewall configurations and the service link connection. In the following diagram, the configuration extends the Amazon VPC from the AWS Region to the Outpost. An Direct Connect public virtual interface is the service link connection. The following traffic goes over the service link and the Direct Connect connection: + Management traffic to the Outpost through the service link + Traffic between the Outpost and any associated VPCs ![\[Direct Connect connection to AWS\]](http://docs.aws.amazon.com/outposts/latest/network-userguide/images/intra-vpc-Nov-23.png) If you are using a stateful firewall with your internet connection to limit connectivity from the public internet to the service link VLAN, you can block all inbound connections that initiate from the internet. This is because the service link VPN initiates only from the Outpost to the Region, not from the Region to the Outpost. ![\[Internet gateway connection to AWS\]](http://docs.aws.amazon.com/outposts/latest/network-userguide/images/igw-connection-Nov-23.png) If you use a stateful firewall that is both UDP and TCP-aware to limit connectivity regarding the service link VLAN, you can deny all inbound connections. If the firewall is acting in a stateful manner, allowed outbound connections from the Outposts service link should automatically allow reply traffic back in without explicit rule configuration. Only outbound connections initiated from the Outpost service link need to be configured as allowed. | Protocol | Source Port | Source Address | Destination Port | Destination Address | | --- | --- | --- | --- | --- | | UDP | 443 | AWS Outposts service link /24 | 443 | AWS Outposts Region's public networks | | TCP | 1025-65535 | AWS Outposts service link /24 | 443 | AWS Outposts Region's public networks | If you use a non-stateful firewall to limit connectivity regarding the service link VLAN, you must allow outbound connections initiated from the Outposts service link to the AWS Outposts Region's public networks. You must also explicitly allow reply traffic in from the Outposts Region’s public networks inbound to the service link VLAN. Connectivity is always initiated outbound from the Outposts service link, but reply traffic must be allowed back into the service link VLAN. | Protocol | Source Port | Source Address | Destination Port | Destination Address | | --- | --- | --- | --- | --- | | UDP | 443 | AWS Outposts service link /24 | 443 | AWS Outposts Region's public networks | | TCP | 1025-65535 | AWS Outposts service link /24 | 443 | AWS Outposts Region's public networks | | UDP | 443 | AWS Outposts Region's public networks | 443 | AWS Outposts service link /24 | | TCP | 443 | AWS Outposts Region's public networks | 1025-65535 | AWS Outposts service link /24 | **Note** Instances in an Outpost can't use the service link to communicate with instances in another Outposts. Leverage routing through the local gateway or local network interface to communicate between Outposts. AWS Outposts racks are also designed with redundant power and networking equipment, including local gateway components. For more information, see [Resilience in AWS Outposts](https://docs.aws.amazon.com/outposts/latest/network-userguide/disaster-recovery-resiliency.html). # Outposts rack network troubleshooting checklist Network troubleshooting Use this checklist to help troubleshoot a service link that has a status of `DOWN`. ![\[Virtual LANs.\]](http://docs.aws.amazon.com/outposts/latest/network-userguide/images/outpost-rack2ndgen-servicelink-troubleshoot.png) ## Connectivity with Outpost network devices Check the BGP peering status on the customer local network devices that are connected to the Outpost network devices. If the BGP peering status is `DOWN`, follow these steps: 1. Ping the remote peer IP address on the Outpost network devices from the customer devices. You can find the peer IP address in the BGP configuration of your device. You can also refer to the [Network readiness checklist](outposts-rack2ndgen-requirements.md#network-readiness-checklist) provided to you at the time of installation. 1. If pinging is unsuccessful, check the physical connection and ensure that connectivity status is `UP`. 1. Confirm the LACP status of the customer local network devices. 1. Check the interface status on the device. If the status is `UP`, skip to step 3. 1. Check the customer local network devices and confirm that the optical module is working. 1. Replace faulty fibers and ensure the lights (Tx/Rx) are within acceptable range. 1. If pinging is successful, check the customer local network devices and ensure that the following BGP configurations are correct. 1. Confirm that the local Autonomous System Number (Customer ASN) is correctly configured. 1. Confirm that the remote Autonomous System Number (Outpost ASN) is correctly configured. 1. Confirm that the interface IP and remote peer IP addresses are correctly configured. 1. Confirm that the advertised and received routes are correct. 1. If your BGP session is flapping between active and connect states, verify that TCP port 179 and other relevant ephemeral ports are not blocked on the customer local network devices. 1. If you need to troubleshoot further, check the following on the customer local network devices: 1. BGP and TCP debug logs 1. BGP logs 1. Packet capture 1. If the issue persists, perform MTR / traceroute / packet captures from your Outpost connected router to the Outpost network device peer IP addresses. Share the test results with AWS Support, using your Enterprise support plan. If BGP peering status is `UP` between the customer local network devices and the Outpost network devices, but the service link is still `DOWN`, you can troubleshoot further by checking the following devices on your customer local network devices. Use one of the following checklists, depending on how your service link connectivity is provisioned. + Edge routers connected with Direct Connect – Public virtual interface in use for service link connectivity. For more information, see [Direct Connect public virtual interface connectivity to AWS Region](#check-dc-public). + Edge routers connected with Direct Connect – Private virtual interface in use for service link connectivity. For more information, see [Direct Connect private virtual interface connectivity to AWS Region](#check-dc-private). + Edge routers connected with Internet Service Providers (ISPs) – Public internet in use for service link connectivity. For more information, see [ISP public internet connectivity to AWS Region](#check-public-internet). ## Direct Connect public virtual interface connectivity to AWS Region Use the following checklist to troubleshoot edge routers connected with Direct Connect when a public virtual interface is in use for service link connectivity. 1. Confirm that the devices connecting directly with the Outpost network devices are receiving the service link IP address ranges through BGP. 1. Confirm the routes that are being received through BGP from your device. 1. Check the route table of the service link Virtual Routing and Forwarding instance (VRF). It should show that it is using the IP address range. 1. To ensure Region connectivity, check the route table for the service link VRF. It should include the AWS Public IP address ranges or the default route. 1. If you are not receiving the AWS public IP address ranges in the service link VRF, check the following items. 1. Check the Direct Connect link status from the edge router or the AWS Management Console. 1. If the physical link is `UP`, check the BGP peering status from the edge router. 1. If the BGP peering status is `DOWN`, ping the peer AWS IP address and check the BGP configuration in the edge router. For more information, see [Troubleshooting Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html) in the *Direct Connect User Guide* and [My virtual interface BGP status is down in the AWS console. What should I do?](https://repost.aws/knowledge-center/virtual-interface-bgp-down). 1. If BGP is established and you are not seeing the default route or AWS public IP address ranges in the VRF, contact AWS Support, using your Enterprise support plan. 1. If you have an on-premises firewall, check the following items. 1. Confirm that the required ports for service link connectivity are allowed in the network firewalls. Use traceroute on port 443 or any other network troubleshooting tool to confirm the connectivity through the firewalls and your network devices. The following ports are required to be configured in the firewall policies for the service link connectivity. + **TCP protocol** – Source port: TCP 1025-65535, Destination port: 443. + **UDP protocol** – Source port: TCP 1025-65535, Destination port: 443. 1. If the firewall is stateful, ensure that the outbound rules allow the Outpost’s service link IP address range to the AWS public IP address ranges. For more information, see [AWS Outposts connectivity to AWS Regions](region-connectivity.md). 1. If the firewall is not stateful, make sure to allow the inbound flow also (from the AWS public IP address ranges to the service link IP address range). 1. If you have configured a virtual router in the firewalls, ensure that the appropriate routing is configured for traffic between the Outpost and the AWS Region. 1. If you have configured NAT in the on-premises network to translate the Outpost’s service link IP address ranges to your own public IP addresses, check the following items. 1. Confirm that the NAT device is not overloaded and has free ports to allocate for new sessions. 1. Confirm that the NAT device is correctly configured to perform the address translation. 1. If the issue persists, perform MTR / traceroute / packet captures from your edge router to the Direct Connect peer IP addresses. Share the test results with AWS Support, using your Enterprise support plan. ## Direct Connect private virtual interface connectivity to AWS Region Use the following checklist to troubleshoot edge routers connected with Direct Connect when a private virtual interface is in use for service link connectivity. 1. If connectivity between the Outposts rack and the AWS Region is using the AWS Outposts private connectivity feature, check the following items. 1. Ping the remote peering AWS IP address from the edge router and confirm the BGP peering status. 1. Ensure that BGP peering over the Direct Connect private virtual interface between your service link endpoint VPC and the Outpost installed on your premises is `UP`. For more information, see [Troubleshooting Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html) in the *Direct Connect User Guide*, [My virtual interface BGP status is down in the AWS console. What should I do?](https://repost.aws/knowledge-center/virtual-interface-bgp-down), and [How can I troubleshoot BGP connection issues over Direct Connect?](https://repost.aws/knowledge-center/troubleshoot-bgp-dx). 1. The Direct Connect private virtual interface is a private connection to your edge router in your chosen Direct Connect location, and it uses BGP to exchange routes. Your private virtual private cloud (VPC) CIDR range is advertised through this BGP session to your edge router. Similarly, the IP address range for the Outpost service link is advertised to the region through BGP from your edge router. 1. Confirm that the network ACLs associated with the service link private endpoint in your VPC allow the relevant traffic. For more information, see [Network readiness checklist](outposts-rack2ndgen-requirements.md#network-readiness-checklist). 1. If you have an on-premises firewall, ensure that the firewall has outbound rules that allow the service link IP address ranges and the Outpost service endpoints (the network interface IP addresses) located in the VPC or the VPC CIDR. Ensure that the TCP 1025-65535 and UDP 443 ports are not blocked. For more information, see [Introducing AWS Outposts private connectivity](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/). 1. If the firewall is not stateful, ensure that the firewall has rules and policies to allow inbound traffic to the Outpost from the Outpost service endpoints in the VPC. 1. If you have more than 100 networks in your on-premises network, you can advertise a default route over the BGP session to AWS on your private virtual interface. If you don't want to advertise a default route, summarize the routes so that the number of advertised routes is less than 100. 1. If the issue persists, perform MTR / traceroute / packet captures from your edge router to the Direct Connect peer IP addresses. Share the test results with AWS Support, using your Enterprise support plan. ## ISP public internet connectivity to AWS Region Use the following checklist to troubleshoot edge routers connected through an ISP when using the public internet for service link connectivity. + Confirm that the internet link is up. + Confirm that the public servers are accessible from your edge devices connected through an ISP. If the internet or public servers are not accessible through the ISP links, complete the following steps. 1. Check whether BGP peering status with the ISP routers is established. 1. Confirm that the BGP is not flapping. 1. Confirm that the BGP is receiving and advertising the required routes from the ISP. 1. In case of static route configuration, check that the default route is properly configured on the edge device. 1. Confirm whether you can reach the internet using another ISP connection. 1. If the issue persists, perform MTR / traceroute / packet captures on your edge router. Share the results with your ISP's technical support team for further troubleshooting. If the internet and public servers are accessible through the ISP links, complete the following steps. 1. Confirm whether any of your publicly accessible EC2 instances or load balancers in the Outpost home Region are accessible from your edge device. You can use ping or telnet to confirm the connectivity, and then use traceroute to confirm the network path. 1. If you use VRFs to separate traffic in your network, confirm that the service link VRF has routes or policies that direct traffic to and from the ISP (internet) and VRF. See the following checkpoints. 1. Edge routers connecting with the ISP. Check the edge router’s ISP VRF route table to confirm that the service link IP address range is present. 1. Customer local network devices connecting with the Outpost. Check the configurations of the VRFs and ensure that the routing and policies required for connectivity between the service link VRF and the ISP VRF are configured properly. Usually, a default route is sent from the ISP VRF into the service link VRF for traffic to the internet. 1. If you configured source-based routing in the routers connected to your Outpost, confirm that the configuration is correct. 1. Ensure that the on-premises firewalls are configured to allow outbound connectivity (TCP 1025-65535 and UDP 443 ports) from the Outpost service link IP address ranges to the public AWS IP address ranges. If the firewalls are not stateful, ensure that inbound connectivity to the Outpost is also configured. 1. Ensure that NAT is configured in the on-premises network to translate the Outpost’s service link IP address ranges to public IP addresses. In addition, confirm the following items. 1. The NAT device is not overloaded and has free ports to allocate for new sessions. 1. The NAT device is correctly configured to perform the address translation. If the issue persists, perform MTR / traceroute / packet captures. + If the results show that packets are dropping or blocked at the on-premises network, check with your network or technical team for additional guidance. + If the results show that the packets are dropping or blocked at the ISP's network, contact the ISP’s technical support team. + If the results do not show any issues, collect the results from all tests (such as MTR, telnet, traceroute, packet captures, and BGP logs) and contact AWS Support using your Enterprise support plan. ## Outposts is behind two firewall devices If you have placed your Outpost behind a high-availability pair of synced firewalls or two stand-alone firewalls, asymmetric routing of the service link might occur. This means that inbound traffic could pass through firewall-1, while outbound traffic goes through firewall-2. Use the following checklist to identify potential asymmetric routing of the service link especially if it was functioning correctly before. + Verify if there were any recent changes or ongoing maintenance in your corporate network’s routing setup that might have led to asymmetric routing of the service link through the firewalls. + Use firewall traffic graphs to check for changes to traffic patterns that line up with the start of the service link issue. + Check for a partial firewall failure or a split-brained firewall-pair scenario that might have caused your firewalls to no longer sync their connection tables between each other. + Check for links down or recent changes to routing (OSPF/ISIS/EIGRP metric changes, BGP route-map changes) in your corporate network that line up with the start of the service link issue. + If you are using public Internet connectivity for the service link to the home region, a service provider maintenance could have given rise to asymmetric routing of the service link through the firewalls. + Check traffic graphs for links to your ISP(s) for changes to traffic patterns that line up with the start of the service link issue. + If you are using Direct Connect connectivity for the service link, it is possible that an AWS planned maintenance triggered asymmetric routing of the service link. + Check for notifications of planned maintenance on your Direct Connect service(s). + Note that if you have redundant Direct Connect services, you can proactively test the routing of the Outposts service link over each likely network path under maintenance conditions. This allows you to test if an interruption to one of your Direct Connect services could lead to asymmetric routing of the service link. The resiliency of the Direct Connect portion of the end-to-end network connectivity can be tested by the Direct Connect Resiliency with Resiliency Toolkit. For more information, see [Testing Direct Connect Resiliency with Resiliency Toolkit – Failover Testing](https://aws.amazon.com/blogs/networking-and-content-delivery/testing-aws-direct-connect-resiliency-with-resiliency-toolkit-failover-testing/). After you have gone through the preceding checklist and pinpointed asymmetric routing of the service link as a possible root cause, there are a number of further actions you can take: + Restore symmetric routing by reverting any corporate network changes or waiting for a provider planned maintenance to complete. + Log in to one or both firewalls and clear all flow state information for all flows from the command-line (if supported by the firewall vendor). + Temporarily filter out BGP announcements through one of the firewalls or shut the interfaces on one firewall in order to force symmetric routing through the other firewall. + Reboot each firewall in turn to eliminate potential corruption in the flow-state tracking of the service link traffic in the firewall’s memory. + Engage your firewall vendor to either verify or relax the tracking of UDP flow-state for UDP connections sourced on port 443 and destined to port 443.