Ports Blocked?

[helpint]

Hi. I have been using VM for years and up to 3 days ago I was able to connect to my Exchange Server using Outlook without any trouble. I have static ports 5000-5005 on my Exchange. If I look at my firewall at the remote end, there is nothing getting there apart from port 135 from my IP address. A few others that also use VM are having the same issue.

Have VM started to block ports and is there anyway I can actually see if it's true?

Thanks


Rich

[Toto]

Hi. I have been using VM for years and up to 3 days ago I was able to connect to my Exchange Server using Outlook without any trouble. I have static ports 5000-5005 on my Exchange. If I look at my firewall at the remote end, there is nothing getting there apart from port 135 from my IP address. A few others that also use VM are having the same issue.

Have VM started to block ports and is there anyway I can actually see if it's true?

Thanks


Rich

No port blocking on VM side,what does your local firewall say?

[AbyssUnderground]

VM don't block any ports, except for a few like NetBIOS and other ports that common widespread trojans might use.

[webcrawler2050]

I would expect this is your local software firewall or if you have a router, then it will be that.

[helpint]

I'll have a look when I get home. Thanks.

[helpint]

I cannot telnet to the server on TCP 135 and I think this is required for Outlook/Exchange. All other ports appear to be OK. I can't see that this is blocked my end. Anyone have any thoughts on this?

[Toto]

Where is the exchange hosted?

[helpint]

In a datacentre that I have full control of.

[dev]

135 outgoing is being blocked here, tcptraceroute stops at the CMTS (going off the hostname). As far as I know, 135/139 have been blocked incoming for sometime, 135 outgoing is news to me.

[helpint]

What can be done? Anything?

[dev]

Change ISP?

Use a VPN? (eg OpenVPN)

Ask VM to unblock it for you? (unlikely)

[token]

RPC over HTTP.

[altis]

135 outgoing is being blocked here, tcptraceroute stops at the CMTS (going off the hostname). As far as I know, 135/139 have been blocked incoming for sometime, 135 outgoing is news to me.

Since 2004, at least:
http://www.theregister.co.uk/2004/06/11/ntl_port_blocking_plan/

[dev]

Since 2004, at least:
http://www.theregister.co.uk/2004/06/11/ntl_port_blocking_plan/

To me, that only suggests inbound which is what I said.

[helpint]

RPC over HTTP.

Doesn't that require having to enter your password every time you connect?

[Toto]

Change ISP?

Use a VPN? (eg OpenVPN)

Ask VM to unblock it for you? (unlikely)

There's nothing yo unblock though is there on the VM side, as they don't block any other ports other than those listed in the Reg article above.

---------- Post added at 20:57 ---------- Previous post was at 20:56 ----------

What can be done? Anything?

What does your hosting company say?

[helpint]

I am the hosting company! Everyone that connects to this Exchange Server has no problem apart from those on VM broadband. I can happily telnet out on Port 135 from everywhere apart from VM. I presume this is the issue as none of the other ports that we use on this server are blocked.

[Paul]

Why dont you just use exchange outlook web access ?

http://en.wikipedia.org/wiki/Outlook_Web_Access

[altis]

Mrs A has to use that for her PGDE course. It seems very flakey and is the cause of much irritation!

[Paul]

I use for my work email from home, and have never had any issues with it.

[altis]

I guess it's possibly more to do with the implementation in an academic environment.

[helpint]

Can't really use Outlook Web Access on a long term basis. It's ok for when you're out and about but when you are searching through folders and looking at things, it has really got to be Outlook. As I said, this only happened 3 days ago and it coincided with one of the rare IP address changes. I did notice as well that when I did a traceroute, the routers along the way were now virginmedia.net and not the old NTL ones that have been used up to now. Wonder if they have changed things without any notification.

[Hugh]

I guess it's possibly more to do with the implementation in an academic environment.
We use in our academic environment, with 3500 staff. ;)

Only issue our Profs/Readers/etc have with it is they can't put a delay on the message, otherwise no problems (and I use it all the time).

[Toto]

Can't really use Outlook Web Access on a long term basis. It's ok for when you're out and about but when you are searching through folders and looking at things, it has really got to be Outlook. As I said, this only happened 3 days ago and it coincided with one of the rare IP address changes. I did notice as well that when I did a traceroute, the routers along the way were now virginmedia.net and not the old NTL ones that have been used up to now. Wonder if they have changed things without any notification.

The changing from ntl to virginmedia.net would be a naming convention change, nothing more I suspect.

When you say a rare IP address changes, are you referring to your IP address changing?

[helpint]

The changing from ntl to virginmedia.net would be a naming convention change, nothing more I suspect.

When you say a rare IP address changes, are you referring to your IP address changing?

Yes, my IP address doesn't change very often but this problem coincided with one.

[Ignitionnet]

Just so that I can get a grasp of all this, you have an Exchange server with RPC, etc, facing the public Internet, is that correct?

