Skip to main content

Configure a GATE service

To consume a GATE service, the Anapaya EDGE appliance must have an IP-in-SCION tunneling domain configured that advertises the customer's service IP prefix(es) into the SCION network via the GATE.

Prerequisites​

Before configuring the EDGEs for GATE, the following prerequisites must be met:

  1. SCION AS configuration — The EDGEs must be configured with a SCION AS and be connected to the SCION network.
  2. GATE service ordered — The GATE service has been ordered from a reseller, and the following information have been obtained from the GATE reseller:
    1. GATE ISD-ASes — List of GATE ASes which provide the selected GATE profile.
    2. Service IP address — Either reseller assigned or a customer-provided IP prefix.

EDGE configuration​

warning

The following configuration assumes appliance version v0.41 or later.

The following shows the minimal IP-in-SCION tunneling domain configuration for an EDGE connecting to a GATE provider.

Loading...

Refer to the IP-in-SCION tunneling configuration reference for a detailed explanation of each field and additional configuration options.

Prefixes learned from the GATE are redistributed to the LAN

The GATEs announce the prefixes of the networks they serve to the EDGE. Depending on the profile, this can be a large number of prefixes covering all ISPs of the profile. If the EDGE is connected to the customer LAN using BGP, it redistributes all of these prefixes to its LAN BGP peers, so the LAN router learns a route via the EDGE for every network reachable through the selected GATEs. Traffic from the LAN towards those networks then takes the SCION path via the EDGE instead of the regular internet path.

To control this, either restrict what the EDGE accepts from the GATEs with the prefixes.accept_filter of the tunneling remote (see the IP-in-SCION tunneling configuration reference), or filter and deprioritize the prefixes on the LAN router for which traffic should not be routed via the EDGE.

LAN integration and service configuration​

If the EDGE is integrated with the LAN via BGP rather than via static routes or VRRP, account for the prefixes the GATEs announce as described in the warning above. See EDGE LAN integrations for an overview of the LAN integration options.

The diagrams below show the same EDGE and tunneling configuration integrated into the customer LAN in three common approaches. Each one combines an approach to bind the service IP address with an approach to route the return traffic back to the EDGE. Both aspects, including further options, are described in the sections that follow. The addressing is an example and needs to be adapted to your setup.

Option 1: Service directly connected Customer ISD-AS 1-ff00:1:20 · GATE service IP 193.29.20.2/31 GATE AS SCION ISP of the EDGE Residential users EDGE LAN IP 10.10.0.2/24 optional Internet uplink ✕ no internet route in this VRF Service 10.10.0.50/24 + alias 193.29.20.2 (GATE service IP) The EDGE is the only gateway for the service: it is either directly connected, or the firewall in between sits in a VRF that has no internet route. In both cases the replies reach the EDGE without any extra routing configuration. Anapaya EDGE GATE AS SCION ISP Residential users Firewall or router Service / server Internet uplink SCION link IP connectivity Inbound traffic from the GATE Return traffic to the GATE Example addressing — adapt it to your own setup.

Service IP address​

The service IP address (or prefix) assigned during GATE service ordering must be bound to the protected service so that it can receive traffic arriving from the SCION network.

There are three common approaches to achieve this:

  1. Bind the IP address directly on the service — The simplest option. Assign the GATE-provided IP address as an additional IP address on the server's network interface (e.g., as a loopback alias).
  2. DNAT on an existing firewall — If a firewall or load balancer already sits in front of the service, configure a Destination NAT (DNAT) rule that forwards traffic arriving at the GATE-provided IP to the internal service IP.
  3. DNAT on the EDGE — Available since appliance v0.40. The EDGE can be configured to perform the DNAT directly. Refer to the NAT configuration reference for details.

Return traffic routing​

When a residential user's traffic arrives at the EDGE via the GATE and is forwarded to the service, the service must route its reply traffic back through the same EDGE. If the EDGE is the only gateway between the service and the outside world, this happens naturally. If there is also a regular internet path available, additional configuration is needed to prevent asymmetric routing.

