PortShield
by Valtrix

Today, an increasing number of organisations are subject to Layer 3 and Layer 4 (L3/L4) DDoS attacks targeting their internet-facing infrastructure. It is not just web servers under attack. Game servers, SSH and RDP access points, VPN concentrators, file transfer services, IoT endpoints, and any other application that communicates over TCP or UDP has become a frequent target for volumetric floods, reflection attacks, and protocol exploitation.

Traditional network-level DDoS scrubbing protects IP prefixes but offers no per-application control, no origin masking, and no service-aware filtering. Web application firewalls (WAFs) and CDNs protect HTTP traffic but cannot proxy arbitrary protocols. The gap between those two approaches is exactly where PortShield operates.

PortShield by Valtrix is a reverse proxy service that provides DDoS protection for any application running over TCP or UDP. Services such as game servers, SSH, RDP, VPN, MQTT, FTP, VoIP, custom trading protocols, and IoT telemetry can all use PortShield to mask the origin server, protect it from L3/L4 DDoS attacks, and add per-port access controls without modifying the application itself.

The attack surface problem

When a server's IP address is publicly reachable, it is permanently exposed to reconnaissance and attack. Attackers scan the entire IPv4 space in under an hour using widely available tools. Once your origin IP is known, it can be targeted directly, bypassing any upstream protections you have in place. Rate limits, cloud provider DDoS scrubbing, and upstream ISP filtering all operate at the IP level. None of them hide your origin.

PortShield solves this by moving the publicly reachable address to an edge node. Your clients connect to the edge, not to your server. Your server's IP is never advertised in DNS, never appears in connection logs on the client side, and can be completely locked down at the network level to only accept traffic from PortShield edge node IPs. Attackers have no origin to target directly.

What PortShield is not

PortShield is not a web application firewall and it is not a CDN. It does not cache content, does not terminate TLS, does not parse HTTP headers, and does not inspect application-layer payloads. It operates purely at Layer 4, which means it is compatible with encrypted protocols, proprietary binary protocols, and any application that does not use HTTP. The trade-off is that PortShield cannot block application-layer attacks such as HTTP floods or SQL injection. For those threats, a WAF should be layered in front of the application separately.

Key capabilities

• Reverse proxy for any TCP or UDP application with origin IP masking
• L3/L4 DDoS absorption up to 1 Tbps per edge region
• Dual-tier mitigation: centralized detection plus autonomous edge-local filtering
• Per-port IP firewall with CIDR-based allowlists and blocklists enforced at the edge
• Service-specific filtering profiles with protocol-aware heuristics
• Configurable per-port rate limiting (PPS and Mbps caps)
• Subnet-level batch protection: cover an entire /24 IP block in a single operation
• Per-account Prometheus metrics endpoint for Grafana and alerting integration
• Full REST API for automation, CI/CD pipelines, and infrastructure-as-code workflows
• Zero-downtime rule propagation to all edge nodes in real time

When a request to a TCP or UDP application arrives, it first hits the closest PortShield edge node. The edge node checks the source IP against the port's firewall rules, validates the traffic against the configured service profile, applies any rate limits, and then proxies clean connections to the origin server over a direct tunnel. The full connection state is maintained on the edge node so the application on the origin side sees a normal TCP or UDP connection.

End-to-end traffic path

# 1. Client's DNS resolves the protected hostname to the edge node
ssh.example.com  IN  CNAME  prt-02-oc-d1.valtrix.one
prt-02-oc-d1.valtrix.one  IN  A  206.206.77.180

# 2. Client connects to the edge port
Client (internet)  --TCP SYN-->  206.206.77.180:14200

# 3. Edge node processes the connection
Edge Node (prt-02-oc-d1.valtrix.one)
  Step 1: Match source IP against ACL rules
          - If allowlist is configured: drop if source is not allowed
          - If blocklist is configured: drop if source is explicitly blocked
  Step 2: Validate against service profile (e.g. SSH SYN-flood heuristics)
  Step 3: Check rate limits (PPS cap, Mbps cap)
  Step 4: Open proxied connection to origin

# 4. Clean traffic reaches your server
Edge Node  --TCP-->  203.0.113.5:22  (your origin, hidden from internet)

Platform components

PortShield has two main components that work together:

Edge network regions

When you create a protected port, the panel assigns it to the tunnel region you selected and returns an edge port number and a CNAME hostname. That hostname resolves to the edge node's IP. Your clients connect to the hostname and edge port. The edge port is permanent for the lifetime of the rule.

PortShield uses a dual-tier mitigation architecture. Attacks are handled at both the edge node level and the network level, so that large volumetric floods are absorbed before they reach the proxy layer and sophisticated protocol-exploitation attacks are caught by service-aware heuristics running on the edge agents themselves.

Attack types handled

What happens to your traffic during an attack

When a volumetric attack hits a protected port, the edge node's carrier-level scrubbing absorbs the flood. Legitimate connections from allowed source IPs continue to be proxied normally on the same edge port during the attack. There is no failover, no port change, and no client-visible disruption as long as the attack volume stays within the region's rated capacity.

For protocol-level attacks, the edge agent drops malformed or flagged packets per the active service profile while continuing to forward clean connections. The attack log in the panel records each mitigated attack event with timestamps, peak throughput, estimated source IP count, and attack type classification.

Cloudflare Spectrum is the most widely recognised TCP/UDP application proxy service. PortShield by Valtrix operates in the same product category: both are reverse proxies that handle any TCP or UDP application, mask origin IPs, and provide L3/L4 DDoS protection. Neither service requires the protected application to speak HTTP.

The table below covers the major feature differences. PortShield includes several capabilities that Spectrum does not offer in its standard tier, including per-port IP firewall rules, a private Prometheus metrics endpoint, and subnet-level batch provisioning. Cloudflare's advantage is global reach across 300+ data centres, which PortShield does not currently match at the same scale.

PortShield includes a completely software-defined IP firewall that is configured per protected port, directly from the dashboard or the API. You can allow or deny individual IP addresses or CIDR ranges to control which sources can reach your application through the proxy. Rules are enforced on the edge agent before any traffic is forwarded to your origin, so blocked connections never consume origin server resources.

Operating modes

The firewall operates in one of two modes depending on which rule types are present:

CIDR notation

Example: restrict an SSH endpoint to known sources

# Adding at least one allow rule activates allowlist mode.
# All other internet traffic is dropped at the edge.

allow  192.168.10.0/24   # Office internal network
allow  10.8.0.0/16        # VPN client pool
allow  203.0.114.5        # Individual admin workstation

# Result: only these three CIDR ranges can connect through the edge.
# An attacker who knows the edge port gets a silently dropped connection.

Adding rules via the API

curl -b cookies.txt -X POST https://portshield.valtrix.one/api/ports/pp-abc/acl \
  -H "Content-Type: application/json" \
  -d '{
    "cidr":   "192.168.10.0/24",
    "action": "allow",
    "note":   "Office network"
  }'

PortShield exposes a private Prometheus-compatible metrics endpoint for each account. The endpoint returns traffic counters, connection counts, and port status data scoped exclusively to the authenticated account's ports. No other user can access your metrics endpoint, and you cannot access another account's endpoint. The API key embedded in the URL is unique per account and cannot be reused across accounts.

Point any Grafana instance at your endpoint URL to build real-time dashboards. A pre-built dashboard JSON is available for download from the Grafana Metrics page in the panel. It includes panels for bandwidth per port, active connection counts, total traffic aggregates, and a protected ports status overview.

Available metrics

All metrics carry labels: port_id, label, protocol, tunnel, origin.

Setting up Grafana in four steps

Useful PromQL queries

rate(valtrix_bytes_in_total[2m]) * 8

sum(rate(valtrix_bytes_in_total[2m]) + rate(valtrix_bytes_out_total[2m])) * 8

valtrix_active_connections > 0

valtrix_port_status == 0

The subnet /24 batch feature creates one protection rule for every IP address in a given /24 CIDR block. All 256 rules share the same port number, protocol, service profile, and tunnel region, and each rule receives its own unique edge port. The operation runs as a single API call or panel form submission.

When batch mode is justified

• A hosting provider that has allocated a dedicated /24 to game nodes where every node exposes the same UDP port
• An operations team running a dense server cluster where all machines in the /24 have the same management port open to the internet and all nodes are active
• An anycast or load-balanced cluster where every IP in the block serves the same application on the same port simultaneously

