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.

warning

Depending on the profile, the GATE can announce a large number of prefixes to the EDGE. In case the EDGE is connected to the customer LAN using BGP, ensure that you filter or deprioritize IP prefixes for which traffic should not be routed via the EDGE as they might be part of what the GATE announces.

LAN integration and service configuration​

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 ways 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.

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.

note

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.

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

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>/