I have a wonderful ISP blocking all UDP traffic (except DNS to its own DNS servers).

However, I want to use UDP for my VPN solution. I have root over both VPN endpoints, and both of them are using Linux.

My idea is to simply overwrite the packet type field in my outgoing UDP packets to look as TCP, and doing the reverse on the server side.

Thus, the routers/firewall of my wonderful ISP will see bad TCP packets, while my VPN processes will be able to communicate on UDP.

I strongly suspect, that the firewall of the ISP is not smart enough to detect that something is not okay.

Of course it would be a dirty trick, but not more dirty than simply forbidding the second most used IP protocol and selling this as ordinary internet connection.

As far I know, there are some iptables rules for that, but which one?

  • Have you tried contacting your ISP about them blocking UDP?
    – Torin
    Commented Feb 27, 2019 at 12:25
  • @Torin Chanceless. ("Your call is very important for us. Please wait until our customer specialist...blahblah") It is a Big Company. If I could access this customer specialist, he wouldn't understand my problem. Then he would sent me to some level-0 support who will want me to plug in/plug out my cable, reboot my router, reboot my windows..................
    – peterh
    Commented Feb 27, 2019 at 12:27
  • You'll probably need something better than iptables rules, as you'll need to fool all the middleboxes on the way which will track the TCP connection, so it least it should look like a proper TCP connection, even if there are no retransmission semantics. Have a look at raw sockets (man 7 raw), and be prepared to add a bit of source code to your VPN software.
    – dirkt
    Commented Feb 27, 2019 at 14:00
  • technically nftables can mangle "ip protocol udp" into "ip protocol 6". but you get what you asked then: except for the ports no information is the same. the checksum which isn't at the same place is now wrong, and if corrected (which might happen automatically) will overwrite some data, etc. couldn't get it to be accepted on the other side of the same wire after the reverse operation
    – A.B
    Commented Feb 28, 2019 at 18:21

2 Answers 2


I doubt iptables alone will be enough, as TCP and UDP are fundamentally different protocols.

You can forget setting up an IPsec VPN with such scenario (ISP blocking all UDP ports).

Tunnel all the traffic via ICMP. (best old school solution I know of. Lots of organizations still do not filter out any kind of ICMP) see https://github.com/DhavalKapil/icmptunnel

'icmptunnel' works by encapsulating your IP traffic in ICMP echo packets and sending them to your own proxy server. The proxy server decapsulates the packet and forwards the IP traffic. The incoming IP packets which are destined for the client are again encapsulated in ICMP reply packets and sent back to the client. The IP traffic is sent in the 'data' field of ICMP packets.

RFC 792, which is IETF's rules governing ICMP packets, allows for an arbitrary data length for any type 0 (echo reply) or 8 (echo message) ICMP packets.

So basically the client machine uses only the ICMP protocol to communicate with the proxy server. Applications running on the client machine are oblivious to this fact and work seamlessly.

also, as A.B. points out, you have a UDP-to-raw tunneling software at https://github.com/wangyu-/udp2raw-tunnel

Or in alternative, setup an OpenVPN solution. If you manage to talk outside run OpenVPN over port 53/UDP, or on the lack of that, run it over TCP. Mind you that doing a VPN over TCP will be slower than UDP, but it works.

As for the actual question of changing an IP field: You want to look at the mangle table in iptables, however:

  1. I suspect your ISP is blocking that too
  2. I know mangle supports modifying some IP fields, not sure about the one you need. See https://serverfault.com/questions/467756/what-is-the-mangle-table-in-iptables

More alternatives, you can try GRE tunnels (protocol 47), see https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.tunnel.gre.html ( it is easier than trying to develop an application ). Some organizations block this. Basically it is encapsulating IP/ICMP/UDP over protocol 47.

Or if nothing else works, you can tunnel it via an IP tunnel over SSH (mind you tun over SSH, not TCP port tunneling). see Ip Tunnel Over Ssh With Tun http://www.marcfargas.com/posts/ip-tunnel-over-ssh-with-tun/ By the way, no technology of smart/adaptative/deep inspection traffic shapper/firewall that will detect and block all the methods on this thread will be able to block a TUN over SSH.

PS. It is hard to believe an ISP blocking UDP, and furthermore, NTP and DNS UDP ports.

  • I use openvpn. I've already tested UDP port 53, the packets don't arrive. I suspect, an intermediary DNS proxy could be in the background. I did not very deeply tested, exactly which UDP ports are allowed.
    – peterh
    Commented Feb 27, 2019 at 13:31
  • OpenVPN run over TCP too, albeit slower. Commented Feb 27, 2019 at 13:32
  • 1
    Yes, I use OpenVPN over TCP (I think it is not important to answer the question). I want to use OpenVPN over UDP due to better performance.
    – peterh
    Commented Feb 27, 2019 at 13:35
  • 3
    github.com/wangyu-/udp2raw-tunnel : uses so-called FakeTCP mode for its tunnel to bypass firewalls. Simulates TCP without getting the tcp-over-tcp penality.
    – A.B
    Commented Feb 27, 2019 at 23:23
  • 1
    @A.B The wangyu idea looks very good!
    – peterh
    Commented Dec 9, 2020 at 22:58

This will popably not work. The Firewall surely will track the TCP setup packets (SYN,SYN-ACK,ACK) needed for a correct TCP Connection, which are missing if you just use altered UDP Packets.

What you could do is: Write a small Application which picks up UDP on the one side, connects to the other side via TCP, and another application which accepts the incoming TCP Connection and Forwards TCP traffic to UDP.

  • It could work, but I could change the VPN to use TCP with a single-line change in the vpn configuration. The problem is that exactly this is what I want to avoid - sending TCP packets over the (encrypted) TCP VPN connection triples the tcp handshake time, and this is exactly what I want to avoid.
    – peterh
    Commented Feb 27, 2019 at 12:33
  • Are you sure that it would track?
    – peterh
    Commented Feb 27, 2019 at 12:34
  • Well, i am not sure that it does, but it is very likely. You don't Need the vpn, just run a daemon here and there, connecting to each other. Do you Need multiple UDP Ports ? If not, just use the existing Connection to "tunnel" the udp data.
    – gerhard d.
    Commented Feb 27, 2019 at 14:09
  • The goal of using UDP is exactly to spare the TCP handshake and ACKs. Using a TCP VPN could work, but it would be slow. I want to make it quick.
    – peterh
    Commented Feb 27, 2019 at 14:16
  • @peterh You mean you need to optimize the initial TCP handshake of the VPN connection (latency of bringing up the VPN tunnel)? Because that's the only point where the extra TCP handshake matters. Tunneled TCP handshakes work just the same inside TCP or UDP tunnels. The performance disadvantages of tunneling in TCP are in congestion avoidance, retransmission, and a bit of extra bandwidth consumption.
    – TooTea
    Commented Feb 27, 2019 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .