8 ms·

For anybody that's tried both - how do these compare to DNS tunnels (e.g. iodine), in terms of speed and reliability?

vampire_dk 11y ago
I haven't tried comparing both. I don't have much resources. All I can say is that using icmptunnel, one couldn't differentiate whether it's using tunnel or direct internet. Hence ICMP tunneling was very fast. Although I'm interested in comparison as well :)
dogma1138 11y ago
DNS is less reliable, but could give you bigger throughput (you can send and request large records) ICMP packets would arrive quicker, will be more reliable will bypass various DNS hijackers (common with many ISP's) along the way. DNS also requires you to have a DNS server and a domain, and you'll need something to constantly clear the cache on the local machine otherwise you'll eventually run out of room even if you are going to use the max available DNS record size. If anything in the way will keep your DNS queries in cache then you might be screwed and run out of space very quickly. If you need internet access ICMP tunnel will be better, bandwidth will be limited but it will be more or less a P2P tunnel, if you need to exfiltrate data without explicitly needing to maintain a bi-directional tunnel DNS is the way to go, will also work in more captive portal restrictive cases than ICMP. Today ICMP is usually utterly blocked DNS sometimes work especially in common cases where the restricted network offers some white listed sites (e.g. airport wifi that allows you to access the airport's site and the local train service but blocks everything else).
- vampire_dk 11y ago
  With even ICMP you can send/receive large messages. There is no restriction on the maximum payload length.
  - dogma1138 11y ago
    I haven't seen a single network stack that doesn't limit the size of the tailing payload or packet in general (MTU's ;)), go try and push 65507 bytes of payload into the message and tell me how it goes. In any case DNS tunnel offers you both TCP and UDP tunneling at much higher throughput, I'll take a look at your code when I'll have the time and see how it compares to ptunnel or ICMP shell.
  - vampire_dk 11y ago
    Normally, an ethernet or wifi restricts an MTU of 1500. I use ping packets accordingly
    - dogma1138 11y ago
      1500 is the MTU of Ethernet, it's often not sustainable on end to end connection (especially when you add frame overheads) if you are using that high of a payload size you'll get considerably worse performance than say limiting it to around 500 bytes, you are welcomed to try it. Also with how global traffic is managed smaller packets tend to get priority since they can be qued quicker backbone connectivity uses much bigger frames than Ethernet so more often than not generating more smaller packets would increase your overall throughput (to a limit) unless you are on a very controlled network.
      - theptip 11y ago
        What do you mean by "it's often not sustainable"? Throughput on a server is higher at higher packet size, so if you're doing a download I'd expect the server to send 1500 byte packets. It's pretty easy to saturate a link with 1500 byte packets, and it's much harder to do so at lower packet sizes (from the server's perspective) since the per-packet processing costs start to dominate over the per-byte costs. Admittedly my knowledge of this sort of stuff is mostly intra-DC; is there some other factor that you're referring to that supersedes this on the web? I'm not aware of prioritizing smaller packets on the backbone, sounds like something that would be targeted at small flows (i.e. first N packets in a flow get a priority bump)? More info on that would be appreciated.
        Ded7xSEoPKYNsDd 11y ago
        I don't know about cable, but DSL usually uses PPPoE. It has on overhead of 8 bytes, lowering the MTU of those connections to 1492 bytes.
        dogma1138 11y ago
        It doesn't matter the MTU setting on your end for WAN and ISP / interlink grade networks is meaningless they don't use Ethernet, FDDI frame size is 4500 (ATM is about double that) bytes (minus what ever overhead, but usually 4200 and change) ISP/WAN routers don't care about how many mbit/s they transfer but how many packets they route at per given unit of time, as packets get packed into a single frame the smaller the packet the more packets they can transfer each frame. Also from a more high level point of view if you think about it the small packets are the most critical ones and they are at least as far as responsiveness goes DNS is limited to 512bytes over UDP, TCP 3-way handshake packets are tiny and those are the packets that need to get to and back from their destination as fast as possible, delays in data transfers means slower speeds, delays of handshakes mean that your application can fail or hang. Other important traffic such as VOIP[0] also uses very small packet sizes for this same reason most critical services need to transfer very little data (per given unit of time) but need to update data as frequently as possible to provide the illusion of real time and to mask the latency, same goes for other things like online/multi-player gaming and so on and on and on. Pretty much if you want your service to be as responsive as possible limit your packet size to the smallest size possible and increase your PPS this will ensure that your packets get quicker to their destination. [0]VOIP Packet Sizes http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html http://www.cisco.com/c/en/us/support/docs/voice/voice-qualit... The only time you would want to use large packets is pretty much when you can have a buffer, this means that you need to handle less packets per second which lowers CPU consumption (across the entire path) so video streaming and such can use pretty much as large of an MTU as they want unless they start getting fragments.
  - gvb 11y ago
    "A correctly-formed ping packet is typically 56 bytes in size, or 84 bytes when the Internet Protocol header is considered. However, any IPv4 packet (including pings) may be as large as 65,535 bytes." Ref: https://en.wikipedia.org/wiki/Ping_of_death https://en.wikipedia.org/wiki/Ping_of_death ;-)
avar 11y ago
By far the biggest impact on tunneling over DNS is whether or not you can make direct DNS queries to the server running iodine. I did some tests a while and found that iodine was ~98% of non-tunneled speed when I could access the server directly, since then the traffic is wrapped over huge big TXT queries and it's really efficient. But the common case for using it is that you can only lookup through a local DNS server, and then it's usually ~0.5% or so of the usual speed. I.e. 1-2KB/s at best.

I haven't tried comparing both. I don't have much resources. All I can say is that using icmptunnel, one couldn't differentiate whether it's using tunnel or direct internet. Hence ICMP tunneling was very fast. Although I'm interested in comparison as well :)

dogma1138 11y ago

DNS is less reliable, but could give you bigger throughput (you can send and request large records) ICMP packets would arrive quicker, will be more reliable will bypass various DNS hijackers (common with many ISP's) along the way. DNS also requires you to have a DNS server and a domain, and you'll need something to constantly clear the cache on the local machine otherwise you'll eventually run out of room even if you are going to use the max available DNS record size. If anything in the way will keep your DNS queries in cache then you might be screwed and run out of space very quickly. If you need internet access ICMP tunnel will be better, bandwidth will be limited but it will be more or less a P2P tunnel, if you need to exfiltrate data without explicitly needing to maintain a bi-directional tunnel DNS is the way to go, will also work in more captive portal restrictive cases than ICMP. Today ICMP is usually utterly blocked DNS sometimes work especially in common cases where the restricted network offers some white listed sites (e.g. airport wifi that allows you to access the airport's site and the local train service but blocks everything else).

vampire_dk 11y ago
With even ICMP you can send/receive large messages. There is no restriction on the maximum payload length.
- dogma1138 11y ago
  I haven't seen a single network stack that doesn't limit the size of the tailing payload or packet in general (MTU's ;)), go try and push 65507 bytes of payload into the message and tell me how it goes. In any case DNS tunnel offers you both TCP and UDP tunneling at much higher throughput, I'll take a look at your code when I'll have the time and see how it compares to ptunnel or ICMP shell.
- vampire_dk 11y ago
  Normally, an ethernet or wifi restricts an MTU of 1500. I use ping packets accordingly
  - dogma1138 11y ago
    1500 is the MTU of Ethernet, it's often not sustainable on end to end connection (especially when you add frame overheads) if you are using that high of a payload size you'll get considerably worse performance than say limiting it to around 500 bytes, you are welcomed to try it. Also with how global traffic is managed smaller packets tend to get priority since they can be qued quicker backbone connectivity uses much bigger frames than Ethernet so more often than not generating more smaller packets would increase your overall throughput (to a limit) unless you are on a very controlled network.
    - theptip 11y ago
      What do you mean by "it's often not sustainable"? Throughput on a server is higher at higher packet size, so if you're doing a download I'd expect the server to send 1500 byte packets. It's pretty easy to saturate a link with 1500 byte packets, and it's much harder to do so at lower packet sizes (from the server's perspective) since the per-packet processing costs start to dominate over the per-byte costs. Admittedly my knowledge of this sort of stuff is mostly intra-DC; is there some other factor that you're referring to that supersedes this on the web? I'm not aware of prioritizing smaller packets on the backbone, sounds like something that would be targeted at small flows (i.e. first N packets in a flow get a priority bump)? More info on that would be appreciated.
      - Ded7xSEoPKYNsDd 11y ago
        I don't know about cable, but DSL usually uses PPPoE. It has on overhead of 8 bytes, lowering the MTU of those connections to 1492 bytes.
        dogma1138 11y ago
        It doesn't matter the MTU setting on your end for WAN and ISP / interlink grade networks is meaningless they don't use Ethernet, FDDI frame size is 4500 (ATM is about double that) bytes (minus what ever overhead, but usually 4200 and change) ISP/WAN routers don't care about how many mbit/s they transfer but how many packets they route at per given unit of time, as packets get packed into a single frame the smaller the packet the more packets they can transfer each frame. Also from a more high level point of view if you think about it the small packets are the most critical ones and they are at least as far as responsiveness goes DNS is limited to 512bytes over UDP, TCP 3-way handshake packets are tiny and those are the packets that need to get to and back from their destination as fast as possible, delays in data transfers means slower speeds, delays of handshakes mean that your application can fail or hang. Other important traffic such as VOIP[0] also uses very small packet sizes for this same reason most critical services need to transfer very little data (per given unit of time) but need to update data as frequently as possible to provide the illusion of real time and to mask the latency, same goes for other things like online/multi-player gaming and so on and on and on. Pretty much if you want your service to be as responsive as possible limit your packet size to the smallest size possible and increase your PPS this will ensure that your packets get quicker to their destination. [0]VOIP Packet Sizes http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html http://www.cisco.com/c/en/us/support/docs/voice/voice-qualit... The only time you would want to use large packets is pretty much when you can have a buffer, this means that you need to handle less packets per second which lowers CPU consumption (across the entire path) so video streaming and such can use pretty much as large of an MTU as they want unless they start getting fragments.
- gvb 11y ago
  "A correctly-formed ping packet is typically 56 bytes in size, or 84 bytes when the Internet Protocol header is considered. However, any IPv4 packet (including pings) may be as large as 65,535 bytes." Ref: https://en.wikipedia.org/wiki/Ping_of_death https://en.wikipedia.org/wiki/Ping_of_death ;-)

avar 11y ago

By far the biggest impact on tunneling over DNS is whether or not you can make direct DNS queries to the server running iodine. I did some tests a while and found that iodine was ~98% of non-tunneled speed when I could access the server directly, since then the traffic is wrapped over huge big TXT queries and it's really efficient. But the common case for using it is that you can only lookup through a local DNS server, and then it's usually ~0.5% or so of the usual speed. I.e. 1-2KB/s at best.