How batch provisioning works

# Input
Subnet CIDR:  10.20.0.0/24
Origin Port:  22
Protocol:     TCP
Service Type: ssh-sftp
Label Prefix: SSH Cluster

# Result: 256 rules created, each with its own edge port
SSH Cluster (10.20.0.0)    -> :14300
SSH Cluster (10.20.0.1)    -> :14301
SSH Cluster (10.20.0.2)    -> :14302
# ...
SSH Cluster (10.20.0.255)  -> :14555

API call

curl -b cookies.txt -X POST https://portshield.valtrix.one/api/ports/batch \
  -H "Content-Type: application/json" \
  -d '{
    "mode":        "subnet",
    "cidr":        "10.20.0.0/24",
    "tunnelId":    "t-as-1",
    "originPort":  22,
    "protocol":    "TCP",
    "serviceType": "ssh-sftp",
    "label":       "SSH Cluster"
  }'

PortShield supports configurable per-port rate limiting for both TCP and UDP traffic. Rate limits are enforced at the edge agent and operate independently of the service profile. You can set a packets-per-second (PPS) cap, a throughput cap in megabits per second (Mbps), or both. Traffic that exceeds either threshold is dropped silently at the edge before it reaches your origin.

Rate limiting is useful when you want to cap resource consumption for a specific port regardless of attack conditions, protect a shared host from one tenant consuming all available capacity, or enforce a contractual bandwidth limit per client.

Configuring rate limits

Select rate-limit-tcp or rate-limit-udp as the service type when creating or editing a protected port. Two additional fields appear:

Protocol:     UDP
Service Type: rate-limit-udp
PPS Limit:    50000   # packets/sec; 0 to disable
BPS Limit:    100     # megabits/sec; 0 to disable

# Effect: any burst above 100 Mbps or 50,000 pps is dropped.
# Legitimate traffic below the threshold passes through unmodified.

Each protected port is assigned a service profile that tells the edge agent which application-level heuristics to apply when processing traffic. Selecting the correct profile significantly improves mitigation accuracy. A generic TCP pass-through profile will forward all SYN packets regardless of rate; an SSH-specific profile will apply connection rate limiting and SYN flood detection tuned for SSH connection patterns.

Protocol selection

Available service profiles

Profiles are grouped by category. Choose the most specific profile available for your application. The more specific the profile, the more accurate the attack detection.

Pass-through and rate limiting

Infrastructure and management access

Web

VPN and tunneling

Game servers

Additional game profiles are available in the panel. Contact support if your specific game title is not listed.

Generic proxies

Every operation available in the panel is also available through the PortShield REST API. Use it to automate port provisioning during server deployments, integrate with internal ticketing and monitoring systems, or manage large numbers of protected ports through infrastructure-as-code tooling such as Terraform or Ansible.

Endpoint reference

Authentication

Protected Ports

IP Firewall

Domains and Logs

Full example: provision a port and add ACL rules

# Step 1: authenticate
curl -c cookies.txt -X POST https://portshield.valtrix.one/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"you@example.com","password":"yourpassword"}'

# Step 2: create the protected port
curl -b cookies.txt -X POST https://portshield.valtrix.one/api/ports \
  -H "Content-Type: application/json" \
  -d '{
    "originIp":    "203.0.113.5",
    "originPort":  22,
    "protocol":    "TCP",
    "serviceType": "ssh-sftp",
    "label":       "Primary SSH",
    "tunnelId":    "t-as-1"
  }'

# Response includes the edge port and CNAME target
# { "id":"pp-abc", "edgePort":14200, "cnameTarget":"prt-02-oc-d1.valtrix.one", ... }

# Step 3: restrict access to known IP ranges (activates allowlist mode)
curl -b cookies.txt -X POST https://portshield.valtrix.one/api/ports/pp-abc/acl \
  -H "Content-Type: application/json" \
  -d '{"cidr":"192.168.10.0/24","action":"allow","note":"Office"}'

curl -b cookies.txt -X POST https://portshield.valtrix.one/api/ports/pp-abc/acl \
  -H "Content-Type: application/json" \
  -d '{"cidr":"10.8.0.0/16","action":"allow","note":"VPN clients"}'

