1

I have 2 offices which are literally across the road from each other which I have 1 DC at in each office. We have setup a VPN site link between both DC's via RRAS. I have setup DFS-R and have got Group policys all up to date with serving each clients at each locations.

DFS-R copies files from Site A in real time over to server at site B and clients at site B see changes in about 1 minute (Obv. dependent on file size) but this works for us. Clients can cross the road, login and get their files in either site.

The issue I am having now is that I want to share printers.

I could just deploy the printers as I have done in each site via group policy however clients at site B (on 192.168.0.0) cannot ping printers on site A (192.168.1.0) hence can't print to them.

Both servers can ping each other, printers and clients on the other site just the clients at either end of the servers cant ping anything else except those in their own site.

I have a funny feeling its something to do with DNS and NAT possible but after setting all this up I have now stepped out of my comfort zone.

Any help would be much appreciated.

Thanks in advance.

weazel91
  • 49
  • 5
  • It's probably not NAT or DNS. Do the printers have a Default Gateway configured in their network configuration? If not, then they won't be reachable from a different subnet. – joeqwerty Apr 27 '15 at 11:57
  • Yes they do. Ip of one is 192.168.1.6 subnet 255.255.255.0 and gateway of 192.168.1.1 – weazel91 Apr 27 '15 at 12:08
  • Should my clients which are connected to server2 in site B be able to ping clients which are connected to server1 in site A if server1 and 2 have a VPN between them? – weazel91 Apr 27 '15 at 12:13

1 Answers1

0

After further discussion, the situation is that server A in site A makes a VPN connection to Server B in Site B allowing server A to access Site B's resources. Server B does the reverse.
The VPNs are established using RRAS

The correct solution here would be to configure RRAS to use LAN and demand dial routing, and then set up a Demand Dial interface on each server which will connect both networks together with the servers handling routing between.

Since the default gateway for the clients is currently their ISP router, it will be necessary to either change the default gateway to the local server's address, or add a route to the client machines so that they can route the remote network via the RRAS server in the local site.

