WARP causing problems in Netcat/Python

Hi everyone,

I have a port forwarded to my computer. I also have a remote virtual machine behind a NAT. I’ve noticed weird results when Cloudflare WARP is turned on:

Online port checkers indicate that the port is closed
When I run an online port checker with Netcat listening for TCP connections on the other end, the port checker fails to detect a port, and Netcat fails to establish a connection.


nc -l -p <port> -vv

Remotes machine cannot establish a TCP connection with my machine via Netcat
Whenever I try to establish a TCP connection from the remote machine to my machine, Netcat does not output anything (unable to establish a connection).


My machine: nc -l -p <port> -vv
Remote machine: nc <my-public-ip> <port> -vv

But when WARP is turned off, Netcat prints the expected output on my machine:

listening on [any] 2595 …
connect to [] from ec2-44-195-32-251.compute-1.amazonaws.com [] 44608
sent 0, rcvd 0

UDP packets can be sent from the remote machine but not sent from my machine
UDP packets can get through from the remote machine when WARP is on.


My machine: nc -l -p <port> -vv -u
Remote machine: nc <my-public-ip> <port> -vv -u

However, UDP packets cannot get through from my machine when WARP is on.


First send a message from the remote machine (for UDP hole punching):
nc <my-public-ip> <port> -vv -u -p <remote-port>
Remote machine: nc -l -p <remote-port> -vv -u.
My machine: nc <remote-ip> <remote-port> -vv -u -p <port>

So it appears that WARP is preventing TCP connections, as well as outbound UDP packets. The behaviour is also replicated when using Python sockets.

What is causing this issue, and how can it be fixed? I thought that it may have something to do with TCP packets being forwarded through a WARP server, but I read that WARP does not change the source IP of packets, but puts another layer over the original packet until the WARP endpoint, where the original packet is sent to its destination (which should look exactly the same as a normal packet?).


Search for Python.

I assume that is the issue but coming at it sideways

Thanks, I’m using raw UDP/TCP connections (no TLS/SSL/HTTPS) so I’m not sure it is a certificate issue as there is no certificate authentication being done (unless I’m missing something?).

I noticed that some “What’s my IP” websites (eg: Google Search infobox on the search page) returns WARP’s IP instead of my public IP. I’m not sure how this is happening, but if the remote machine is somehow seeing WARP’s IP as the source instead of mine, that would explain why UDP hole punching isn’t working.

Warp is a proxy for your traffic, it egresses from Cloudflare’s edge network. So the IP seen will be a Cloudflare one in most instances.


Thanks, that probably accounts for the behaviour above. I guess it is rare that a server would be behind a NAT anyways, but it may affect P2P in some cases.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.