Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IP traffic over ICMP tunneling

github.com

Post reply on HN
Print view View original

61–70 of 86 posts

Re: IP traffic over ICMP tunneling

#61

Post by simoncion »

dogma1138 wrote: post #8
vampire_dk wrote: post #4

Earlier quoted context omitted.

I agree that some captive portals/firewalls do block ICMP but still I've seen many in my country which don't.

Well the question is then what's the point other than a personal exercise? There is plenty of ICMP / multi protocol tunnels software out there for both linux and windows much of it doesn't require administrative privileges. Also ptunnel comes standard with some linux distro's these days Ubuntu and so do probably most of it's derivatives, and as far as raw performance goes ptunnel is also the highest performing one ca…

> Well the question is then what's the point other than a personal exercise?

What's your question? Is it "What's the point of blocking ICMP?"? Or is it the opposite question?

If it's the former, then there are sysadmins out there who cargo-cult their network configuration and listen to folks like Gibson Research Corporation who've been giving really bad advice [0] for the past decade+.

[0] Specifically, they strongly recommend dropping all traffic to ports that don't have listening services, along with all ICMP, rather than rejecting said traffic and allowing all non-problematic ICMP. They also have a "handy" tool [1] to make it look like doing anything else is "DANGEROUS": (The tool reports [2] if your site responds to ICMP echo requests.)

[1] https://www.grc.com/shieldsup

[2] Ping Reply: RECEIVED (FAILED) — Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers. This is highly recommended since "Ping" is among the oldest and most common methods used to locate systems prior to further exploitation.

Re: IP traffic over ICMP tunneling

#62

Post by dogma1138 »

simoncion wrote: post #59
dogma1138 wrote: post #31

Earlier quoted context omitted.

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…

> 1500 is the MTU of Ethernet... It's the de-facto MTU of much of The Internet. Baby Jumbo (MTU >1500 but Edit: > Also with how global traffic is managed smaller packets tend to get priority... Do you have a reliable citation for this? I would expect that core and near-core devices would handle so much traffic, that they all would be using MTUs far higher than 1500 bytes per frame.

It's pretty standard QoS measure, network schedulers especially for multiplexed/aggregated networks will have a bias for small packets, you should be able to find performance statistics for various token bucket configurations that will demonstrate that.

Re: IP traffic over ICMP tunneling

#63

Post by dogma1138 »

simoncion wrote: post #60
dogma1138 wrote: post #58

Earlier quoted context omitted.

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 th…

> It doesn't matter the MTU setting on your end for WAN and ISP / interlink grade networks is meaningless [as] they don't use Ethernet... It absolutely does matter and is quite meaningful. :) If you set your edge router's Internet-facing MTU to 9k, and the upstream equipment's MTU is smaller than that, then either your packets will be dropped, or PTMU Discovery will try to figure out the MTU of the path. (Better hope…

Poor choice of words on my part, if you configure jump frames on your uplink you are going to kill your network stack, if you limit it too much you'll have a huge overhead. The point being is that for transferring data especially when responsiveness is important if not paramount utilizing the maximum potential frame size you can push without fragmentation would generally yield a poorer result in real world applications.

Re: IP traffic over ICMP tunneling

#65

Post by gvb »

vampire_dk wrote: post #24
dogma1138 wrote: post #22

Earlier quoted context omitted.

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…

With even ICMP you can send/receive large messages. There is no restriction on the maximum payload length.

"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 ;-)

Re: IP traffic over ICMP tunneling

#66

Post by motoboi »

Laforet wrote: post #56
vesinisa wrote: post #47

A few years back, I was assigned to work at a BigCorp's premises. They had really tight network security: all outward connections were blocked except through a dedicated HTTP proxy. This was bad news, since stuff like SSH are absolutely essential in my job. After few days of mobile tethering, I realized I could ask their HTTP proxy to open an HTTPS connection to a server outside the network, but instead of sending HT…

Sounds like they enabled HTTP CONNECT without limiting the accepted port range, so any protocol will go through. Maybe this is why Microsoft Azure never allowed ICMP travseral through their outer firewall despite frequent request from users....

It's common to run OpenVPN on TCP port 443 (HTTPS) to avoid such restrictions.

The Great China Firewall and others need deep packet inspection, heuristics and AI to find tunnels set up that way.

Re: IP traffic over ICMP tunneling

#67

Post by simoncion »

dogma1138 wrote: post #62
simoncion wrote: post #59

Earlier quoted context omitted.

> 1500 is the MTU of Ethernet... It's the de-facto MTU of much of The Internet. Baby Jumbo (MTU >1500 but Edit: > Also with how global traffic is managed smaller packets tend to get priority... Do you have a reliable citation for this? I would expect that core and near-core devices would handle so much traffic, that they all would be using MTUs far higher than 1500 bytes per frame.

It's pretty standard QoS measure, network schedulers especially for multiplexed/aggregated networks will have a bias for small packets, you should be able to find performance statistics for various token bucket configurations that will demonstrate that.

Do you have a cite for that? :) I know that CoDel doesn't bias for small packets; it treats all flows equally and tracks traffic on a bytes-transferred (rather than packets-transferred) basis.