ChadH360
  • 404
  • 2
  • 3
  • Hi Chad, I don't have any Cisco routers. All my VPN is done through open ports on BT hubs and RRAS from server to server in both sites. We, at present, have no means of acquiring any. Everything however is working how it should at present. When the VPN is up server to server I can add a printer on Server2 and print to the printer in Site A which server1 is connected. The only issue is the clients connected to Server2, they can't. When the VPN is up should clients be able to ping other clients in the other site? As at present it only looks to be the server that can. – weazel91 Apr 27 '15 at 12:52
  • Ah - OK. I suspect it is a routing issue then. Can I ask a small favour - can you run a tracert from a client machine in Site B to the server in Site A. Can you also run a tracert from a client machine Site B to the printer in Site A. I just want to get an idea of how you are routing traffic from one network to the other. I assume you have your router as the default gateway, and clients will not know to route to the other network via the VPN on the server. – ChadH360 Apr 27 '15 at 12:59
  • Tracing route to 192.168.1.6 over a maximum of 30 hops 1 * BS1-PC.*DOMAINHIDDEN* [192.168.0.6] reports: Destination host unreachable. Trace complete. I get the exact same response for any trace route. I do have the router set to the default gateway and I completely understand that the client and router can't pass through the VPN tunnel without knowing where it is... How's best to solve this? – weazel91 Apr 27 '15 at 13:04
  • By the way - did you set up a Demand Dial interface in RRAS with routing configured? It would be helpful if you could be specific about your RRAS configuration. The correct method here would be to set up a Demand Dial Interface on each side with details about the remote network. You would then need to add a route to the client machines (via group policy would be best) eg in the 192.168.0.0 site - route add 192.168.1.0 mask 255.255.255.0 192.168.0.x (where x is the IP address of your RRAS server). For the printers, just set the default gateway as the RRAS server in the local site – ChadH360 Apr 27 '15 at 13:06
  • Thanks for the traceroute. I have a much better idea of what's going on now, but let me just confirm I understand correctly. Server A make a bog standard VPN connection to Server B and can access everything in Site B. Server B does the same. Apart from the servers, nothing else can access anything in a remote site. Is that correct? See my comment above about adding a demand dial interface and setting up routes on client PCs. That's what you want to do here. – ChadH360 Apr 27 '15 at 13:10
  • I've edited the answer to be more specific to your situation. You can quite easily do what you need to do, but just need to configure RRAS at both ends accordingly. – ChadH360 Apr 27 '15 at 13:20
  • Hi Chad! That is correct. I have 1 demand dial setup with the remote networks details set up in that. I am currently making another one just now, so technically both should be dialing into each other? Correct? – weazel91 Apr 27 '15 at 13:23
  • You don't have to have one at each end, but if you do, it means that either server can establish the connection. Also, by setting one up at the other end, it will ensure that all of the necessary IP routes are present. As you have the demand dial interface in place already, the final step to get the client machines working is to make them aware of the correct ip route. There are two ways to do this: 1) Set the default gateway of all clients to the local RRAS server. This is the quickest/easiest method, but means all internet traffic is going through your RRAS server..... – ChadH360 Apr 27 '15 at 13:27
  • Which aint ideal... Or the alternative? – weazel91 Apr 27 '15 at 13:27
  • The second option would be to add routes to the client machines. From a DOS prompt, you could run (in the 192.168.1.0 network) route add -p 192.168.0.0 mask 255.255.255.0 192.168.1.x (where x is the RRAS server). You would do the same in the 192.168.0.0 network but change the numbers accordingly. The -p option makes the route persistent across reboots. Dependent on the number of clients, you may prefer to roll out the routes using group policy. What this command basically does is tell the computer that anything to 192.168.0.x should be routed via 192.168.1.? (ip address of RRAS server). – ChadH360 Apr 27 '15 at 13:31
  • Based on everything we've discussed, it sounds as though you had everything in place barring this last step. Like I said earlier, for the printers, just change their gateway to the RRAS server. They shouldn't really have internet traffic anyway. By the way, there is a third option! Your ISP router may support IP routing and allow you to add IP routes there. If it does, just do that. That way, you won't need to configure any client machines or printers at all! – ChadH360 Apr 27 '15 at 13:35
  • I have setup a direct dial from both ends and one has connected. I have set the IPv4 settings on a client 192.168.0.6 mask 255.255.255.0 and primary domain of 192.168.0.200 (Server running RRAS) and I still can't ping from that client I just get Destination host unreachable thru a tracert :/ – weazel91 Apr 27 '15 at 13:37
  • Did you run the route add command? What is your default gateway? Primary DNS shouldn't be relevant here for testing as that's for name resolution, not IP routing. Also, you will need to configure both ends for it to work. Configuring one end will allow the traffic to go out, but you need to configure the other end too for it to get back. – ChadH360 Apr 27 '15 at 13:42
  • Working on all you suggested, It's taking me a while. I have set default gateway back to router ip of 192.168.0.1 I have run the route add command but to no success sadly... :/ – weazel91 Apr 27 '15 at 13:58
  • Which machine have you run the route add command on? This needs to be done on a client machine, not the server. From the client machine what happens if you tracert to a client machine in the remote site after you've run the route add command on it? You also need to use the route add command in the remote site for return traffic. So on client machine with IP address 192.168.0.50 (example) you would run route add 192.168.1.0 mask 255.255.255.0 192.168.0.200 (ip address of RRAS). On client machine with IP 192.168.1.50 you would run route add 192.168.0.0 mask 255.255.255.0 192.168.1.200 – ChadH360 Apr 27 '15 at 14:04
  • Assuming I've got the correct ip address for the RRAS servers, this would then allow 192.168.0.50 and 192.168.1.50 to communicate with each other. Obviously, I've used example IP numbers for the client machines, but you should get what I mean. When you've done this on both, run a tracert if it still isn't working and post results here. If that works for you, you just need to do the same on all the other client machines. Don't forget the -p option to make the route persistent otherwise it will be lost after a reboot. – ChadH360 Apr 27 '15 at 14:06
  • Hi Chad, Let me work on this over today and tomorrow then. You've gave me a lot to work on. Quick question though can I run the route add command on the server also? or will that pose issues? As the clients also cant communicate with the server on the other site too – weazel91 Apr 27 '15 at 14:18
  • You won't need to run this on the server as the necessary routes should already be in place as part of the setup of the demand dial interface. Running 'route print' on the servers will show you the routing table - you will be looking out for 192.168.0.0 and 192.168.1.0 respectively. The server routes are sorted already - it's the client routes that need to be added, so that the client machines know to send that traffic to the VPN server instead of the default gateway. Good luck with it - I know it's a lot to take in. IP is a complex beast that can take years to understand fully! – ChadH360 Apr 27 '15 at 14:27
  • Awesome, very much appreciated. I think I have an understanding of what needs done so I'll get it tried over the next few days. Cheers – weazel91 Apr 27 '15 at 14:40
  • Good stuff - let me know how you get on, and post back here if you have any queries. – ChadH360 Apr 27 '15 at 15:09
  • Hi Chad. Still having issues. I now have both direct dials working fully and connected. DFS-R working perfectly. I have on my 192.168.0.6 client machine ran route add -p 192.168.1.0 mask 255.255.255.0 192.168.0.200 (RRAS Server) and did a route print and see that the entry is in the route table. I have also set the primary gateway on the client PC to 192.168.0.200 also however when I run tracert from the 192.168.0.6 client I do see that it tries the server 192.168.0.200 however then gives up and then moves on to the BT hub at 192.168.0.1. Now something server side I think but not sure what? – weazel91 Apr 28 '15 at 09:24
  • Yes - sounds server related now. Can you run a route print from the server and post here. I am in a board meeting at the moment, so it my be a while before I can answer – ChadH360 Apr 28 '15 at 09:29
  • No worries. Tracert from server (192.168.0.200) to other RRAS server (192.168.1.2) C:\Users\Administrator.*DOMAINHIDDEN*>tracert 192.168.1.2 Tracing route to *DOMAINHIDDEN* [192.168.1.2] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 * * * Request timed out. 4 * * The server 192.168.0.200 can resolve names however, if I try and resolve \\server it will show me all the shares from the other site. – weazel91 Apr 28 '15 at 09:44
  • Also just found out I can also see shares from \\192.168.1.2 I just can ping now?! – weazel91 Apr 28 '15 at 09:48
  • OHHHH!! Scrap all that. I have now noticed I can resolve by name and not IP from my client machine now... Why is that? – weazel91 Apr 28 '15 at 10:05
  • What is your DNS setup? Could be down to the fact that the client machine in site B can now access the DNS server in site A. Incidentally, with the new setup, firewalls may start being an issue - the local site may be trusted, but the remote site may not be. This could explain why you can't ping, but can browse shares. Obviously pinging is not essential, but is useful for troubleshooting. – ChadH360 Apr 28 '15 at 10:26
  • How should my DNS setup be then? At present each server is running its own DNS service and dealing with its own internal site and I suppose now potentially the VPN connection, unless that is handled within RRAS? – weazel91 Apr 28 '15 at 10:29
  • Personally, I would have an AD integrated zone hosted by both servers. For all machines in Site A (including server), I would set site A DC as primary DNS and Site B DC as secondary DNS. For machines in Site B (including server) I would set Site B DC as primary DNS and Site A DC as secondary DNS. It could just be that RRAS has registered the remote server in the local server's DNS. – ChadH360 Apr 28 '15 at 10:36
  • As the initial query was about sharing printers. If you change the default gateway on the printer, can you now get these to work. You could also set the printer up on the local server and share it. If the remote clients can access the local server shares, they could connect to the printer that way. – ChadH360 Apr 28 '15 at 10:37
  • Hey, As I can now access the shares on site A from Site B I can now add and access printers to deploy them from there, The issue I now have is that DFS-R now isn't replicating. You sort one issue and one follows... I could ping from server to server when the direct dial was made and now I can't. Would this cause the DFS to fail? – weazel91 Apr 28 '15 at 10:51
  • The active routes in serverA (192.168.1.2) has an entry of 192.168.0.0 255.255.255.0 192.168.1.134 192.168.0.214 21 this technically should mean that all 0.0 addresses are being routed through the direct dial, yeh? – weazel91 Apr 28 '15 at 10:52
  • Being unable to ping is probably the cause of DFS-R failing. I believe this will be firewall related now. Try disabling firewall temporarily on both servers to check ping and DFS-R work after that. If they do, modify firewall rules accordingly before re-enabling. What firewall/AV are you using on the servers? – ChadH360 Apr 28 '15 at 10:54
  • It surely can't be firewall related as it was functioning earlier. However I have turned off our AVG and Windows Firewall and still to no avail. My tracert from server to server shows a request time out and the route print from 192.168.1.2 shows 192.168.0.0 255.255.255.0 192.168.1.134 192.168.0.214 21 which looks as though when pinging 192.1680.200 it should go through the direct dial... so why is it not? – weazel91 Apr 28 '15 at 11:00
  • route print looks fine on that side. What does route print from the other server look like? – ChadH360 Apr 28 '15 at 11:04
  • From 0.200 192.168.1.0 255.255.255.0 192.168.0.214 192.168.1.134 11 – weazel91 Apr 28 '15 at 11:05
  • if I do ipconfig from .0.200 I can see the IP given from DHCP to be 192.168.1.134 and I can ping that with full success... I just can't ping 192.168.1.2 and for DNS (I assume) to resolve this through the VPN – weazel91 Apr 28 '15 at 11:12
  • All looks fine there - what's your adapters and bindings order (Network Connections -> Advanced -> Advanced Settings). Make sure your physical adapater is at the top. Try restarting RRAS on both servers and try pinging again. Is there anything AVG related that might still be switched on - packet filter, firewall, etc? – ChadH360 Apr 28 '15 at 11:18
  • 0.200 Wireless Network Connection THEN Local Area Connection THEN [Remote Access connections] 1.2 Local Area Connection THEN [Remote Access connections] And both have file and printer sharing IPV4 THEN IPV6 THEN Client for Microsoft Networks IPV4 Then IPV6 – weazel91 Apr 28 '15 at 11:25
  • I'll restart both... Its just a bit bizarre that a client on 192.168.0.6 can ping 192.168.1.2 through 192.168.0.200 however 192.168.0.200 (RRAS server) can't? – weazel91 Apr 28 '15 at 11:26
  • Yeah - it is bizarre which makes me think it might be some form of firewall/packet filter. Still in this board meeting, but hopefully out in the next couple of hours so I can take a more solid look at this. – ChadH360 Apr 28 '15 at 11:30
  • No worries... I know it is totally unethical and wrong however if you wanna have a look with me sat infront of it I'm sure I could get team viewer onto both servers... Your eyes (and mind) I'm sure will be better than mine! I've just got rid of AVG and stripped things back to bare bones on both servers but nope... still no such luck! – weazel91 Apr 28 '15 at 11:36
  • Can I just confirm current situation. Clients can ping local server and remote server - is that right? Can clients ping remote clients? Local server can't ping remote server by main IP address, but can ping RRAS interface - is that correct? – ChadH360 Apr 28 '15 at 12:53
  • Client from site B can Ping serverB and serverA NOT ClientA. Client from site A can ping ServerA NOT serverB or client B. Servers can't ping other servers or clients. – weazel91 Apr 28 '15 at 13:15
  • Apologies... I am now confusing myself... All clients can ping their own server and the other sites server when the add route command is added. The only issue now is that servers cant ping each other, hence DFSR wont replicate – weazel91 Apr 28 '15 at 13:30
  • Printer issue was solved when comuters could ping the other sites server as that also acts as a print server – weazel91 Apr 28 '15 at 13:31
  • My tracert from serverA to serverB and vice versa shows that it hits the BT hub instead of going through the VPN tunnel... How do you solve that? – weazel91 Apr 28 '15 at 13:47
  • FROM 192.168.0.200... Tracing route to 192.168.1.2 over a maximum of 30 hops 1 1 ms <1 ms <1 ms BTHUB3 [192.168.0.1] 2 8 ms 7 ms 8 ms 217.32.142.195 3 9 ms 9 ms 8 ms 217.32.142.238 4 16 ms 16 ms 15 ms 212.140.206.210 5 15 ms 16 ms 15 ms 31.55.165.181 6 16 ms 16 ms 16 ms 31.55.165.107 – weazel91 Apr 28 '15 at 13:48
  • It sounds like there is something wrong with the routing here. I would be inclined to remove remote access from both servers, delete any routes that correspond to 192.168.0.0 and 192.168.1.0. Restart both servers, and then reconfigure RRAS on both servers. I think earlier you may have added these client routes to the one or both of the servers by mistake, and I wonder if this is causing an issue now. – ChadH360 Apr 28 '15 at 14:24
  • Hi again Chad. I've left it just now as I was tearing my hair out. The only issue with that it that users VPN into our main server... I may just tell them that there is a down day and start feom scratch like u suggest. – weazel91 Apr 28 '15 at 15:32
  • I think that's probably for the best. There seems to be some routing issue which I think would be easier to overcome by starting from scratch with it. Like I say, remove RRAS on both, check that all routes have been removed from the servers (use the route delete command if necessary), and then reinstall RRAS with the right configuration. If you continue having issues, I'll set up a test lab with a similar setup and see if I can replicate your problem. Once RRAS is configured, and the necessary routes are added to the clients, everything should be able to ping everything (firewall permitting)! – ChadH360 Apr 28 '15 at 22:19
  • Hi Chad... back at it. I've got RRAS removed on one server at present and is restarting. Out of curiosity what ports should be open... only PPTP through the routers? – weazel91 Apr 29 '15 at 07:26
  • Also when you say firewall permitting what should be allowed through windows firewall? I still have AVG removed. – weazel91 Apr 29 '15 at 07:28
  • Just PPTP through the routers is fine for this. I only say firewall permitting just in case. If you have a bit of firewall software on ClientB1 that only 'trusts' the site B network, then it may have trouble communicating with a client in site A. Just covering all bases - if you have problems to begin with, turn off the firewall. If that fixes it, configure the firewall accordingly. No need to worry about that just yet, though. Let's get the infrastructure in place first. – ChadH360 Apr 29 '15 at 08:04
  • Ok... So I have RRAS both setup in either side of the servers and I am again back to square 1. Clients can only ping their own servers and servers cant ping other server (Even with the route added on the client machines and NOT the server machines) – weazel91 Apr 29 '15 at 09:07
  • Did you create the Demand Dial interface on both sides? Did you add a Static Route whilst going through the wizard? Can you go to the IPv4 static route section of RRAS and let me know what's there on both servers. If there is nothing there, add the necessary routes using the demand dial interface. I suspect this is what's missing - it would normally be added as part of the wizard, and I have assumed it has been. – ChadH360 Apr 29 '15 at 09:25
  • Demand Dial setup on both sides, yes. I did yes. Server 192.168.1.2 has IPv4 static route of destination - 192.168.0.0 subnet 255.255.255.0 gateway none and IPv4 static route of destination 192.168.1.0 subnet 255.255.255.0 gateway none. – weazel91 Apr 29 '15 at 09:39
  • I have a funny feeling something is working as if I try to remote desktop into the server (192.168.0.200) from (192.168.1.2) it does ask for a username and password however then seems to time out – weazel91 Apr 29 '15 at 09:45
  • After leaving things a while to settle clients can again ping other servers both ways... just servers cant get to other servers. – weazel91 Apr 29 '15 at 09:51
  • ALSO... if I go to serverB (192.168.0.200) and type in \\serverA into search I get the shares in serverA if I go to ServerA (192.168.1.2) and type in \\ServerB I get "Windows cannot access \\ServerB" Strange that I can't ping from server to server however 1 server can access shares. – weazel91 Apr 29 '15 at 09:54
  • If you ping server a from server b, what IP address do you get? 192.168.1.2 or 192.168.0.xx? Is the demand dial interface showing as connected from both sides in RRAS? If not, what happens when you manually try to connect? Are you sure there are no firewalls on any of the servers? Is there anything in the event logs? – ChadH360 Apr 29 '15 at 10:02
  • It's either firewall, or possibly only one side of the DD interface is connecting – ChadH360 Apr 29 '15 at 10:03
  • Route print from each server https://www.dropbox.com/s/b3qutswlxky5ydn/routeprints.png?dl=0 pinging serverA from serverB gets ip address of 192.168.1.2 demand dial is connected both ends see link. PPTP is open on both routers and all firewalls are down – weazel91 Apr 29 '15 at 10:05
  • https://www.dropbox.com/s/hxq14dpsrajglse/ping.png?dl=0 There is the ping result also – weazel91 Apr 29 '15 at 10:09
  • Thats what I would have thought but all firewalls are down and both DD are connected as seen in the image above – weazel91 Apr 29 '15 at 10:11
  • I take it back! My apologies sincerely! Damn firewall! :@ Wild bloody goose chase! I never disabled Public firewall, only domain *facepalms* o.O I do apologise! – weazel91 Apr 29 '15 at 10:14
  • Gotta love firewalls! So did that fix it then? I'm surprised public firewall came into play though as I assume all these devices are on the same domain. – ChadH360 Apr 29 '15 at 10:16
  • It has indeed. I am just having a little issue with DFSR however I think that is a time issue, might have to play the waiting game on that one. They are on the same domain as both servers were in the same building before they got moved. – weazel91 Apr 29 '15 at 10:23
  • Great news! Assuming that all client machines can now access both servers, do you still need to use DFS-R? Obviously depends on link speed, but you could have users accessing files over the link removing the need for duplicating files on both sides. Final step is to tighten up your firewall without restricting traffic over the demand dial interface. – ChadH360 Apr 29 '15 at 10:42
  • Will have a look at firewall when all is setup. Correct! However as we have no other means of backup DFSR to our other server is VERY preferable... and since all the data is backed up there then it may as well be accessed from there by all clients connected in the other site. However running DFSRdiag replication state is showing 0 connections even after recreating the connections in DFS :( – weazel91 Apr 29 '15 at 10:47
  • https://www.dropbox.com/s/zh74qeu5fvvjqkz/DFSR.png?dl=0 Connections are made in DFS and not replicating... I have added a few files to make sure replication should happen as I understand all files are already replicated. The replication is set to full for every hour of every day so should be replicating. – weazel91 Apr 29 '15 at 10:50
  • DFSR is not really my area of expertise - I've not really had enough experience with troubleshooting it. Take a look [here](http://serverfault.com/questions/556568/dfsr-not-replicating) and see whether the dfsrdiag command helps. There is also mention of a 'stale namespace'. With the network changes, this could have something to do with it. – ChadH360 Apr 29 '15 at 11:04
  • Cheers, I have realised my 2 servers are in the same site... not quite sure where DFS pulls this from as in sites and services they are in separate sites. Hmm... – weazel91 Apr 29 '15 at 11:07
  • Might be worth having a look in your DNS servers and see what A records there are for your servers. It could be that RRAS has registered a remote server with a local address in DNS which has confused DFS. You should be OK to just delete any erroneous A records - check the forward and reverse lookup zones. Failing that, probably best to open a new question. – ChadH360 Apr 29 '15 at 11:14
  • Hey again Chad. Yeah it had however that and flushing DNS still hasn't solved my issue. Damn! I'm so nearly there aswell! Haha! Might need to be another question! – weazel91 Apr 29 '15 at 11:39
  • After deleting the erroneous a records, Did you clear the cache on your DNS servers as well as using ipconfig /flushdns on the servers? Possible that DFS might need a restart afterwards as well. But yeah - that's about as far as I can help you with DFS I'm afraid, so may need another question. Please keep me updated though - I hope you get it working soon. – ChadH360 Apr 29 '15 at 11:44
  • Hey Chad. I had the direct dial up and running and sorted out the firewalls on both ends. I was having severe trouble with DFS but I have now got a bigger issue being that I have accidentally deleted the _msdcs entry in DNS and now cant recreate it... this your area? – weazel91 May 03 '15 at 19:31
  • I'm out at the moment and so can't confirm, but I'm fairly certain if you run ipconfig /registerdns on your domain controllers, that should rebuild those entries. Failing that, try restarting (i think) the netlogon service on the DCs, or reboot them. – ChadH360 May 03 '15 at 20:30
  • Good stuff - did you manage to get the DFS issue sorted? – ChadH360 May 03 '15 at 20:33
  • Not as of yet so I have tried removing the other DC and am trying to add again via DCPromo but I cant get it to join now :/ ive pointed it to the dns server of the other server however its throwing up a dns issue... :( – weazel91 May 03 '15 at 21:06