Bizzare & Crazy VPN Troubles

[Z D]

Hello,

OK. This is a very strange problem.

The setup:
============
3 servers:
1) multihomed ISA server connected to the internet and internal LAN (LAN IP
range=10.2.1.x)
2) WWW server on the internal LAN
3) VPN (RRAS, PPTP) server on the internal LAN (static pool of IP addresses
assigned=10.2.3.x)

-All servers have ISA set as the DG.

-ISA has a static route entry so that servers on the LAN can reach the VPN
clients on the 10.2.3.x network (the static route forwards everything to
the VPN server for the 10.2.3.x range).

-ISA publishes both the WWW and VPN servers to the external world. This
works perfectly. All servers are windows server 2003.

-I can VPN into the network, obtain an IP on the 10.2.3.x network, and PING
all internal servers on the 10.2.1.x network.


THE PROBLEM:
============
If I try to HTTP or RDP or make any form of connection from the VPN client
onto the WWW server then it just times out, nothing happens. EVEN THOUGH I
CAN PING THE SERVER!!!!

From the VPN server (and all other servers) I can HTTP,RDP,etc with no
problems to the www server.

-From the external world I can HTTP to the www server with no problem.

-ONLY from the VPN clients is where I cant HTTP,RDP,etc to the www server
EVEN THOUGH i can ping it!!



THE BIZZARE PART:
==================
Now the bizzare part: If I physically go to the www box and then ping the
connected vpn client address, a "connection" is then open between the two
machines. While this "connection" is open I can use HTTP,RDP, etc from the
VPN client to the www server. However, if I wait for a while and the
"connection" closes between the two machines then the VPN client again
cannot access the www server.

Is that strange or what??

Its almost as though the VPN client is somehow blocked from initiating
connections to the 10.2.1.x network!?!?!? Is there some sort of setting in
RRAS on the VPN server to fix this?


PLEASE some advice/suggestions/explanation because I'm going crazy here!


Questions:
-Why can I ping the www server from the vpn client but not http/rdp/etc onto
it?
-why does it only work when the www server pings the vpn client in order to
open a connection and then everything works fine.. temporarily until the
connection is closed.


Also: Once the VPN client is connected, it does NOT go through ISA in order
to talk to the www server because it goes direct to the VPN server to the
www server... ISA is not involved and thus nothing shows up in the ISA
realtime monitor.
However, when the www server tries to talk to the vpn client then it goes
through ISA because ISA is the DG and the VPN client is on a different
subnet. Thus the www-->vpn client ping shows up in ISA logs.


Anyways -sorry for the long post. Many apologies. PLEASE HELP!

thanks

-ZD

 

[Z D]

Hi Guys,

Get this: I came up with a workaround but now i'm even more confused:

On the VPN server I added a static route that basically routes all traffic
for the 10.2.1.x network (internal LAN) up to the ISA server.

This fixed the problem. But I DONT UNDERSTAND!?!?!?!

Why cant the VPN server just route the traffic directly to the WWW server?
It has an IP address on that same subnet!!!!

