Skip to main content

GRE tunnel setup

Replace every placeholder with values Templass provisions. Use the values Templass provisions, not example placeholders.

If you have not chosen a path yet, read Connectivity overview first.

Before you start

You need:

  • An active Templass service, or written confirmation that GRE is being issued
  • A public IPv4 address on your side that can terminate GRE (<YOUR_PUBLIC_GRE_IP>)
  • Permission to add a tunnel and a route on the origin device
  • The provisioned set below, from Panel or from Templass staff
PlaceholderMeaningWho fills it
<TEMPLASS_GRE_ENDPOINT>Templass outer GRE addressTemplass admin
<YOUR_PUBLIC_GRE_IP>Your outer GRE addressYou, then confirmed by Templass
<GRE_KEY>Optional GRE keyTemplass admin, if keys are used
<TUNNEL_INNER_TEMPLASS>Inner address on the Templass sideTemplass admin
<TUNNEL_INNER_YOU>Inner address on your sideTemplass admin, or agreed with you
<PROTECTED_PREFIX>Address or prefix users will hitTemplass admin

If any Templass field is missing, stop and ask in Discord or [email protected]. Guessing an endpoint will not work.

1. Give Templass your outer address

Send <YOUR_PUBLIC_GRE_IP> to the person handling your ticket, or enter it where Panel asks for it. Templass uses this as the tunnel destination.

The address must:

  • Be reachable from the internet
  • Allow GRE (IP protocol 47) from <TEMPLASS_GRE_ENDPOINT> once that value exists
  • Stay stable. A DHCP-changing WAN IP will drop the tunnel

2. Receive the Templass endpoint

When provisioning finishes you should have <TEMPLASS_GRE_ENDPOINT> and, if used, <GRE_KEY> plus inner addresses. Keep keys off chat logs that you do not control.

3. Allow GRE on the path

On any firewall in front of the terminator, permit:

  • IP protocol 47 (GRE) between <YOUR_PUBLIC_GRE_IP> and <TEMPLASS_GRE_ENDPOINT>
  • The inner prefix or point-to-point pair once it is assigned

Do not publish the protected service on <YOUR_PUBLIC_GRE_IP> if that address is only the tunnel endpoint.

4. Build the tunnel (Linux example)

This is a typical ip tunnel shape. Interface names and VRFs are yours.

# Outer tunnel. Add "key <GRE_KEY>" only when Templass issued a key.
sudo ip tunnel add gre-templass mode gre \
remote <TEMPLASS_GRE_ENDPOINT> \
local <YOUR_PUBLIC_GRE_IP> \
ttl 64

sudo ip link set gre-templass up
sudo ip addr add <TUNNEL_INNER_YOU>/30 dev gre-templass

Point the protected prefix at the tunnel, not at your WAN default route:

sudo ip route add <PROTECTED_PREFIX> dev gre-templass

The exact route direction depends on whether you are receiving destination traffic for <PROTECTED_PREFIX> or sending return traffic toward Templass. Follow the pairing Templass gave you. See Routing expectations.

5. Vendor devices

On a hardware router or firewall, create a GRE interface with:

  • Tunnel destination: <TEMPLASS_GRE_ENDPOINT>
  • Tunnel source: <YOUR_PUBLIC_GRE_IP>
  • Key: <GRE_KEY> only if issued
  • Inner IPs: the /30 or /31 Templass documented

Do not enable extra GRE features (checksum-only quirks, unexpected keepalive protocols) unless Templass asked for them. Keep MTU conservative. Start with 1476 on the tunnel if you see fragmentation, then adjust with Templass.

6. Prove the path before cutover

  1. Confirm the tunnel interface is up on both ends (Templass can confirm their side).
  2. Ping <TUNNEL_INNER_TEMPLASS> from <TUNNEL_INNER_YOU> if inner ICMP is allowed.
  3. Send a controlled probe to <PROTECTED_PREFIX> from a host that is not sitting on the origin.
  4. Confirm the packet arrives clean on your service, not on the old public binding.

If the tunnel is up but application traffic is not, the usual causes are a missing return route, an origin still listening on a bypass IP, or a firewall still blocking the inner pair.

7. Cut over

Change DNS, announcements, or frontend records to <PROTECTED_PREFIX> only after the probe succeeds. Keep a rollback: the previous origin IP and the tunnel config.

When something is still blank

Provisioning is not instant. Panel may show the service before GRE values exist. That is an access/admin step, not a broken tunnel. Details: Access and Panel unlock.