5 ms·

I built an HTTP service that listens on all 65535 TCP ports and tells you which port you connected to (very useful to diagnose which outbound ports are firewall

by mrb 9y ago

I built an HTTP service that listens on all 65535 TCP ports and tells you which port you connected to (very useful to diagnose which outbound ports are firewalled by ISPs or by Wifi networks): http://open.zorinaq.com/ http://open.zorinaq.com/ The folks at Cloudflare have done it with an iptables TPROXY rule (which requires the socket to have the IP_TRANSPARENT option) which is how I did it too. But there is another way to do this in Linux: you can use an iptables REDIRECT rule, and the userspace program can obtain the original destination port by doing a getsockopt() call to read SO_ORIGINAL_DST. Edit: oh I see now the blog post does mention the REDIRECT & SO_ORIGINAL_DST option, but criticize its performance... which makes sense given its dependence on conntrack. There is a typo in Cloudflare's blog post: s/SO_TRANSPARENT/IP_TRANSPARENT/

majke 9y ago
Indeed! Conceptually REDIRECT is _very_ similar to TPROXY. The subtle difference is that REDIRECT seems to rewrite the destination-host-and-port while TPROXY keeps it the same, only does the routing earlier. In practical terms to recover original target in REDIRECT you have to use the obscure SO_ORIGINAL_DST, while for TPROXY getpeername() will just work. By this token TPROXY is a bit easier to use. This is for TCP. UDP is a bit harder.
jiveturkey 9y ago
neat. but why do you need a service at all to detect blocking? you can use timing to also do it easily without the need for any server component at all. perhaps this works poorly for firewalls near to the service but you declared the problem to be one close to the client. AIUI
- mrb 9y ago
  When an ISP blocks certain ports by dropping the SYN packet, the client sees a time out. There is nothing to "time" that can prove it's the ISP dropping it.
  - jiveturkey 9y ago
    yes there is. When you don't get a RST back at the expected time (say *2), you know SYN was dropped. Are you arguing that it could be packet loss? You address that by taking multiple samples, and by comparing against loss to ports that you get ACK back from.
    - mrb 9y ago
      «you know SYN was dropped» But you don't know who dropped it: the ISP or the remote server. In order to show it's the network between the client and server dropping it, you need a server that behaves in a known way, hence open.zorinaq.com I used to work in the InfoSec industry, running port scans from various locations, and open.zorinaq.com was incredibly useful to ensure there was no random firewall preventing us from finding certain open ports. That was the primary motivation why I built the service.

by mrb 9y ago

majke 9y ago

Indeed! Conceptually REDIRECT is _very_ similar to TPROXY. The subtle difference is that REDIRECT seems to rewrite the destination-host-and-port while TPROXY keeps it the same, only does the routing earlier. In practical terms to recover original target in REDIRECT you have to use the obscure SO_ORIGINAL_DST, while for TPROXY getpeername() will just work. By this token TPROXY is a bit easier to use. This is for TCP. UDP is a bit harder.

jiveturkey 9y ago

neat. but why do you need a service at all to detect blocking? you can use timing to also do it easily without the need for any server component at all. perhaps this works poorly for firewalls near to the service but you declared the problem to be one close to the client. AIUI

mrb 9y ago
When an ISP blocks certain ports by dropping the SYN packet, the client sees a time out. There is nothing to "time" that can prove it's the ISP dropping it.
- jiveturkey 9y ago
  yes there is. When you don't get a RST back at the expected time (say *2), you know SYN was dropped. Are you arguing that it could be packet loss? You address that by taking multiple samples, and by comparing against loss to ports that you get ACK back from.
  - mrb 9y ago
    «you know SYN was dropped» But you don't know who dropped it: the ISP or the remote server. In order to show it's the network between the client and server dropping it, you need a server that behaves in a known way, hence open.zorinaq.com I used to work in the InfoSec industry, running port scans from various locations, and open.zorinaq.com was incredibly useful to ensure there was no random firewall preventing us from finding certain open ports. That was the primary motivation why I built the service.