# Step 4: update DNS (in your DNS provider)
# ssh.example.com. 3600 IN CNAME prt-02-oc-d1.valtrix.one.

# Step 5: lock down your origin server firewall
# Only accept connections from the PortShield edge node IP on port 22

Selecting the correct protocol is important. Choosing TCP/UDP when only one is needed creates two proxy listeners per rule and wastes edge capacity. The following table covers the most common applications and the correct protocol selection for each.

After adding a protected port, the panel provides a CNAME target hostname. Clients must connect to this hostname (and the assigned edge port) instead of your origin server IP. You achieve this by adding a CNAME record in your DNS zone.

CNAME record (recommended)

# SSH management access
ssh.example.com.     3600  IN  CNAME  prt-02-oc-d1.valtrix.one.

# Game server
play.example.com.    300   IN  CNAME  sg-01-oc-d1.valtrix.one.

# VPN endpoint
vpn.example.com.     3600  IN  CNAME  eu-01-xx0d2-c1.valtrix.one.

# Multiple services behind the same edge node
rdp.example.com.     3600  IN  CNAME  prt-02-oc-d1.valtrix.one.
sftp.example.com.    3600  IN  CNAME  prt-02-oc-d1.valtrix.one.

Resolving to a static IP (testing only)

dig +short prt-02-oc-d1.valtrix.one
# 206.206.77.180

# Then connect directly to the IP (not recommended for production)
ssh user@206.206.77.180 -p 14200

Before and after

# Before: direct connection to origin (IP publicly reachable)
ssh admin@203.0.113.5 -p 22

# After: connection routed through PortShield edge
ssh admin@ssh.example.com -p 14200

# Your origin IP 203.0.113.5 is now invisible to clients and attackers.
# Lock your server firewall to only accept from the edge node IP.

PortShield is applied across a wide range of industries and application types. Below are representative scenarios illustrating how different operators configure and benefit from the service.

What PortShield inspects

PortShield operates at Layer 4 only. It inspects source and destination IP addresses, source and destination ports, TCP flags, packet sizes, and packet rates. It does not read, store, modify, or forward copies of application-layer payload content. For TCP connections, it maintains connection state (SYN, ESTABLISHED, FIN) without reading what data is transmitted inside the connection.

This means PortShield is compatible with end-to-end encrypted protocols. Whether your application uses TLS, WireGuard, SSH, or a custom proprietary encryption scheme, the payload remains opaque to the proxy. PortShield never terminates encryption and never holds decryption keys.

Data handling

• Port configurations, traffic counters, and attack event metadata are stored in a PostgreSQL database on the panel server
• Traffic counters record byte totals and connection counts per port, not payload samples
• Attack logs record timestamps, peak throughput, estimated source IP count, and attack type classification, not packet captures
• Session cookies are HTTP-only and cannot be read by client-side JavaScript
• Passwords are hashed and never stored in plaintext
• Prometheus API keys are derived via HMAC-SHA256, scoped to one account, and do not require a separate database column

Access control model

Panel and edge communication

All management traffic between your browser and the panel is encrypted with TLS 1.3. Edge nodes and the control panel communicate over an authenticated, encrypted control channel. Client traffic is strictly separated from control-plane communication. Protection rules remain fully active on edge nodes even if the panel is temporarily offline because agents operate independently after initial configuration.

Contacting support

Planned maintenance

Edge agent updates are deployed in a rolling fashion, one node at a time. Each node being updated drains existing connections over a 30-second graceful window before the process restarts. Traffic is not interrupted for clients connected to other nodes during a rolling update. Panel maintenance windows are announced at least 48 hours in advance by email. During a panel outage, all existing protection rules remain fully active on edge nodes because agents operate independently of the panel.

Traffic and billing

• Each plan includes a monthly traffic quota. Usage above the quota is billed at the per-GB overage rate shown in the tunnel selector.
• Attack traffic absorbed and dropped by the mitigation engine does not count toward your monthly quota. Only successfully forwarded clean traffic is metered.
• Payment is processed via Valtrix Account Code issued by our team. No credit card is required.
• Bank transfer and manual invoice are also accepted. Contact support to arrange.
• Custom contracts with dedicated bandwidth allocation, dedicated node capacity, or enhanced SLA terms are available. Contact support@valtrix.one.