Running a Trojan VPN server gives you a powerful, TLS-based proxy that can blend into normal HTTPS traffic. However, misconfigured network access or overly permissive firewall rules can instantly turn that advantage into a liability. This article outlines concrete, practical firewall rules, port setup recommendations, and hardening steps to make your Trojan server resilient against network attacks, lateral movement, and reconnaissance — aimed at site administrators, DevOps engineers, and security-conscious developers.

Understand the Trojan network model and the threat surface

Before applying rules, you must understand how Trojan works and what needs protection. Trojan implements a TLS-based proxy that usually listens on a TCP port (commonly port 443 to blend with HTTPS), terminates TLS, and forwards traffic to backend services or creates outbound connections on behalf of clients. Key elements you need to protect:

  • The listening socket: The port where Trojan accepts client TLS connections.
  • Certificates and private keys: TLS key material must be tightly protected.
  • Control plane: Admin interfaces, health endpoints, management APIs.
  • Network forwardings: NAT/forward rules to reach internal services or the internet.
  • Logging/monitoring endpoints: Syslog, metrics, or remote logging ports.

Design principles for firewall rules

Good firewall design follows a few simple principles:

  • Default deny: Block everything not explicitly allowed.
  • Least privilege: Only open the ports necessary for client traffic and operations.
  • Separation: Keep management and data plane ports distinct and restricted to trusted sources.
  • Defense in depth: Combine OS-level firewalls with cloud security groups and host-based protections like fail2ban and SELinux.
  • Logging and alerting: Log dropped/accepted packets, monitor for anomalous spikes.

Which ports does Trojan use?

Typical deployments use:

  • 443/tcp — Common default because it blends with HTTPS. Trojan expects TLS there.
  • 80/tcp — Often used for ACME HTTP-01 challenges to obtain TLS certificates; can be restricted to the certificate authority IPs or managed via a proxy.
  • Custom high ports — Some operators move Trojan to high ports (e.g., 8443, 8444) to avoid service collisions or for multiple instances.
  • Management ports — If you expose SSH (22/tcp) or an admin API, restrict by IP.

Concrete iptables examples for IPv4

Below are practical iptables snippets to implement a secure baseline. Adapt interfaces (eth0) and addresses to your environment.

1) Flush and set default policies:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

2) Allow loopback and established traffic:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

3) Allow Trojan listening port (443) from anywhere, rate-limit new connections to mitigate scans:

iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -m recent --set --name trojan
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 30 --name trojan -j DROP
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

4) Allow ACME HTTP challenge only when required — restrict to port 80 and optionally to CA IPs (example for Let’s Encrypt IP ranges requires updating):

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

5) Restrict SSH to admin IPs:

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

6) Log dropped inbound packets (rate-limited):

iptables -N LOGGING
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A INPUT -j LOGGING

nftables modern alternative

For newer systems, nftables is preferred. Example ruleset (conceptual):

table inet filter {
chain input {
type filter hook input priority 0;
policy drop;
iif lo accept
ct state established,related accept
tcp dport 443 ct state new limit rate 30/second accept
tcp dport {80,443} accept
ip saddr 203.0.113.10 tcp dport 22 accept
tcp dport 22 drop
log prefix "nft-drop: " limit rate 5/second
}
}

nftables can combine IP sets and more advanced matching (see ipset below).

FirewallD (firewalld) and UFW examples

If you use distribution firewalls:

  • For firewalld: use zones. Place the server in the public zone but add services/ports selectively and put SSH into a restricted zone bound to an interface or source IP.
  • For UFW:

ufw default deny incoming
ufw default allow outgoing
ufw allow 443/tcp
ufw allow proto tcp from 203.0.113.10 to any port 22
ufw allow 80/tcp # if required for ACME

Protect TLS keys and enforce TLS hardening

