Tips and best practices

VPC deployments

When setting up WARP Connector on a virtual private cloud (VPC), you may need to configure additional settings in the cloud service provider.

GCP

For Google Cloud Project (GCP) deployments, enable IP forwarding ↗ on the VM instance where you installed WARP Connector.

AWS

For Amazon Web Services (AWS) deployments:

• Stop source/destination checking ↗ on the EC2 instance where you installed WARP Connector.

• In your subnet route table ↗, route all IPv4 traffic to the EC2 instance where you installed WARP Connector. For example:

  Destination	Target
  0.0.0.0/0	eni-11223344556677889

Source IPs for Cloudflare services

When Cloudflare services such as Load Balancing send traffic to your private network through WARP Connector, the traffic originates from a configurable IP range (default 100.64.0.0/12). You may need to configure Cloudflare source IPs to avoid IP conflicts or align with your IP address management plan.

WARP Connector with cloudflared

WARP Connector and cloudflared can run together on the same Linux host. This configuration is useful when you want to use WARP Connector as a gateway for your private network, while also using the cloudflared daemon to expose specific applications.

By design, WARP Connector captures all outbound traffic and routes it through Cloudflare's network. This prevents cloudflared from making its own required outbound connections to Cloudflare, causing the tunnel to fail with connection timeouts.

To allow cloudflared to connect, use Split Tunnels to explicitly exclude the Cloudflare Tunnel destinations from the WARP tunnel. For example, if you are using Split Tunnels in Exclude mode, add the following hostnames (or their corresponding IP ranges) to your Split Tunnel exclusion list:

• region1.v2.argotunnel.com
• region2.v2.argotunnel.com

Note

Split Tunnels is the only supported method of running both connectors on one machine. Due to its low-level integration with the kernel networking stack, WARP Connector will override any routing configurations made by commands such as ip route add and iptables.

MTU, MSS, and packet fragmentation

To ensure reliable network performance, it is important to understand the requirements for Maximum Transmission Unit (MTU) ↗ and Maximum Segment Size (MSS) ↗ when using WARP Connector. An incorrect configuration can lead to performance degradation or packet loss.

WARP Connector uses encapsulation to route traffic, which adds extra headers and bytes to each packet ↗. This is especially critical for traffic from your private network (on-ramped via WARP Connector) to a remote WARP client. This traffic flow is encapsulated twice:

1. By the WARP Connector on your Linux host.
2. Again by Cloudflare before being delivered to the off-ramp.

This final encapsulation adds overhead. If a device on your private network sends a packet that is already near the maximum size (1,460 bytes or more), this final encapsulation will create a packet larger than 1,500 bytes, which will be dropped.

Generally, this does not cause issues for TCP traffic and modern applications that use Path MTU Discovery (PMTUD) ↗. When they send a large packet with the do not fragment (DF) bit set, the WARP Connector's Linux host will correctly send an ICMP Fragmentation Needed message back to the source device. The source device then learns to send smaller packets.

However, this may cause issues for legacy applications (like some video streaming or monitoring tools) that may not perform Path MTU Discovery (PMTUD). Instead, they send large packets (e.g., more than 1,280 bytes) with the do not fragment (DF) bit unset (DF=0).

In this situation, WARP Connector host receives this large packet (for example, 1,460 bytes), then fragments the packet to fit its tunnel MTU. These fragments are then reassembled at a Cloudflare data center back into the original 1,460-byte packet. Cloudflare then tries to encapsulate this 1,460-byte packet to send to the WARP client, pushing it over 1,500 bytes and causing it to be dropped. Cloudflare does not currently support fragmenting these outgoing encapsulated packets.

Recommendations

To ensure reliable connectivity for all traffic types, especially legacy UDP applications, the most effective solution is to configure the MTU on your source devices (such as servers, cameras, or other devices on your private network) to 1,280 bytes.

This ensures the original packet is small enough to be encapsulated and delivered without being fragmented or dropped.

For TCP-only applications, you can alternatively apply an MSS clamping ↗ on your router (an intermediary network device). A value of 1,240 bytes (1,280 bytes MTU - 20-byte IP header - 20-byte TCP header) is recommended to align with the WARP Connector's tunnel MTU.