1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Unusual Network Configuration Presents Problems

Discussion in 'Networks' started by questorfla, Feb 8, 2013.

  1. questorfla

    questorfla New Member

    2
    0
    1
    Hi:
    I gather this board is in the UK. I have tried many in the US and gotten nowhere and sort of tired of asking but I figure maybe someone on the other side of the Pond can come up with a solution. Or rather a Better solution than i have as it is tedious at best and not very "Right", if you know what I mean.

    The issue began when we <upgraded> from Server 2008R1 to R2. Actually, just to remove any doubts, it was a new system, clean install.

    Everything went very smoothly all the way up to the part where you create the VPN's for the Users Outside Access. VPN worked Mapped network drives... Sometimes.

    I will save a lot of time by telling you after many months of trial and effort and questions I finally was able to prove that the cause was indeed a part of Windows itself. R2 uses Port 445 on almost every MAPPED network share. Maybe ALL of them, I am sure someone here knows far more than I and it took me seriously months to even be able to prove this.

    The result is that anyone using an ISP who BLOCKS port 445 (anyone remember that famous worm that used that port?)

    Anyway some ISP's DO block it. If blocked, the VPN still connects just fine. But
    the user cannot access ANY mapped resources. I.e.: If I share a folder with totally everybody having all access, it won’t map.
    I was able to prove my theory by having the same user go to a different location to connect to a different ISP and.. Yep.. The drive mapped perfectly.

    There is and was NO indication whatsoever that this was being caused by a port being blocked. I had to find that by trial and error because the Program which needed to access that mapped drive.. a SQL database program. The program ran just fine. It was not using any "mapped" resources and routes through a port somewhere in the 2000 range.

    So it had no problem Opening on that same system. And would run fine. No errors. But when the user pulled up a record that referenced data on the Mapped Drive Letter... No Go. Drive Letter has red X. Will NOT map.

    Solution: I found several. None easy.

    Currently the BEST of the bunch was to load another system with the Old Server 2008R1 software, create those users who could NOT map a drive letter on the R2 VPN connect to the R1 for the data and also the R2 for the program. Then mirror-sync the same resources on both servers. Extremely complicated and most people here don't even believe I am doing it. But...

    Of course, this worked perfectly which just went further to prove my point that it WAS a change Windows between R1 and R2 (as we all know there were a lot more than just that) But this was an almost unknown side-effect. No one i could find would agree with me. Yet No one ever has yet been able to do it any other way than what I say above.

    Tonight, as I was syncing the resource folders between the two servers, I happened to think that there should be a way to allow the users to map Directly Thru rather than me having to constantly sync. If I can connect Server R1 to Server R2 with a VPN ( I have to do it that way as they are on totally different ISP's as well as network paths.. I am open to any other methods to do this but they must stay configured as they are. I am sure if I put them both on the same ISP it would be a lot easier)

    Anyway. Sorry. If I can go to server R1 and map a drive letter to the shared folder on Server R2 while Inside the server room (no Port Blocking Here :D

    Why can't I just have the users who MUST continue to connect to R1 because r1 doesn’t care about port 445 (or rather it used to be optional I think)
    Map directly through to the folders on the R2 server? Since I can do it ON the R1, I know the path is clear. The problem is that after the VPN connects to the R1, I cannot figure out how to point it on through to the R2.

    I hope this wasn't too confusing. An even Better solution would be a way to beat the port 445 problem. One User actually signed up for Business service at his house (Of course, no problem, no blocking if you pay for business. By that time I was pretty sure I knew what was going on). Another User can connect their cellular router another goes direct through their cellphone but any way to get around the 445 block is what it takes. OR using R1 which did not Require it..

    My last thought was to find out if there was a way to reroute the traffic windows 2008R2 needs on port 445 onto another port. But I have not found a way to do that. Any takers on that one?
    Then I could go back to using just R2 on a single server.

    PS: Don’t ask why I can’t move the SQL program over to the R1 Server. I already asked for permission.
    Was told it was “unnecessary back-pedaling in face of continuing software improvements” (ie: Server 2012)

    Any and ALL communications gratefully appreciated.
     
    Last edited by a moderator: Feb 8, 2013
  2. danielno8

    danielno8 Gigabyte Poster

    1,305
    48
    92
    I am not sure what VPN you are using - but why can the ISP see the traffic to block it? In a VPN, the clients traffic (destination port 445 in this case) would be encrypted, therefore the ISP should not see traffi destined to port 445, and wouldn't block it.
     
    Certifications: CCENT, CCNA
    WIP: CCNP
  3. SimonD

    SimonD Terabyte Poster Moderator

    3,463
    397
    199
    445 is the common SMB port required for network access to windows shares and will be needed.

    As far as your VPN is concerned tho, it shouldn't matter what protocol you're using internally (445, 80, 1433 etc) because that would be encrypted and tunnelled.

    I would be more interested in your Networking configuration at your Firewall than any internal LAN config at the moment because it may well be that the correct routes from your VPN IP network haven't been configured correctly to communicate to your Windows shares.

    Of course it could also be that your end users have something on their home routers that drop VPN packets as well.
     
    Certifications: CNA | CNE | CCNA | MCP | MCP+I | MCSE NT4 | MCSA 2003 | Security+ | MCSA:S 2003 | MCSE:S 2003 | MCTS:SCCM 2007 | MCTS:Win 7 | MCITP:EDA7 | MCITP:SA | MCITP:EA | MCTS:Hyper-V | VCP 4 | ITIL v3 Foundation | VCP 5 DCV | VCP 5 Cloud | VCP6 NV | VCP6 DCV | VCAP 5.5 DCA
    WIP: VCP6-CMA, VCAP-DCD and Linux + (and possibly VCIX-NV).
  4. Sparky
    Highly Decorated Member Award

    Sparky Zettabyte Poster Moderator

    10,191
    296
    319
    I would agree with this as well.

    To the OP - I have migrated most of my customers onto SSL based VPN products which seems to get around any weirdness on home router setups.
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) Security+ Network+ A+
    WIP: Exchange 2007\2010
  5. Plant Guy

    Plant Guy New Member

    2
    0
    1
    What VPN method are you using? i.e. L2TP, PPTP, etc.

    I was also under the impression that port traffic was encrypted during transmission over the ISP.
     

Share This Page

Loading...