Here's the IP's to make it more clear:
ISA: 10.2.1.1
WWW: 10.2.1.2
VPN: 10.2.1.3 (LAN) & 10.2.3.1(VPN Client's static pool)


So now a VPN client connects and gets an IP of: 10.2.3.99. In order for it
to contact the www server it has to follow this route:
10.2.3.1 (VPN server)
10.2.1.1 (ISA server)
10.2.1.2 (www server)

BUT WHY can't it just do this:
10.2.3.1 (VPN server)
10.2.1.2 (www server)

It shouldn't HAVE to go through the ISA server because the VPN server has an
IP address on the same subnet as the www server!

I'm SOOOOO confused...

*******Does ISA server have some magical powers that intercepts / firewalls
on-subnet communication?? I dont get it, and I dont want to leave this
workaround in place because its inefficient!

please help! thanks :|

-ZD

 

[Terry Liu [MSFT]]

Hi,

I have replied you in the other thread in ISA newsgroup. For your
convenience, I have included it as follows. If you have further concern,
feel free to reply to the original thread. Have a great day!

===============================================
Thank you for posting here!

In order to perform research on this issue, I appreciate you help me gather
following information:

1. The network physical topology.
2. Network MPSReport of VPN Server, ISA Server, and one VPN client.
3. Run TRACERT to trace the route to WWW server, and other servers from VPN
client.

For your convenience, you can download and run the Network MPSReport from
the link below:

http://www.microsoft.com/downloads/details.aspx?FamilyID=cebf3c7c-7ca5-408f-
88b7-f9c79b7306c0&DisplayLang=en

Next, please send them to me at (e-mail address removed) as email attachments.
Hope this helps us to pinpoint the root cause.
============================================

Best regards,

Terry Liu
MCSE 2K MCSA MCDBA CCNA
Microsoft Online Support Engineer

Get Secure! - <www.microsoft.com/security>
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Z D]

Hi Guys

I started doing more analysis and I think I may know what is causing the
problem. Here is what I think:

- When the vpn client initiates a connection to the www01 server, it gets
routed directly to www01 from the vpn server (sbs01). When this happens,
the ISA server (fw01) doesn't know about this communication.

- Now, when the www01 wishes to respond, it goes through ISA server (it's
default gateway) because it is trying to contact the vpn client which is on
a different subnet (10.2.3.x).

- Since ISA doesn't know about the inital communication from vpn client to
the www server, it may think that www01 is responding to a request that was
never asked and thus blocks/denies the connection.

-When I look at the ISA logs, right after the vpn client makes an http
request to the www01 server, I see the following in the log:

Destination: 10.2.3.5 (vpn client IP address)
Destination port: 3426
Protocol: Unidentified Network Traffic
Action: Denied Connection
Rule: (BLANK!!)
Client: 10.2.1.2 (www01 server IP address)
Source network: Internal
Destination Network: internal


- SO, ISA seems to be blocking the response from www01. To test this out, I
changed the DG on www01 from the ISA server to the VPN server. When I do
this, everything works fine!!!

-Also, I guess PING works fine because ISA only cares about TCP protocols?

-Also: As mentioned in my previous email, when I set the route on the VPN
server to go through the ISA server then it works fine because then ISA
knows about the inital request so thus it allows the response.


Anyways - this is just my thoughts on what the problem is. Does this mean
it's a bug in ISA?

Why doesn't it show the specific rule that it used to deny the request?
Under the rule heading in the log, it is just blank!! It does not specify a
rule that was used to block the communication!!

How do I go about telling ISA to enable this communication? I even tried
ALLOW ALL protocols / all networks access rule but that doesn't help, it
still denies the connection and doesnt tell me what rule it used to deny
it!!

PS: NOte: ISA2004 beta2 is used.

Regards,
-ZD

 

[Christian Hagemann]

Hey Z D

do you have the IP-range of the VPN-Clients(10.2.3.X) in your LAT?
So the ISA knows to "trust" these IPs.

Greetings

Christian

 

[Phillip Windell]

Ther is no LAT in ISA2004. It uses "Networks" and the networks are simply
designated internal or external. I'm not sure I like that idea, but that is
what has been done.

 

[Z D]

Actually, "Networks" are not only designated as Internal OR External. You
can define VPN Client Networks, VPN Site-to-Site networks, or other networks
that you define yourself.

-ZD

Ther is no LAT in ISA2004. It uses "Networks" and the networks are simply
designated internal or external. I'm not sure I like that idea, but that is
what has been done.


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

Hey Z D

do you have the IP-range of the VPN-Clients(10.2.3.X) in your LAT?
So the ISA knows to "trust" these IPs.

Greetings

Christian


(LAN
IP THOUGH from
the

setting

in http/rdp/etc
onto order
to