Re: IP traffic over ICMP tunneling

#68

Post by simoncion »

dogma1138 wrote: post #63
simoncion wrote: post #60

Earlier quoted context omitted.

> It doesn't matter the MTU setting on your end for WAN and ISP / interlink grade networks is meaningless [as] they don't use Ethernet... It absolutely does matter and is quite meaningful. :) If you set your edge router's Internet-facing MTU to 9k, and the upstream equipment's MTU is smaller than that, then either your packets will be dropped, or PTMU Discovery will try to figure out the MTU of the path. (Better hope…

Poor choice of words on my part, if you configure jump frames on your uplink you are going to kill your network stack, if you limit it too much you'll have a huge overhead. The point being is that for transferring data especially when responsiveness is important if not paramount utilizing the maximum potential frame size you can push without fragmentation would generally yield a poorer result in real world applicatio…

> [I]f you configure [jumbo] frames on your uplink you are going to kill your network stack...

I can't agree with that statement. If upstream devices support larger than 1500 byte MTU, OR PTMU works correctly, then you are absolutely not going to "kill your network stack". At worst, (in the PMTU discovery phase) you'll see poor performance for a few moments while the MTU for the path is worked out, and then nothing but smooth sailing from then on.

> The point being is that for transferring data especially when responsiveness is important if not paramount utilizing the maximum potential frame size you can push without fragmentation would generally yield a poorer result in real world applications.

I'm not sure what you're saying here. Are you saying:

"If you configure your networking equipment to always wait to fill up a full L2 frame before sending it off, you'll harm perf on latency-sensitive applications."?

If you're not, would you be so kind as to rephrase your statement? I may be particularly dense today. :)

However, if you are, then that statement is pretty obvious. I expect that few people configure their networks to do that. However, I don't see what that has to do with the link's MTU. Just because you have a 9k+ MTU, doesn't mean that you have to transmit 9k of data at a time. :)

Re: IP traffic over ICMP tunneling

#69

Post by gonzo »

PinguTS wrote: post #53
vampire_dk wrote: post #4

Earlier quoted context omitted.

I agree that some captive portals/firewalls do block ICMP but still I've seen many in my country which don't.

Any major captive portal re-routes DNS requests to their Login-IP and block any IP leaving the local network. That essentily prohibits any ICMP request to the outside world.

Sure, but they still need to lookup the name.

Re: IP traffic over ICMP tunneling

#70

Post by suprjami »

dogma1138 wrote: post #31
vampire_dk wrote: post #29

Earlier quoted context omitted.

Normally, an ethernet or wifi restricts an MTU of 1500. I use ping packets accordingly

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…

Can you please clarify this comment? It sounds like you're saying Ethernet cannot maintain a line-rate transfer at the maximum MTU. But that can't be what you're saying, anyone could run an iperf/netperf or even large crafted packet transfer and prove this wrong.
Post reply on HN