Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 443
  • Last Modified:

unable to access a windows 2008 server from windows 7 client through VPN

Hi,

We've recently installed a vpn server through Routing and remote access on a Windows 2008 R2 server.
We're able to establish VPN connections just fine and most network access works fine as well. There is one problem though.
If we try to connect to a Windows 2008 server on the network, it doesn't work, but only from a Windows 7 client (windows XP works just fine).
It applies to RDP,  ICMP, HTTP, HTTPS, ...

I've ran Wireshark on the server which I want to access and when I ping the machine from the client, I can see incoming AND outgoing ICMP messages.
But somehow they're not coming back to the client.

From the same client (ie Windows 7) I can however succesfully access a Windows 2003 server that is in the same subnet as the Windows 2008 server.

My VPN connection has IP address 172.21.250.39
Windows 2008 is 172.21.255.95
Windows 2008 is 172.21.255.90

We've disabled ipv6 on the client to see if that makes a difference, but it doesn't.

We're kind of lost right now, so any ideas would be appreciated.

Thanks,

Bart
0
vabict
Asked:
vabict
  • 10
  • 5
1 Solution
 
gicagoCommented:
Can you remote to other clients (win xp) from the win7 machine? Is the problem only over the vpn connection or is it also happening locally on the LAN?

First two things that I can think of is the "Use default gateway on remote network" option in the vpn connection on windows clients. Thats in vpn connection properties--> networking--> ipv4--> advanced. That option (if turned on) routes you traffic to the remote gateway and uses vpn for your internet connection instead of your local network gateway.

Secondly what is the remote desktop option on the the Server?
Go in the computer properties-->remote settings and then try the More secure option ( that will probably prevent win xp users to connect but you can just try it for a couple of minutes )

It probably isnt the second option cause you cant even ping and that is a network issue.

Did you try setting your vpn in the same range as the servers? That is possible only if you can spare the range of addresses that will be for your vpn clients.

Also, do you have a firewall in your network and is the user in the right security group on the server ( like Remote desktop users ). Are you connecting to the vpn with an administrator pass or a user accaunt?  Maybe the answers help someone else if it isn`t the vpn gateway thing.
0
 
Tech SavyCommented:
Could you please post the output of the netmon/wireshark trace from the windows 7 Client machine to the server? for ICMP /HTTP /HTTPS /RDP.
0
 
vabictAuthor Commented:
When the client PC is in the LAN, it is able to connect to the server (which is in our dmz, so it has to pass through the firewall).

Strange thing is that I can connect to a Windows 2003 server (and ping that machine) without a problem even through the VPN. Since both servers are in the same subnet, it would seem strange to me that there's a routing problem (unless Windows 2008 uses different ports for VPN communication?).

I've tried turning of the "Use default gateway on remote network" option on IPv4, but that doesn't help. The only difference is that the server names are not resolved (so no access to the internal DNS), I can still connect to the 2003 server through IP address, but not to the 2008 server.

I haven't tried the more secure option yet, since you're probably right that's not the problem since pinging doesn't work either.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
vabictAuthor Commented:
This is the wireshark log from the server.

There seems to be an issue with the checksum in the reply, but I'm not sure that would be the problem.icmplog.txt
0
 
vabictAuthor Commented:
on the client side I can't differentiate on the different protocols in wireshark. All I see are PPP comp en GRE messages going back and forth to the VPN server. There's no telling what's what.
0
 
Tech SavyCommented:
When i Look at the trace :

When sent:
Ethernet II, Src: Vmware_a9:2e:0b (00:50:56:a9:2e:0b), Dst: Vmware_a9:00:0f (00:50:56:a9:00:0f)
Internet Protocol Version 4, Src: 172.21.250.63 (172.21.250.63), Dst: 172.21.255.95 (172.21.255.95)

When received:
Ethernet II, Src: Vmware_a9:00:0f (00:50:56:a9:00:0f), Dst: CheckPoi_35:4a:bf (00:1c:7f:35:4a:bf)
Internet Protocol Version 4, Src: 172.21.255.95 (172.21.255.95), Dst: 172.21.250.63 (172.21.250.63)

The MAC address is changing which is why your NIC is not picking up the PING response.

When I do a MAC address lookup for this address : 00:1c:7f:35:4a:bf it belongs the following vendor.
001C7F      Check Point Software Technologies

Could you let me know what device is this ?
0
 
vabictAuthor Commented:
That's our router. But in the logfiles on the router I haven't been able to find anything.

I'll see on the 2003 if this behavior is also happening there.
 
I'll have to investigate closer into the firewall loggings then, I suppose...

Thanks!
0
 
vabictAuthor Commented:
I've checked on the 2003 server and the behaviour is different there.

Request
Ethernet II, Src: Vmware_a9:2e:0b (00:50:56:a9:2e:0b), Dst: Vmware_a9:43:c5 (00:50:56:a9:43:c5)

Reply
Ethernet II, Src: Vmware_a9:43:c5 (00:50:56:a9:43:c5), Dst: Vmware_a9:2e:0b (00:50:56:a9:2e:0b)

The windows 2003 doesn't change the recipient and doesn't pass through the firewall.


I've also finally found the packets on the firewall and they are indeed blocked. So now I know how I can solve it, but I'd still like to know why this behaviour is different on a Windows  2008 server and apparently only when coming from a Windows 7 client, not from an XP client.
Do you have any ideas on that?
0
 
Tech SavyCommented:
Its difficult to comment on it. Unless I can go ahead and collect some more information. Most probably I take remote sessions and work on the problem.

Probably I'll have to check how the network is setup how the packet is being routed, take multiple traces then we could sniper shoot the issue. If i comment something now which might look i am throwing a grenade in the dark. I hope you understand my point of view.

Cheers.
0
 
vabictAuthor Commented:
Actually you can forget the coming from windows XP pc, because that's actually not true. I'd been told that by a colleague, but hadn't double checked it, since I didn't have a XP available.
I've just configured on though and the behaviour is exactly the same.

So it's basically an "issue" on Windows 2008, i'll dive into the routing tables of these servers some more.
0
 
Tech SavyCommented:
Take a simultaneous trace. On client and on server as well then post it here.

Also post the output of arp -a

Do you have only router connected between the client and server ? or are there any other devices ?
0
 
vabictAuthor Commented:
Off course I understand your point of view.
I think I can live with solving the problem without knowing why it is happening exactly :-)

I'll change the firewall settings to allow the traffic and we should be fine. Thanks!!!
0
 
vabictAuthor Commented:
When I look in the routing tables of the servers, on the 2003 server the 172.21.250.0 range is present and it's gateway is the vpn server (172.21.250.202).
On the 2008 server, there is no entry on the 172.21.250.0 range, so i suppose that's the problem.
0
 
Tech SavyCommented:
Ok that's great let me know if the problem is resolved or not.

Cheers.
0
 
vabictAuthor Commented:
i've added a route to the 2008 servers and everything works fine now.

Many thanks for leading me in the right direction.
0
 
vabictAuthor Commented:
This pointed me in the right direction. We'd been looking all over the place but we missed that one.
0

Featured Post

Lessons on Wi-Fi & Recommendations on KRACK

Simplicity and security can be a difficult  balance for any business to tackle. Join us on December 6th for a look at your company's biggest security gap. We will also address the most recent attack, "KRACK" and provide recommendations on how to secure your Wi-Fi network today!

  • 10
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now