Can you attach the tracert log? You should end up at 79.161.150.134.
I'm using UptimeRobot to monitor uptime from two different physical locations. Tellmon.net is responding from both of these.

Her er tracert for PCen hjemmem hvor det går bra å koble til tellmon,net, 
Tracing route to tellmon.net [79.161.150.134] over a maximum of 30 hops:
1 1 ms <1 ms 1 ms router.asus.com [192.168.1.1]
2 28 ms 28 ms 29 ms c01A0BF51.dhcp.as2116.net [81.191.160.1]
3 28 ms 37 ms 160 ms te1-0-2.cr2.nord41.as2116.net [195.0.242.153]
4 28 ms 28 ms 28 ms ae1.cr2.bo.as2116.net [193.75.3.43]
5 39 ms 36 ms 37 ms ae2.cr1.prinsg39.as2116.net [193.75.3.40]
6 52 ms 45 ms 44 ms ae2.cr1.san110.as2116.net [195.0.240.90]
7 44 ms 44 ms 44 ms te3-0-0.br1.osls.as2116.net [193.75.2.154]
8 45 ms 45 ms 46 ms 193.156.120.66
9 45 ms 44 ms 44 ms 237.79-160-112.customer.lyse.net [79.160.112.237]
10 45 ms 46 ms 46 ms 2.79-160-49.customer.lyse.net [79.160.49.2]
11 48 ms * 47 ms 65.79-160-49.customer.lyse.net [79.160.49.65]
12 48 ms 47 ms 47 ms 203.79-160-49.customer.lyse.net [79.160.49.203]
13 * * * Request timed out.
14 * * * Request timed out.

30 * * * Request timed out.
Trace complete.

Det ender ikke på den adressen du oppga. 79.161.150.134.

Fra jobben er tracert det samme: 

Tracing route to www.tellmon.net [79.161.150.134]   over a maximum of 30 hops:
1 * * * Request timed out.
2 <1 ms <1 ms <1 ms 158.39.96.1
3 5 ms 3 ms 3 ms npolar-gw.npolar.no [158.39.97.65]
4 3 ms 3 ms 5 ms vethstromso-gw.uninett.no [128.39.230.189]
5 3 ms <1 ms 1 ms tromso-gw4.uninett.no [128.39.230.205]
6 2 ms 1 ms 1 ms tromso-gw2.uninett.no [128.39.255.157]
7 15 ms 15 ms 17 ms trd-gw.uninett.no [128.39.254.101]
8 22 ms 22 ms 22 ms oslo-gw1.uninett.no [128.39.255.45]
9 24 ms 30 ms 33 ms 193.156.90.66
10 23 ms 23 ms 23 ms 237.79-160-112.customer.lyse.net [79.160.112.237]
11 24 ms 24 ms 28 ms 2.79-160-49.customer.lyse.net [79.160.49.2]
12 26 ms 26 ms 26 ms 65.79-160-49.customer.lyse.net [79.160.49.65]
13 26 ms 26 ms 26 ms 203.79-160-49.customer.lyse.net [79.160.49.203]
14 * * * Request timed out.
15 * * * Request timed out.

30 * * * Request timed out.
Trace complete.

Regner med at sideforespørselen kommer til serveren også her men at noe gjør at den ikke svarer? 

As a side-note I have installed a new firewall today that should take the load much better than the old one. 

Hi Pål
I now reach tellmon.net using tracert from both locations and can also ping the server from both places. But the website does only respond when I try from  81.191.167.157. From 158.39.96.23 I get no response

I can see 81.191.167.157 in my logs, but I find no mention of 158.39.96.23 in any logs. I'm sorry, but I don't know what else to look for. http://tellmon.net is available from all the locations I can try from. If the 158.39.96.23 location is connecting via a proxy, make sure it is configured to send the HOST header in the http requests. 