Choose one of the following options:

Option 1: Service directly connected​

If the protected service is on a network segment that is directly connected to the EDGE and there is no other default gateway for that segment, no additional routing configuration is required. The EDGE automatically forwards the traffic to the service and return traffic reaches the EDGE by default.

The same holds if a firewall or router sits between the EDGE and the service, as long as it reaches the service in a VRF that has no internet connectivity. Without a competing default route, the reply traffic is still sent to the EDGE.

Option 2: Policy based routing​

If the service is not directly connected to the EDGE and there is a router or firewall between the EDGE and the service that also has access to the public internet, configure policy-based routing (PBR) on that device. The PBR rule must ensure that traffic sourced from the service IP addresses is sent back toward the EDGE rather than via the default internet gateway.

Option 3: Ingress source NAT on the EDGE​

If the service has an existing internet path and policy-based routing on the service host or upstream firewall is not feasible, configure ingress source NAT (SNAT) on the EDGE. The EDGE rewrites the source IP of packets arriving from the SCION tunnel to one of its own addresses, so that reply traffic is automatically routed back to the EDGE.

Refer to the NAT — Ingress source NAT section for the configuration details.

warning

Downside of this approach: The service will see the source IP of the EDGE rather than the original client. This may impact logging, access control, or application behavior that relies on the client's IP address.

Option 4: Load balancer returning to the last hop​

If the service is terminated on a load balancer, the load balancer may be able to send the reply traffic of a connection back to the device the connection arrived from, independently of its routing table. On F5 BIG-IP this feature is called Auto Last Hop; other vendors provide equivalent functionality under different names.

With this enabled, replies to connections that arrived via the EDGE are sent back to the EDGE, while all other traffic keeps following the default internet path. No policy-based routing on the LAN and no SNAT on the EDGE is required, and the service still sees the original client IP address.

This requires the load balancer to terminate the connection (or at least to see both directions of it). The reply is sent to the layer 2 source of the incoming traffic, so it reaches the EDGE directly only if the EDGE is the last hop in front of the load balancer. A device in between, such as a dedicated firewall, works as well, as long as that device returns the traffic to the EDGE in turn - either because it forwards established sessions back the way they came, or because that segment has no competing internet path.

Testing and validation​

Verify the tunnel is established​

note

This check can be performed by the operator of the EDGE appliance.

After completing the EDGE and LAN configuration, verify that the EDGE has established a tunnel to the GATE and is exchanging prefixes correctly.

Check that the EDGE announces the service prefix to the GATE:

appliance-cli get debug/scion-tunneling/sgrp/local/announce

Check that prefixes from the GATE providers are being received by the EDGE:

appliance-cli get debug/scion-tunneling/sgrp/remote/receive
note

Refer to the IP-in-SCION tunneling troubleshooting tips if the tunnel is not established or prefixes are not exchanged as expected.

Assign a DNS record​

To make the service accessible to residential users by hostname, create a DNS record pointing to the GATE-assigned service IP address. The choice of DNS name depends on how the service should be reachable:

  • New hostname exclusively via GATE — Create an A/AAAA record for the new hostname directly resolving to the GATE-provided service IP. This is the simplest case.
  • Existing hostname, GATE as additional access path — Create a dedicated subdomain (e.g., scion.example.com) resolving to the GATE-provided IP, while the main domain continues to resolve to the public internet IP.
  • Same hostname replaces internet access — Replace the existing A/AAAA record with the GATE-provided IP. Consider DNS TTL and failover implications before doing this.

Test end-to-end connectivity​

note

This check should be performed by the customer of the GATE service, ideally from a residential user that is part of one of the ISPs in the GATE profile.

To verify that the full path from a residential user through the GATE to the service is working, perform a connectivity test from a client that is part of one of the ISPs in the GATE profile.

For a basic reachability check, use ping or curl from such a client:

ping <service-ip-prefix-first-address>

or

curl -v https://<service-hostname>/