I believe we have a fix for this, which will be implemented this evening (all being well).
The problem is complex. Information follows. You might wish to read this laying down, or with a pillow near your head.
Our TS server has (recently) been using an IP address ending in .255 - and technically, there is nothing wrong with that at all.
However, in LAN environments, historically the x.x.x.0 and x.x.x.255 IP addresses were reserved as 'broadcast' addresses - and in almost all cases, that is still true now.
Most routers and networks interface cards are smart enough to know the difference between the local area network and the internet, and will look at more than just the .255 ending to decide whether to broadcast a packet on the LAN. If it's a LAN address with .255, broadcast it; if it's anything else with a .255 ending, sending it to the router for onward transmission to your ISP and then the internet.
However, it's come to light that there is something 'iffy' with these KPN/Arcadyan routers which (so far) only seem to be supplied in the Netherlands - especially the Experia V8. I'm not sure quite where it is in the firmware or settings, but it seems like it's telling the PC's network cards to consider ALL addresses that end in .255 as broadcast addresses, with the result that such traffic destined for these targets will NEVER be routed, and instead just 'yelled' across the local LAN, where, of course, it will never find its target.
You can test this yourself by doing some traceroutes (tracert command in Windows command prompt) and attempting to trace to a site that you know works, and then trying again with the last digit set changed to .255. The 'working' trace will show your own router as the first hop (usually less than 1 microsecond response time), and the second hop being your ISP's border router. And then a bunch of other hops, to the target. The 'bad' trace with the .255 will show nothing except a load of 'response timed out' lines, and absolutely nothing heard back from even your local router. This is because those packets are all being transmitted as broadcasts on the LAN, not as routed traffic to the default gateway (the router), destined for the internet.
So... one fix is to either update your router firmware (if such an option is available), or find the setting in the router which causes this (which may not be possible if it's buried deep in a flawed set of DHCP config code), or get a newer or just different router that doesn't have this bug.
The other fix is for us to change our TS server's ip address so that it doesn't use .255 as its IP address ending. And that is what we have now done*, just because we love you. Use
ts.roleplay.co.uk to reach us on, and the DNS magic will handle the new IP address automatically.
The TS change won't solve your local config problem or fix your dodgy router, but it will at least mean you can access our TS server again and cry about your crappy router to anyone who'll listen.
If you get fixed by tonight's IP address change, please do post here and let us know.