---------- Post added at 23:46 ---------- Previous post was at 23:43 ----------

I am the hosting company! Everyone that connects to this Exchange Server has no problem apart from those on VM broadband. I can happily telnet out on Port 135 from everywhere apart from VM. I presume this is the issue as none of the other ports that we use on this server are blocked.

Yes VM block 135 bidirectionally, this affected you when you switched DHCP servers at VM, which caused your IP change along with providing a new config file to the modem which contained these filter statements - have you considered putting the server behind a firewall with an OpenVPN SSL VPN or similar terminating on the firewall as a route to the internal subnet, your present setup is somewhat risky, exposing those services to the public network.

Ideally just have port 25 reachable from outside via static NAT on the firewall so that SMTP works, and have the other services non-mapped and only reachable from the RFC1918 subnet and hence the VPN.

[helpint]

I can use a VPN and this works fine for me but the Exchange Server is also used for hosting clients domains and they require access without the need to create VPN's. I guess I may have to go down the route of RPC over HTTPS but it's a pain having to enter your password each time. Thanks for the reply, most useful.

[Toto]

Just so that I can get a grasp of all this, you have an Exchange server with RPC, etc, facing the public Internet, is that correct?

---------- Post added at 23:46 ---------- Previous post was at 23:43 ----------



Yes VM block 135 bidirectionally, this affected you when you switched DHCP servers at VM, which caused your IP change along with providing a new config file to the modem which contained these filter statements - have you considered putting the server behind a firewall with an OpenVPN SSL VPN or similar terminating on the firewall as a route to the internal subnet, your present setup is somewhat risky, exposing those services to the public network.

Ideally just have port 25 reachable from outside via static NAT on the firewall so that SMTP works, and have the other services non-mapped and only reachable from the RFC1918 subnet and hence the VPN.

I thought it was inbound only? Does it work across both legacy networks?

EDIT: OK, not sure it is bidirectional, my router log shows an access attempt on port 135.

Saturday July 18, 2009 06:30:56 Unrecognized attempt blocked from 86.3.*.*:1794 to 86.5.*.* TCP:135

[Ignitionnet]

I thought it was inbound only? Does it work across both legacy networks?

EDIT: OK, not sure it is bidirectional, my router log shows an access attempt on port 135.

Saturday July 18, 2009 06:30:56 Unrecognized attempt blocked from 86.3.*.*:1794 to 86.5.*.* TCP:135

The standardised config files have blocks for RPC (135), Netbios over TCP (139) and SMB (445). Might be more I don't know about.

That you saw that is, well, odd. The most recent config file I saw certainly had that in. Was originally put in by ntl and crossed to Telewest with the DHCP / TFTP upgrades. Same ones that stopped Telewest custs from using SNMP on their modems.

Oddly what you showed there is inbound. This will be where I find out it's outbound only now probably to avoid VM customers being used as bots :D

---------- Post added at 10:22 ---------- Previous post was at 10:21 ----------

I can use a VPN and this works fine for me but the Exchange Server is also used for hosting clients domains and they require access without the need to create VPN's. I guess I may have to go down the route of RPC over HTTPS but it's a pain having to enter your password each time. Thanks for the reply, most useful.

I appreciate it's a pain but I guess it's either that or the VPN solution - exposing RPC, SMB, etc to the public Internet 'in the clear' is a bit of a risky business due to 0-day exploits, etc.

[Toto]

Thanks Broadbandings - good to get your opinion on it.

[dev]

Just to confirm, tcptraceroute going out gets blocked by the 1st VM node on the list (labelled as a cmts), yet coming in it gets to my router fine.

139/445 appear to be blocked incoming still, wasn't 135 inbound only blocked due to sasser/blaster/whichever worm/virus it was? Could have been unblocked inbound now due to the worm not being of much importance now.

[Ignitionnet]

Just to confirm, tcptraceroute going out gets blocked by the 1st VM node on the list (labelled as a cmts), yet coming in it gets to my router fine.

139/445 appear to be blocked incoming still, wasn't 135 inbound only blocked due to sasser/blaster/whichever worm/virus it was? Could have been unblocked inbound now due to the worm not being of much importance now.

Are you sure it's getting blocked by it and that it's not that it's simply not answering dev? Are you seeing a TCP RST from the CMTS?

[dev]

It's just a trace route, if the CMTS isn't answering it won't appear at all. 135/139/445 all stop with the first VM node (labelled as the CMTS) which to me suggests it's blocking it, otherwise it'd continue like a normal trace route.

[Ignitionnet]

Not getting blocked by the CMTS, it wouldn't be answering if it were filtering the traffic itself. There is filtering of some sort on the modems but traffic from the CMTS itself avoids that filter, traffic just routed by the CMTS rather than actually from it doesn't.

[Rik]

We use in our academic environment, with 3500 staff. ;)


We use it in our Leisure/Retail based environment, with over 8500 staff spread over 2 Head Offices and 35 remote sites. :) No problems here.

Beat that :)