Fortifying firewall rules is necessary but not sufficient. TLS key compromise will break everything. Key hardening steps:

  • Run Trojan as a dedicated unprivileged user and set strict file permissions: chmod 640 /etc/ssl/private/trojan.key, owner root:tproxyuser.
  • Bind Trojan to a non-root port only if using capabilities (CAP_NET_BIND_SERVICE) or run via systemd with AmbientCapabilities to allow binding to port 443 without full root.
  • Enforce TLS modern cipher suites and TLS 1.2/1.3 only. Disable TLS 1.0/1.1.
  • Use OCSP stapling and HSTS where applicable to reduce certificate validation attacks.

Network-level protections and kernel tuning

Harden the kernel and netfilter to mitigate scanning and DDoS:

  • Enable SYN cookies: sysctl -w net.ipv4.tcp_syncookies=1
  • Tune connection tracking timeouts if NATing many endpoints: /proc/sys/net/netfilter/nf_conntrack_max
  • Rate-limit ICMP to avoid ping floods and maintain necessary diagnostics: iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
  • Disable source routed packets: sysctl -w net.ipv4.conf.all.accept_source_route=0

Use ipset for large blocklists and dynamic block rules

If you need to block or allow many IPs (threat feeds, geo-blocking), use ipset to avoid long iptables chains and improve performance:

ipset create blocked hash:net family inet
ipset add blocked 198.51.100.0/24
iptables -I INPUT -m set --match-set blocked src -j DROP

Update ipset dynamically from cron or a management script for automated blocking of malicious ranges.

Logging, alerting and intrusion prevention

Visibility matters. Implement the following:

  • Centralize logs to a remote syslog/ELK stack and watch for peaks in TCP resets or failed TLS handshakes.
  • Deploy fail2ban to watch logs for repeated failed TLS handshakes or authentication failures and add temporary iptables bans.
  • Use an NIDS or flow analysis (Zeek, Suricata) to detect abnormal traffic patterns that a simple firewall won’t catch.

Protect management interfaces and apply deployment best practices

Keep admin paths isolated:

  • Bind admin/monitoring endpoints to the loopback interface or an internal management network only. If remote access is needed, require SSH tunnel or VPN that is separate from the Trojan data plane.
  • Use multi-factor auth and IP whitelisting for SSH and control plane access.
  • Harden systemd units for Trojan: use PrivateTmp, NoNewPrivileges, RestrictAddressFamilies, and restrict filesystem access via ReadOnlyPaths/ProtectSystem where possible.

Example systemd service snippet

[Service] User=trojan
Group=trojan
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
ProtectSystem=full
PrivateTmp=true
ProtectHome=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

Testing and audits

After applying rules, always perform validation:

  • Use nmap from an external host to confirm only intended ports are open: nmap -sS -Pn -p 1-65535 your.server.ip.
  • Run TLS scanners (sslyze, testssl.sh) to verify cipher suites and TLS versions are acceptable.
  • Audit logs for denied connection attempts and tune rate limits to avoid false positives for legitimate users.

IPv6 considerations

If your server has IPv6, apply equivalent rules for ip6tables/nftables. Many operators forget IPv6 and accidentally leave services exposed. Close the same ports on IPv6 and ensure ipset entries include IPv6 families where supported.

Summary checklist

  • Default deny inbound, allow only Trojan listening ports and required management IPs.
  • Rate-limit new TCP connections and use SYN cookies.
  • Protect TLS keys and enforce strong TLS configuration.
  • Separate management plane and bind it to internal interfaces.
  • Use ipset for large blocklists and nftables for modern performance.
  • Log, monitor, and automate temporary bans with fail2ban or similar tools.
  • Test from both IPv4 and IPv6 and audit your rules regularly.

Implementing the firewall posture above will significantly reduce the attack surface of your Trojan VPN server while preserving legitimate client connectivity. For operational deployments, combine cloud security group restrictions with host-based firewalls and system hardening to achieve true defense in depth.

For further guides and configuration examples, visit Dedicated-IP-VPN: https://dedicated-ip-vpn.com/