About this blog…

I am employed by Netnod as head of engineering, research and development and am among other things chair of the Security and Stability Advisory Committee at ICANN. You can find CV and photos of me at this page.

As I wear so many hats, I find it being necessary to somewhere express my personal view on things. This is the location where that happens. Postings on this blog, or at Facebook, Twitter etc, falls under this policy.

The views expressed on this post are mine and do not necessarily reflect the views of Netnod or any other of the organisations I have connections to.

Internet Access at UN meeting is limited

At the Internet Governance Forum MAG meeting today, I heard people start complaining they can not access their chat service, and then email, and then VPN server at home. I did not have any problems, but that was (as I now know) because my VPN came up.

I used the brilliant software Netalyzr, and found that various ports where blocked for outgoing traffic even. Although it is explicitly requested that specifically this meeting should have all access open.

Netalyzr log

You can see the full log of the Netalyzr session here.

I think this is simply one more example of someone not knowing what they do. In some IT department disconnected from the main process in the organisation they work. They try to do their best. They make the wrong decisions, and it has great impact on the work done.

In this case UN discussions on use of IT tools, multistakeholder discussions, remote participation (!) and various other things.

5 comments to Internet Access at UN meeting is limited

  • Nicholas Weaver

    Hey, cool! Thats an amusingly-filtered network. Out of curiosity, are you running your VPN through a nonstandard port (eg, 443 or 22?)

    And thanks for the complements on Netalyzr.

    • paf

      I run the Cisco IPSEC client. Pretty standard config (i.e. tries several methods to connect). I’ll come back with the IPSEC config to you in email.

  • […] Internet Access at UN meeting is limited « stupid.domain.name […]

  • Nicholas Weaver

    Thanks.

    One thing we’ve found that if you want your data to get through, fallback to TCP port 443 (HTTP over TLS) is unmolested in almost every case, far less than anything else, so I’d like to know what the failover list is.

    The other one thats even worse in the irony category is the FCC public-access connection in the US, not only is it heavily filtered but it uses this awful bluecoat HTTP proxy that screws things up AND has a known vulnerability in it.

    • paf

      Using port 443 works better, but fails if there is a mandatory use of an HTTP proxy, and even SSL over HTTP (and similar) is problematic if the CONNECT method is blocked in the HTTP proxy. Something I have seen at few, but still some, places.