Very strange. We do not use proxy. You can find nothing from other IPs starting with 158.39 either? I can start a "ping tellmon.net -t" from a problematic PC at an agreed time. Then you must be able to find traffic reaching the tellmon server
 

The pings are only reaching my firewall and not the server. As it should be. Since you can ping the IP, but not access tellmon.net (note you'll need to use the domain name and not the IP when trying to access the site) I'm not sure what the problem is. As other users can access the site just fine I'm having trouble figuring out why the firewall should block only you.

I have also had problems to connect for a couple of weeks - but only intermittently
Attaching tracert log made when I can not connect.

Tracing route to www.tellmon.net [79.161.150.134]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.254.90
2 <1 ms <1 ms <1 ms dr-se-sto-kn5-2-vl452.bredband2.net [217.115.41.217]
3 1 ms 1 ms 1 ms cr-se-kista-esbogatan11-1-be2.bredband2.net [82.209.176.141]
4 41 ms 1 ms <1 ms ae3.stk10.ip4.gtt.net [77.67.82.1]
5 1 ms <1 ms <1 ms xe-2-3-0.stk30.ip4.gtt.net [89.149.183.250]
6 5 ms <1 ms <1 ms as3549.ip4.gtt.net [77.67.82.146]
7 1 ms 1 ms 1 ms ae10.csr1.ARN3.gblx.net [67.17.74.41]
8 1 ms 1 ms 1 ms po6-60G.ar2.ARN3.gblx.net [67.16.146.82]
9 9 ms 11 ms 11 ms altbox.tengigabitethernet4-4.ar2.arn3.gblx.net [209.130.172.58]
10 37 ms 34 ms 44 ms 237.79-160-112.customer.lyse.net [79.160.112.237]
11 31 ms 31 ms 31 ms 2.79-160-49.customer.lyse.net [79.160.49.2]
12 37 ms 36 ms 36 ms 65.79-160-49.customer.lyse.net [79.160.49.65]
13 33 ms 33 ms 33 ms 203.79-160-49.customer.lyse.net [79.160.49.203]
14 * * * Request timed out.
 :
30 * * * Request timed out.

Trace complete.

This is very strange. I'm using UptimeRobot to monitor site uptime from external locations. It's checking tellmon.net from two different locations every 5 minutes. And it's not reporting any downtime.

Can you open your browser on http://minip.no and send me your IP address?

Just want to check they are have not been blocked by my firewall. Some IP's are doing non-standard http requests and are being blocked by my firewall.

217.115.41.218 (that's one away from the IP of your first hop) are being blocked by my firewall due to malicious http attempts. Not sure if that's you or not. 

217.115.41.218 - that's me! Don't know what I have done that is considered malicious, though.
Is the block time limited? I actually succeed in seeing the sensors from time to time.
Thanks again for your site - very useful.

The firewall does protocol inspection. So traffic on port 80 that does not adhere to the HTTP protocol is blocked. The blocking lasts 5 minutes only. So yes, it's time limited.

According to the logs you got blocked for doing a unknown HTTP command. I.e. something else than GET, POST, PUT, DELETE, OPTION, HEAD. The log does not state what. Are you running some funny software on your computer?

Nope, firefox and no particular add-ons. I'll see if I can find out what's going on by analyzing the traffic when I have the time. 

Hi Pål
At the moment I am on 

IP-Address:	158.39.96.58
Hostname:	apnpc058.akvaplan.niva.no

Tracert from that PC done now is as follows
Tracing route to tellmon.net [79.161.150.134]
over a maximum of 30 hops:


1 * * * Request timed out.
2 3 ms <1 ms <1 ms 158.39.96.1
3 3 ms 4 ms 5 ms npolar-gw.npolar.no [158.39.97.65]
4 3 ms 3267 ms 17 ms vethstromso-gw.uninett.no [128.39.230.189]
5 <1 ms <1 ms <1 ms tromso-gw4.uninett.no [128.39.230.205]
6 3 ms <1 ms <1 ms tromso-gw2.uninett.no [128.39.255.157]
7 16 ms 15 ms 15 ms trd-gw.uninett.no [128.39.254.101]
8 23 ms 22 ms 22 ms oslo-gw1.uninett.no [128.39.255.45]
9 23 ms 26 ms 26 ms 193.156.90.66
10 24 ms 23 ms 23 ms 237.79-160-112.customer.lyse.net [79.160.112.237]
11 27 ms 27 ms 28 ms 2.79-160-49.customer.lyse.net [79.160.49.2]
12 26 ms 27 ms 26 ms 65.79-160-49.customer.lyse.net [79.160.49.65]
13 26 ms 26 ms 26 ms 203.79-160-49.customer.lyse.net [79.160.49.203]


14 27 ms 26 ms 30 ms 134.79-161-150.customer.lyse.net [79.161.150.134
]


Trace complete.

Shaking this thread a little. Doing a traceroute works fine, but I never gets the site loaded to either of my web browsers (Firefox/Safari/Chrome), "The server is not responding". The web page works fine on my mobile, but not on my computer.

According to https://www.site24x7.com/public/t/results-1431343994872.html the web site is available from all locations (except one, but a retest showed that working as well).

I suspect you are running some software on your computer what prevents you from accessing the site.

Can you visit this site: http://myhttp.info/

And post your http headers?

The IP adresses are 158.39.96.x

Request method	GET
Request URI	/
Request protocol	HTTP/1.1
Accept	text/html, application/xhtml+xml, */*
Accept charset
Accept encoding	gzip, deflate
Accept language	en-GB,en;q=0.7,nb;q=0.3
Connection	Keep-Alive
Host	myhttp.info
Referer
User agent	Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

HTTP Request
Request methodGET
Request URI/
Request protocolHTTP/1.1
Accepttext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept charset
Accept encodinggzip, deflate
Accept languageen-US,en;q=0.5
Connectionkeep-alive Hostmyhttp.info
Referer
User agentMozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0

The headers seems fine. Checked the firewall logs and no mention that anything from 158.39.96.* has been blocked either.
Can you check if you can reach http://paks.no or http://crashtest.ninja as well? These are two other web sites running on the same server.

Nope. Times out. On all web browsers. All other web traffic working fine.

http://paks.no and http://crashtest.ninja time out as well

Very strange. No mention of 158.39.96.* in any of the IIS log files, so you are simply not reaching the server.
I've turned on default binding, can you see if you can reach anything now?

Can you check calls from 192.36.162.*? That's me. This might be a network thing on my side (at work, so I can't control it), because if I use my phone to connect, it works, but if I switch on wifi on the phone the connection times out. But it's strange that it is only your servers that I fail to connect to. Absolutely everything else works as expected on this work wifi.

Nope. Nothing for 192.36.162.* either.

There is nothing on Tellmon that should cause it to be blocked. I'm not doing anything fancy, not should the address be blocked by any filters. Could you have a colleague try from another computer on the work network? Good to know if it's an issue with your computer or the whole network.

My colleagues can't connect either. So something in my network is filtering out your addresses (and your only). Time to make a support call, I guess ... But it's really strange that traceroute works.

Yes. Since both ping and traceroute works the only thing I can figure is that your company has a proxy or antivirus that stops the web traffic. Usually those are used to stop employees accessing gambling, porn or similar sites. And most often you are told that site so and so was blocked because it is against company policies.

As far as the 158.39.96.X network is concerned, there is definitely no proxy or other filtering configured, (I am the IT-mgr of that network)

We have found that it MIGHT be connected with the MTU size. Our network technicians are diggin' in deeper if it is the cause of this problem.

Well, this network has no proxy, and reaching anything that is not blocked by Ecpat works. I have asked our network gurus to look into the matter. I'll keep you posted.

From our network techs (I guess you know Swedish Pål, so I won't translate it):

"Har nu gjort diverse tester och enligt vad jag kan se så är det troligtvis storleken på paketen från ”paks.no” som är problemet. När man kör från vårt demonät är MTU-storleken mindre än från t ex ECN (anledningen till detta är en annan historia…), och i normala fall så anpassas paketstorleken efter detta. Jämför jag t ex storleken på mottagna paket från ”www.dn.se” till en klient på demonätet med en klient på ECN, så ser jag att paketen är mindre som går till klienten på demonätet. Av någon anledning verkar dock inte denna anpassning göras när man kopplar upp sig mot ”paks.no”, vilket gör att paketen inte kommer fram till klienten.

Mats: Can you ask the techs what MTU I should use? I'm running pfSense as a firewall with the default WAN MTU settings (1500 bytes). Must confess that this is a bit above my networking understanding.

And their reply: :-)

I do not think it’s the actual MTU on the FW that should be changed. 1500 bytes is standard. It seems more like the TCP Path MTU Discovery (PMTUD) isn’t working, i.e. the function to discover the MTU of the complete path between the server and the client. PMTUD is using ICMP, so I think a first step can be to make sure the FW does not block incoming ICMP type 3 code 4 messages (i.e. “Destination Unreachable, Fragmentation Needed and Don’t Fragment was Set”. These ICMP messages must be able to reach the webserver so it can adjust the packet size accordingly.

ICMP is not blocked. Also according to this MTU test page (http://www.letmecheck.it/mtu-test.php). According to that test 1500 is the max size I can have and still not fragment the packages.

Open the page and enter paks.no as target and test yourself.

MTU test :

Let me Test it

28

Online MTU test allows you to test the maximum MTU size from our host to your destination. To check your MTU, simply provide your IP or DNS hostname. We will test the PMTU (Path Maximum Transfer Unit) aka maximum MTU size (unfragmented) between our host and your destination, most likely the outside of your router or firewall.
More info: Wikipedia

This online MTU test is in BETA. Please let us know, using our contact form, if you find any irregularities.

Sending 32 bytes to Paks.no <- not fragmented Sending 750 bytes to Paks.no <- not fragmented Sending 1125 bytes to Paks.no <- not fragmented Sending 1313 bytes to Paks.no <- not fragmented Sending 1407 bytes to Paks.no <- not fragmented Sending 1454 bytes to Paks.no <- not fragmented Sending 1478 bytes to Paks.no <- FRAGMENTED! Sending 1466 bytes to Paks.no <- not fragmented Sending 1472 bytes to Paks.no <- not fragmented Sending 1475 bytes to Paks.no <- FRAGMENTED! Sending 1473 bytes to Paks.no <- FRAGMENTED! Sending 1472 bytes to Paks.no <- not fragmented From the tests we did, we can assume that 1472 bytes is the largest unfragmented packet size. The MTU size would be 1500, made up from 1472 payload and 28 ICMP/IP Headers and payload information. 

The maximum MTU size for Paks.no is: 1500
 NB: The Internet Protocol requires that hosts must be able to process IP datagrams of at least
576 bytes (for IPv4) or 1280 bytes (for IPv6)

 

More from the tech:

This MTU test only tests the MTU on the connection between “www.letmecheck.it” and “paks.no”, not from my client to “paks.no”, i.e. I will get the same result as you.

I still think it’s PMTUD functionality that is broken, the question is which node(s) that breaks it… Is 79.161.150.134 the “real” address of the web server, or it is hidden behind NAT on the FW? What kind of web server are you running?

The web server is IIS 8.5 running on Windows server 2012 R2.
It is being NATed by a pfSense based firewall. Port 80 is forwarded to IIS which in turn uses the HOST http header to route to the correct web site.

It's available via both IPv4 and IPv6

Maybe we are getting closer to the problem? More from the network guru:

---

I do not have any experience of pfSense firewalls, but looking at the web it seems like pfSense has a known problem with PMTUD in conjunction with NAT. My suggestion is to try the setting the kernel parameter “net.inet.icmp.reply_from_interface=1” according to the following web site to see if that fixes the problem:

https://plone.lucidsolutions.co.nz/networking/pfsense/pfsense-v2.1.5-pmtud-issue-with-ipv4-and-nat
---

Unfortunately this bug was fixed about 6 months ago. Anyways I did check the sysctl net.inet.icmp.reply_from_interface setting and it was already 1.

Tellmon has over 1500 users, the other web sites running on the same server has even more users. I find it strange that an supposed MTU issue should prevent 3 users access. My feeling is that a much larger group should have issues. I've tested the site with all the tools and checks I can think of. And none are reporting any issues.

Tellmon is available via both IPv4 and IPv6 from over 50 different locations I've tested from.

I do agree that it's a minor problem, but nevertheless interesting to dig into. I have the possibility to select another network where this works well. But as strange it is for you that 1500 users can connect without problem, it is equally strange that we (the three users) can't access your sites from our side. And only your sites. Absolutely all other sites I have tested works as expected (as noted, we can traceroute to tellmon.net, but the web server won't give us it's content).

If the error is in our domain or in yours we probably never will find out unless we continue to work together, but if you find it to much of a hassle I will stop the work initiated and move to another network when I need to connect to tellmon.net.

No problem, if you want to continue to dig that is fine. It would be good to track down the issue. I'm just out of ideas. I've run all the tests I can think of and I've spent hours googling and going through settings. But if you have any ideas or settings I can try please let me know.

I have tested at least three other networks. It does not work from uit.no, npolar.no, nilu.no and akvaplan.niva.no

@Jos: What do you mean. Can't you access tellmon.net from within the networks of UiT, npolar, nilu and akvaplan?
Or can't you access those web sites neither from the same network you have issues with tellmon from?

You mentioned tha it was strange that Tellmon.net could be reached by all except from three networks. That is not the case. I cannot reach tellmon.net from any of the networks I mentioned. So, I tried to connect to Tellmon.net from 4 different networks, all with the same result. If only works from home (homenet,no)

Then the issue is to figure out what all these networks have in common. The ones Jos mentions all seems to be related to Universities or science. Where do you work Mats?

Could any of you do a simple connectivity test on port 80?
If you have telnet installed you can do the following from a command prompt:

telnet tellmon.net 80

It will try to connect to port 80 (http) on tellmon, it would be good to know if it connects at all. If you do not have telnet installed download a tool called portping that I made here: https://www.dropbox.com/s/2tth5ig7oqg0iiw/PortPing.zip?dl=0

Unzip and run from command prompt (requires .Net runtime)

portping tellmon.net 80

I work for Ericsson and connects trough a demo network outside our corporate firewall (directly connected to Telia). See tracert in the next message.

The telnet reports the following:

mg11:~ Mats$ telnet tellmon.net 80
Trying 79.161.150.134...
telnet: connect to address 79.161.150.134: Operation timed out
Trying 2a01:79d:3e86:5a18:5945:87fd:f332:83c...
telnet: connect to address 2a01:79d:3e86:5a18:5945:87fd:f332:83c: No route to host
telnet: Unable to connect to remote host

traceroute to tellmon.net (79.161.150.134), 64 hops max, 72 byte packets
1 10.4.4.1 (10.4.4.1) 3.298 ms 1.915 ms 2.128 ms
2 192.36.162.9 (192.36.162.9) 2.676 ms 2.291 ms 2.279 ms
3 ilikr2-ge-0-0-3-1.ilik.net (192.71.20.21) 5.031 ms 509.863 ms 4.442 ms
4 telia-gw.ilik.net (192.71.20.25) 2.745 ms 2.808 ms 2.957 ms
5 193.181.252.67 (193.181.252.67) 3.065 ms 3.087 ms 2.987 ms
6 sesbww01-r12.ericsson.net (193.180.17.236) 2.984 ms 3.087 ms 3.340 ms
7 78.77.163.217 (78.77.163.217) 3.033 ms 4.801 ms 3.232 ms
8 s-b6-link.telia.net (80.91.250.43) 3.828 ms 4.179 ms 4.517 ms
9 level3-ic-155475-s-b2.c.telia.net (213.248.99.134) 42.783 ms 31.932 ms 31.786 ms
10 * ae-1-3.bear1.oslo2.level3.net (4.69.202.245) 28.569 ms 29.383 ms
11 ae-1-3.bear1.oslo2.level3.net (4.69.202.245) 28.428 ms 28.698 ms 28.451 ms
12 62.140.27.6 (62.140.27.6) 28.766 ms 28.999 ms 28.393 ms
13 216.213-167-114.customer.lyse.net (213.167.114.216) 29.179 ms 30.508 ms 31.162 ms
14 237.79-160-112.customer.lyse.net (79.160.112.237) 30.061 ms 28.175 ms 28.393 ms
15 2.79-160-49.customer.lyse.net (79.160.49.2) 29.889 ms 29.706 ms 29.963 ms
16 65.79-160-49.customer.lyse.net (79.160.49.65) 32.049 ms 31.082 ms 31.180 ms
17 203.79-160-49.customer.lyse.net (79.160.49.203) 31.332 ms 31.903 ms 31.391 ms
18 134.79-161-150.customer.lyse.net (79.161.150.134) 31.324 ms 31.248 ms 31.329 ms

This is from a machine outside of my network:

IPv6:
$ telnet tellmon.net 80
Trying 2a01:79d:3e86:5a18:5945:87fd:f332:83c...
Connected to tellmon.net

IPv4
$ telnet -4 tellmon.net 80
Trying 79.161.150.134...
Connected to 134.79-161-150.customer.lyse.net

The "no route to host" error you get when telnet tries IPv6 does not seem right. Could there be an IPv6 routring/host resolve issue? Could you try to temporary disable IPv6. If using Windows just uncheck IPv6 protocol for the network adaptor. Or start Chrome and temporary disable IPv6 there: Using about: config and set setting network.dns.disableIPv6 to true

No effect. Disabled ipv6 on my Mac with "networksetup -setv6off Wi-Fi" and rebooted. Still the same result.

Can you try a "tracepath" or use "mturoute" on Windows?

$ tracepath -n 79.161.150.134

Check the linked document on the tracepath equivalent on the Mac measuring the MTU from 1444 to 1508.
(ping -g 1444 -G 1508 -c 2 -h 1 -D tellmon.net)

https://www.dropbox.com/s/d6zznaypfb2uw49/Tracepath-tellmon_net.pdf?dl=0

I'm trying to get help from the pfSense (my firewall) forum in a thread over here: https://forum.pfsense.org/index.php?topic=94040.0

it happens to me as well for some time. however, it works from my ios phone, from within the same network. I have the feeling it has something to do with cookies, because it didn't work on ios either, until I cleared the cache & history in safari & chrome mobile. then it started to work, loading the cookie message at first access, and checking the checkmark there. I would suggest to suspend the cookie action temporarely from your website, to see if that solves the problem of accessing your website. a ping or tracert to tellmon.net gets through, though!

Cookies are not shared between browsers. So if it was a cookie-problem simply trying another browser or even running chrome/ie/firefox or what ever in "privacy mode" would solve the issue. Cookies are used as a session identifier to persist your authentication so you don't have to re-login on every page load. The site requires that function to work.

Even without cookies you should always get the front page, since that does not require authentication. Also people with connectivity issues cannot reach any of the other web sites on the same server either (test http://paks.no or http://crashtest.ninja).

That it works from an iOS device on the same network is really interesting though.

What is even more interesting is that I CAN ACCESS IT from Tor Browser, on the same computer where no other browser works.

http://crashtest.ninja and http://paks.no are also NOT accessible from Chrome, but accessible from Tor...