Link to home
Start Free TrialLog in
Avatar of ScorpioUltima
ScorpioUltima

asked on

Port blocking problem

Apologies if this is not the most appropriate area to post this but I have a problem with an SBS2003 network as follows:

Small network (Server & 5 workstations). Brand new Fujitsu server built using mostly the defaults, configured to be an Exchange server, allowed access from the Internet to Ourlook Web Access & RWW - the same as I have setup many servers for other clients. However, in this case the server does receive any communications from the outside world to any of the ports that are open, i.e. I can telnet to port 25 on the server from the LAN but not from the outside world. 1st thought was that the router was faulty (We had already identified another fault with it) so a replacement router (Netgear DG834PN) was installed and configured to port forward ports  25, 80, 443, 1723 & 3389 to the server IP address on the LAN. This did not change the situation though, I still cannot receive mail or RDP onto the server from the Internet, only from the LAN. 2nd thought was that the ISP is blocking the ports that they want to be able to access, unfortunately the ISP (BT)appears to have a technical helpdesk staffed by non nechnical people who simply refer to an FAQ and cannot understand the question :(

If it helps at all, the server *can* send mail to both internal and external recipients, however, the clients only receive mail that originated within the LAN. The router logs show a few connections on port 25 but nowhere near the expected number - i.e. in 2 hours the router showed 2 connections to port 25 but I had sent at least a dozen outbound mails to an autoresponder that I use to test email connectivity. There were no connections to port 3389 showing although I had tried to connect to RDP a couple of times.

Any ideas? Faulty router? ISP Port filtering/blocking? The couple of connections to port 25 bothers me, without those I would be confident that it was ISP port filtering :(
Avatar of Steve Agnew
Steve Agnew
Flag of United States of America image

I would start by making sure that the internal server is the right IP address from the router.. and that you have your external DNS setup right for the domain.  Do an IPCONFIG on the server and then check the router to make sure that you are forwarding the right ports to the right IP internally.  Then go to like www.ipchicken.com and see what your external IP address is and make sure that externally your MX records for your domain point to that...
Avatar of ScorpioUltima
ScorpioUltima

ASKER

Thanks DeadNight, all of those things have already been done, DNSReport shows the correct IP Address as the primary MX record, whatismyip confirms that the IP address is the same as the primary MX record and the server IP matches the IP set in the firewall rules section of the router :(
Why don't you temporarily connect a laptop, or a test unit to the WAN side of the router and try to terminal into your server?  At least you could determine whether your port forwarding is working...

If succesful, then the problem is more likely with your provider..  I would escalate any problems to the highest level support group you can get, possibly to whoever is responsible for their DNS servers..  I have had to do this more than a few times here in the USA, and once I get to talk to the DNS admins, I find that they understand the problems, and have helped in the solutions..
When you ran dslreport, you must have had a faliure then when connecting to the mail server?

re-run the ceiw, any change?
All outbound Internet traffic working OK?
Is the SBS box using two Nic's? One external/1 internal?
If so, how is the external NIC picking up its IP address, static or dhcp from the external router?
On the external router, use the DMZ option and so send all traffic to the SBS box
FE, unfortunately the WAN side of the router is the ADSL port and I don't have anyway to connect to that - actually, I wonder if anybody makes a connector that would allow it, that would certainly make it easy to test!

Keith, thanks for the suggestions. I have already re-run CEIW and it makes no difference :( Outbound traffic is fine. The SBS is using a single NIC. The router is a Netgear DG834PN and I don't *think* there is a 'total passthrough' option - AFAIK you setup and enable the rules on the same page, certainly that's the case with my slightly older version of the same!

Current thinking is that we will move the router/server combo to another office (My office) and test there using a different ISP as that will prove if the problem lies with the ISP or otherwise!
Apologies - forgot to say - yes, DNSReport cannot connect to the mailserver either.
Yea, that would be a problem, connecting to a DSL circuit..  sorry...
ASKER CERTIFIED SOLUTION
Avatar of Keith Alabaster
Keith Alabaster
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Well I removed the server/router to my office and still no joy so the problem is not in the ADSL circuit - I was kinda hoping that it was but ast least now I know it's not! Took the server back to the user and re-positioned it, re-ran the Intenet connection wizard (For the nth time) and bingo it worked! However, my joy was short lived as quitting out of the SMTP conversation and retrying gave me the 'connection could not be estalished' message again. Spent the next hour configuring and reconfiguring the CIEW and RAS and it seems that no matter what combination I try it works occasionally (On one occasion it worked 5 times in a row) but with no consistency. I also noticed that in the main, when I tried to exit the conversation by typing 'quit' it was exiting as soon as I pressed the 'q' key - or any other key for that matter. The occasion it worked 5 times in succession I was able to type 'quit' to exit and then up arrow to bring back my telnet xx.xx.xx.xx 25 command and re-connect. The times it exited from a single keypress the up arrow/return combination was giving me the 'failed to connect' message. On a couple of occasions it failed/failed/failed/failed/worked/failed when all I was doing was pressing up/return :(

One other strange thing - all the PC's and the server are connected to a 16 port switch which is in turn connected to the Netgear. This has been the case throughout. On *one* occasion when I ran the CIEW I got the 'Windows has found the following uPnP device' message - but I ran the CIEW at least a dozen times

If I'm honest, I'm stumped by this one, unless anybody has any other suggestions it's a case of backup the data and re-install from scratch which is not an ideal solution as it may not resolve the problem.
I am stumped also..  rebuilding a server is not something I like doing, but sometimes necessary..  lol, eh?  :)
OK.

Tell me about the server please. How many nics? Settings etc?
Running ISA server?
What else is the server running (besides the standard sbs software)?
Keith - Sorry, already rebuilt it! Herein lies a strange story indeed.....

The server was rebuilt using our standard small business IP addressing scheme (Which works perfectly well with all other clients). Routers start at 192.168.1.1, Servers start at 192.168.1.5, Printers start at 192.168.1.10, DHCP range is 192.168.1.20 to 192.168.1.99 with static devices above that. Subnet mask on all devices is 255.255.255.0

We set up the server (On 192.168.1.5) and 1 PC with the static IP of 192.168.1.100

Ping tests were left running wit the -t switch:

Server to Router - Occasionally (~2%)
Server to PC - Yes - 100%
PC to router - Yes - 100%
PC to Server - Yes - 100%

As before, running the CEIW didn't really make a lot of difference except the server could sometimes ping the router and get 3 or 4 replies before dropping off again. Also as before CEIW *once* told me it had found the uPnP Netgear on the network but most of the time it didn't find it.

In a moment of inspiration (Or madness, I'm not sure which) I changed the router to be 192.168.1.200 and re-ran the ping tests but still got the same results. To complete the testing I left the router at the same address and moved the server to 192.168.1.201 - Bingo! 100% success on ping tests for 5 minutes solid! The router rules were reconfigured to send traffic to the new IP address and the telnet tests were run....Yep, success again.

It appears that for some unknown reason the Server/Router combination would not work with them both at low addresses although the Server/PC PC/Router and PC/Server combinations all work without problem regardless of the addresses.

Strange! From a technical viewpoint I would like to understand why this happened but from the clients viewpoint they just want a working system which I can understand even though it means the answer will probably remain a mystery.

How do I close this and split the points? I would like to allocate points as people did make suggestions as to possible problems :)
Should have added - DHCP has disabled on the Router and enabled on the server all through this so it's not that causing the issues!
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
It's certainly a peculiar one! If I was describing it to somebody now (With the benefit of hindsight) I would say that the server could not communicate very well with a device with a low IP address when it also had a low IP address - it communicates occasionally but not consistently. So that makes more sense then.....not! I did wonder about the router but this was the 2nd one we tried, the 1st one also had the same problem and that was a different make/model. I did wonder about IP filtering at the server but even 'out of the box' it had the same issue before we installed RRAS. As far as the client is concerned he now has a working system so he is happy and I guess that's what counts!
I guess that's what counts!<<  absolutely!

thanks for the split, and have a great week!

FE
Again thanks for the split although I am 'not convinced' on this one.  The value of the ip address is the same whether it be 1 or 254 as fars as an IP address is concerned so I think there is still an issue here 'somewhere' to be resolved...

Time will tell.

Regards
Keith