Tunnel IP quickstart

1. What you get
2. The WireGuard configuration
3. Bring it up and check it
4. Using a /29 or /28
5. Firewall the inbound side
6. Port 25
7. Reverse DNS

What you get

A tunnel is a routed IPv4 prefix: one address (/32), 8 addresses (/29) or 16 addresses (/28), in France (GRA) or Germany (LIM), as you chose when you ordered. The prefix is routed to your WireGuard peer. You decide which host, VM or container uses each address.

We send you a WireGuard configuration with your private key, our public key, the endpoint and the addresses. Like the proxy password, the private key is shown once. We keep only the public half, so we cannot show it again. If you lose it, ask us to rotate the key: the old tunnel stops working and you get a new configuration. See Security notes.

The examples use addresses from documentation ranges. 198.51.100.9 stands for one of your public addresses and 198.51.100.8/29 for a block.

The WireGuard configuration

Install WireGuard (on Debian or Ubuntu: sudo apt-get install wireguard-tools) and save the configuration as /etc/wireguard/penduses.conf, readable by root only (sudo chmod 600). The file name is the interface name.

Option A: send all traffic through the tunnel

Best for a router, a gateway or a machine that exists to use the addresses.

[Interface]
PrivateKey = <your-private-key>
# One of your routed public addresses, on the host itself
Address = 198.51.100.9/32

[Peer]
PublicKey = <penduses-public-key>
Endpoint = <endpoint-from-your-welcome-email>:51820
# Send all IPv4 traffic through the tunnel
AllowedIPs = 0.0.0.0/0
# Keeps the tunnel open behind CGNAT or a firewall
PersistentKeepalive = 25

This changes the default route of the host. If you administer the host over its normal address, replies to that connection can end up in the tunnel and the session hangs. Keep console access for the first run, or use option B.

Option B: only traffic from your public address uses the tunnel

Best for a server that keeps its normal address for administration, updates and everything else. Table = off stops WireGuard from touching the default route, and a routing rule sends only traffic whose source is your public address (or block) into the tunnel.

[Interface]
PrivateKey = <your-private-key>
Address = 198.51.100.9/32
Table = off
# Replace 198.51.100.8/29 with your address or block
PostUp = ip route add default dev %i table 51821; ip rule add from 198.51.100.8/29 lookup 51821
PostDown = ip rule del from 198.51.100.8/29 lookup 51821; ip route del default dev %i table 51821

[Peer]
PublicKey = <penduses-public-key>
Endpoint = <endpoint-from-your-welcome-email>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

With B, a connection that the host starts itself uses its normal address unless the program binds your public one, for example curl --interface 198.51.100.9. Services that listen on the public address answer from it, and the answers go through the tunnel.

Bring it up and check it

sudo wg-quick up penduses

# A recent handshake means the tunnel works
sudo wg show penduses

# The address the other side sees (option A; with option B add --interface 198.51.100.9)
curl -sS https://ip-echo.example.com/
# prints 198.51.100.9

# Start it at boot
sudo systemctl enable wg-quick@penduses

No handshake, or a tunnel that comes up but passes no traffic: see Troubleshooting. To take the tunnel down, run sudo wg-quick down penduses.

Using a /29 or /28

Give the host one address of the block (as in the examples) and use the others on VMs, containers or other machines behind it. The host forwards between them and the tunnel.

# Forward between your VMs and the tunnel
sudo sysctl -w net.ipv4.ip_forward=1

# Your VMs sit on the bridge br0. Route the block there.
sudo ip route add 198.51.100.8/29 dev br0

Give each VM one address of the block, and set its default gateway to the host's address on that bridge. Do not use NAT: the public addresses are the VMs' real addresses. The exact bridge setup depends on your hypervisor. Make the change permanent in your network configuration, and make sure the firewall below covers the forwarded traffic.

Firewall the inbound side

As soon as the tunnel is up, your addresses are reachable from the whole internet. Whatever listens on them is exposed, and scans start within minutes. Do not rely on us to filter inbound traffic: firewall the host yourself, and do it before you bring the tunnel up.

This example drops everything that arrives from the tunnel except replies, limited ping, and the web ports of one host. Adapt the ports and the address to what you serve.

table inet penduses_tunnel {
  chain input {
    type filter hook input priority 0; policy accept;
    iifname "penduses" ct state established,related accept
    iifname "penduses" ip protocol icmp icmp type echo-request limit rate 5/second accept
    # The ports this host serves on its public address
    iifname "penduses" tcp dport { 80, 443 } accept
    iifname "penduses" drop
  }
  chain forward {
    type filter hook forward priority 0; policy accept;
    iifname "penduses" ct state established,related accept
    # A web server on a VM: 198.51.100.10
    iifname "penduses" ip daddr 198.51.100.10 tcp dport { 80, 443 } accept
    iifname "penduses" drop
  }
}

• Load it with sudo nft -f on the file, and include it from your boot-time nftables configuration.
• Do not put SSH, databases or admin panels on a public address unless you have to. If you must, use keys only, restrict the source addresses, and keep the software updated.
• You are responsible for what runs on your addresses and what leaves them. The acceptable use policy applies.

Port 25

Outbound port 25 (SMTP) is closed by default on every tunnel, to keep our address space in good standing. If you run a mail server, tell us what you plan to send and from which host name. We check the request against the acceptable use policy and, if it passes, open outbound port 25 for the addresses you name. Before you ask, prepare:

• reverse DNS for the sending address (see below) that matches the host name your server introduces itself with;
• SPF, DKIM and DMARC records for the domains you send from;
• a working abuse@ and postmaster@ mailbox on those domains.

Opening the port is no promise that other mail servers will accept your mail: they decide that for themselves. Static egress addresses cannot send mail on port 25 at all.

Reverse DNS

On request. Send us the host name you want for each address. It must resolve forward to the same address, and we set the reverse record once it does.

The pilot is best effort with no SLA. Questions: support@penduses.com.