Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Given is an office connected to headquarters using a RRAS bridge (2 virtual machines using RRAS to route between the two networks).

Naming:

The office is A, the RRAS on A is a-lnk. THe headquartters is B, b-lnk the RRAS machine there.

The VPN works perfectly - machines can ping and work between the sites. Domain controllers on both ends replicating, DFS working, remote desktop working. All in all... everything is fine.

EXCEPT: a-lnk itself can not reach any machine in B. This would normally not be troublesome (noone ever does anything on a-lnk), but there are two exceptions: * a-lnk is supposed to get it's license from a KMS in B, so not being able to reach B means it is not prolonging. * a-lnk is supposed to pull updates from a WSUS in B - and not being able to reach B means - no updates.

Given that thigns work (and security is a minor issue - A-lnk is not reachable from the internet as it is behing a NAT hardware anyway) this got not handled for months. I just wan to get this item ticked off now.

Anyone an idea what this is? It definitely is not a "dns does not work" or "routing in general is bad" item, as any computer in A can connect to any computer in B, and the other way arount - only the RRAS computer itself seems to do something really awkward.

Platform for both: 2008 R2 standard.

share|improve this question
    
Single network adapter rras? Or are a and b on separate adapters? –  Greg Askew May 14 '10 at 9:46
    
Separate adapters in all cases. –  TomTom May 21 '10 at 7:20
    
Does B-lnk have the same issue accessing machines on network A? –  techieb0y May 22 '10 at 12:43
    
yes, although I can connect to b-lnk via remote desktop from a machine in A. a command line in B-lnk does get timeouts trying to ping various computers in A. –  TomTom May 22 '10 at 13:11

3 Answers 3

Start with the basics.

Run a tracert from a-link to a host in site B and see what path the tracert takes.

What is the DG for a-link?

Does a-link have any static routes for site B?

share|improve this answer
    
* the tracert times out on the first element with only "*" shown, no name (Request timed out) * What is DG? * Yes, it routes basically the complete network at B over to B-lnk. This obviously works - as the machines in A can reach them etc. –  TomTom May 15 '10 at 10:36

Try to add to alink a route to reach blink, and vice versa.

Alink = 10.1.1.0/24, gw 10.1.1.254
Blink = 10.1.2.0/24, gw 10.1.2.254

alink = route add 10.1.2.0 mask 255.255.255.0 10.1.1.254
blink = route add 10.1.1.0 mask 255.255.255.0 10.1.2.254

share|improve this answer
    
Routes from A to B and vice versa obviously already exists, as all other computers in A and B can see each other. THis is where things get funny. I have about a dozen computers on each side, and they happily see each other. –  TomTom May 22 '10 at 7:40
    
Do the servers (like wsus) have a route to the machines in A and B link? From wsus, can you ping A or B machines? –  Pier May 22 '10 at 11:02
    
From machines in A and B I can ping other machines in A and B in various combinations. It is ONLY on A-lnk and b-lnk that things do not work - this is, obviously, why the problem was on the backburner for a long time - the network link works perfectly for anything EXCEPT the routers themselves. Domain controllers replicate, file servers are reachable, WSUS updates. –  TomTom May 22 '10 at 13:12
    
Which kind of vpn is that? Ike, sstp or pptp? –  Pier May 22 '10 at 13:50
    
PPTP - if that does make a difference. –  TomTom May 27 '10 at 8:18

Since you say these machines both have dual NICs and that the problem is symmetric, I'm thinking that there's an issue with the default source IP when connections originate on the VPN gateway machines. The simple test case would be pings from both addresses (watch for firewall policies blocking pings, of course); the interface on network A should work while the interface to your NAT gateway (carrying the crypted side of the tunnel) is probably the one being chosen, and hence fails. Sadly, you can't select the source IPv4 address in standard Windows ping; you'll need a third-party tool to test this hypothesis.

share|improve this answer
    
And even then this has not helped ;) –  TomTom May 27 '10 at 8:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.