Welcome to ISAserver.org

VPN - Remote Mgmt Issues

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA Server 2004 Firewall] >> VPN >> VPN - Remote Mgmt Issues

Page: [1]

Message

<< Older Topic Newer Topic >>

VPN - Remote Mgmt Issues - 2.Jul.2004 3:44:00 PM

mdframe

Posts: 14
Joined: 29.Apr.2004
From: Richmond, VA
Status: offline

I am working with a tri-legged ISA 2004 installation. I have the external ip, 208.193.8.x, the DMZ card, 172.31.1.x, and the interal card, 192.168.1.x. I am using DHCP and have DHCP Relaying setup on the ISA Server to get the VPN ip's from the internal DC.

I can connect via VPN just fine and I can ping the servers on the DMZ and Internal interface and I can only remotely manage the servers on the DMZ. I know I have remote management setup correctly on all the servers as I have verified it several times. I can connect to any server on the DMZ and I can ping the internal servers and I have the ip address after connecting of 192.168.1.x so I know that is working fine. Does anyone have any ideas of what to look for? I have checked my access policies several times and the policy does show the source as VPN Client and the destination as Internal. Since I have the internal IP address I just don't understand why the connection is being refused. Please HELP!

Thanks,

Matt

Post #: 1

Featured Links*

RE: VPN - Remote Mgmt Issues - 2.Jul.2004 4:07:00 PM

tshinder

Posts: 47663
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Matt,

Did you create an RDP Access Rule to allow management of the Internal network hosts?

Thanks!
Tom

(in reply to mdframe)

Post #: 2

RE: VPN - Remote Mgmt Issues - 5.Jul.2004 6:09:00 PM

mdframe

Posts: 14
Joined: 29.Apr.2004
From: Richmond, VA
Status: offline

Tom,

I guess I didn't since I don't know what a RDP Access rule is. Can you give me a hint?

Thanks,

Matt

(in reply to mdframe)

Post #: 3

RE: VPN - Remote Mgmt Issues - 5.Jul.2004 6:31:00 PM

tshinder

Posts: 47663
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Matt,

You need to create an access rule that allows the VPN clients network access to the destination network where the managed clients are.

HTH,
Tom

(in reply to mdframe)

Post #: 4

RE: VPN - Remote Mgmt Issues - 5.Jul.2004 8:38:00 PM

mdframe

Posts: 14
Joined: 29.Apr.2004
From: Richmond, VA
Status: offline

Oh then yes I do have that defined. I created an access rule that has VPN Client as the source and Internal as the destination allowing all protocols.

(in reply to mdframe)

Post #: 5

RE: VPN - Remote Mgmt Issues - 5.Jul.2004 10:03:00 PM

tshinder

Posts: 47663
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Matt,

Now its just a matter of opening the Terminal Service client app and making the connection. Note that the DMZ network is not part of the Internal network, so you'll need to make a rule for that, or add the DMZ network to the rule you already created.

HTH,
Tom

(in reply to mdframe)

Post #: 6

RE: VPN - Remote Mgmt Issues - 5.Jul.2004 11:31:00 PM

mdframe

Posts: 14
Joined: 29.Apr.2004
From: Richmond, VA
Status: offline

Tom, that's just it, the only network I can remotely manage is the DMZ. I do have a rule included for my internal and DMZ networks but the internal servers just return the message terminal services is too busy while the DMZ servers work perfect.

Do I need seperate rules for each? I currently have the source as VPN Client and the destination as DMZ and Internal. Why would I need different rules for the same thing?

I have rules for the VPN Client to have access to all the networks including the local host and the only access rule that seems to be working is the DMZ. This is very strange. As I said earlier I can ping and receive the correct DHCP address from the internal network once I connect but after that nothing. When I watch monitoring I don't even see the connection try to take place to the internal server when using Terminal Services. At least when I was trying to ping items before I had the rule correct I could see denied message but with this I see nothing.

[ July 06, 2004, 12:38 AM: Message edited by: Matt ]

(in reply to mdframe)

Post #: 7

RE: VPN - Remote Mgmt Issues - 6.Jul.2004 4:34:00 AM

tshinder

Posts: 47663
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Matt,

What are the network IDs assigned to the DMZ segemnt? The Internal network? The VPN clients?

Thanks!
Tom

(in reply to mdframe)

Post #: 8

RE: VPN - Remote Mgmt Issues - 6.Jul.2004 5:36:00 PM

mdframe

Posts: 14
Joined: 29.Apr.2004
From: Richmond, VA
Status: offline

Tom,

Here is the information I posted at the beginning of this thread:

I am working with a tri-legged ISA 2004 installation. I have the external ip, 208.193.8.x, the DMZ card, 172.31.1.x, and the interal card, 192.168.1.x. I am using DHCP and have DHCP Relaying setup on the ISA Server to get the VPN ip's from the internal DC

Thanks,

Matt

(in reply to mdframe)

Post #: 9

RE: VPN - Remote Mgmt Issues - 6.Jul.2004 5:58:00 PM

ClintD

Posts: 1833
Joined: 26.Jan.2001
From: Keller, TX
Status: offline

When you make the VPN connection, is the client behind a NAT device or live on the Internet? If behind a NAT device, what subnet is it on? 192.168.1.x ?

(in reply to mdframe)

Post #: 10

RE: VPN - Remote Mgmt Issues - 7.Jul.2004 3:02:00 AM

mdframe

Posts: 14
Joined: 29.Apr.2004
From: Richmond, VA
Status: offline

Bing, the light goes on!

Yes I am working behind a home broadband system and my network is behind a LinkSys Router/Network with the same sub-net. I guess this means I will have to change the sub-net on either the office architecure or all of our employees across the US, unless you know of a trick that will allow the current sub-net to work?

That's why we test a new architecture isn't it!

Thanks,

Matt

(in reply to mdframe)

Post #: 11

RE: VPN - Remote Mgmt Issues - 7.Jul.2004 4:03:00 AM

tshinder

Posts: 47663
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Matt,

Ha! I always forget about the VPN client address [Smile]

I always assume (mistakenly) that the VPN client is sitting in a hotel room with a "non firewalled" connection so the client has a public address. [Eek!]