Welcome to ISAserver.org

Bizzare VPN troubles... followup.. ISA BUG?

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA Server 2004 Firewall] >> VPN >> Bizzare VPN troubles... followup.. ISA BUG?

Page: [1]

Message

<< Older Topic Newer Topic >>

Bizzare VPN troubles... followup.. ISA BUG? - 16.Apr.2004 6:29:00 PM

Posts: 15
Joined: 15.Apr.2004
Status: offline

Hello,

This is a followup to this post:
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=30;t=000051

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!

Regards,
-ZD

Post #: 1

Featured Links*

RE: Bizzare VPN troubles... followup.. ISA BUG? - 19.Apr.2004 11:35:00 AM

tshinder

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

Hi ZD,

This is getting a bit confusing. Maybe some basics are in order.

1. Are your setting up a ISA VPN server?

2. where is the VPN client?

3. where is the VPN server?

4. How are you assigning addresses to the VPN clients network?

5. Have you confirmed that there is no overlap between the VPN clients network and the Internet network?

Thanks!
Tom

(in reply to ZD)

Post #: 2

RE: Bizzare VPN troubles... followup.. ISA BUG? - 19.Apr.2004 4:16:00 PM

Posts: 15
Joined: 15.Apr.2004
Status: offline

Hi Tom,

My apologies for the confusion.

Here's the physical setup:

3 Servers:

1) ISA server, 2 NIC's: #1 connected to the internet, and #2 connected to the internal LAN (LAN IP=10.2.1.1)

2) WWW server, 1 NIC, connected to the internal LAN (10.2.1.2)

3) VPN (RRAS, PPTP) server, 1 NIC, connected to the internal LAN with 2 IP addresses:
- 10.2.1.3
- Static pool of IP addresses for vpn clients: 10.2.3.x

SETUP
------
-All servers have ISA set as the DG.

- ISA server is PPTP publishing. All VPN requests from the external world hit the ISA server and are directed to the

VPN server (10.2.1.3) which assigns the vpn client an OFF subnet IP address on the range: 10.2.3.x as mentioned above.

-ISA server has a static route entry so that servers on the LAN can talk to VPN clients on the 10.2.3.x network (the

static route routes everything to the VPN server for the 10.2.3.x network). Note: this is referring to INSIDE the 'vpn

tunnel' communications.

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

on the 10.2.1.x network with no problems whatsoever.

TRACERTS:
-------------
To illustrate the network, here are tracerts from the vpn client to the servers:

(vpn client to WWW Server)
tracert 10.2.1.2 -d

Tracing route to 10.2.1.2 over a maximum of 30 hops
1 2 ms 1 ms 1 ms 10.2.3.1 -VPN SERVER
2 1 ms 1 ms 1 ms 10.2.1.2 --WWW server

(vpn client to VPN Server)
tracert 10.2.1.3 -d

Tracing route to 10.2.1.3
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 10.2.1.3 --VPN server

(vpn client to ISA Server:)
tracert 10.2.1.1 -d

Tracing route to 10.2.1.1 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 10.2.3.1 --VPN server
2 1 ms 1 ms 1 ms 10.2.1.1 --ISA Server

THE PROBLEM:
--------------
-The problem arrises when I wish to http (or use any other protocol) to the www server. When I try this, the connection just times out.

-My suspicion is that, INSIDE the tunnel, when the vpn client wishes to communicate with the www server, the request goes from vpn client -- vpn server -- www server.

ISA doesnt know about this initial communication because it was not involved.

- When www server wishes to respond, it has to go through ISA server (its default gateway) because its replying to the vpn client which is on a different subnet.

ISA blocks this because its thinking that the www server is responding to a request that was never made because the original request from the vpn client never went through ISA server... So, maybe this is some sort of stateful-packet protection?

Also, shortly after I make the hhtp request from the vpn client, i notice this in the isa realtime 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

BUT THIS IS NOT A RULE THAT I'VE DEFINED! THE RULE IS BLANK! So what exactly is causing ISA to deny the connection??

Hence the confusion!

Now, a side note:
If I change the default gateway on the www server from the ISA server to the vpn server, then there are no problems!

This (I'm guessing) is because now ISA is not involved at all in the communications back & forth so it cant deny anything.

Maybe this is some sort of default-stateful packet filtering by ISA.... or is it a bug because no Rule is listed in the log?

thanks!
-ZD
PS Sorry for the long post!

[ April 19, 2004, 04:22 PM: Message edited by: ZD ]

(in reply to ZD)

Post #: 3

RE: Bizzare VPN troubles... followup.. ISA BUG? - 19.Apr.2004 8:37:00 PM

tshinder

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

Hi ZD,

I think the problem is the single homed VPN server. AFAIK, this is an unsupported config, at least, I've never supported such a config [Smile]

VPN servers are typically multihomed devices that separate the internal network from external.

So, why not make life a lot easier and configure the ISA firewall as a VPN server? I'm sure there is a fix to this problem, but it would take some NetMon work to see where the problem is.

Is there a reason why you're not using the ISA firewall as a colocated VPN server?

Thanks!
Tom

(in reply to ZD)

Post #: 4

RE: Bizzare VPN troubles... followup.. ISA BUG? - 19.Apr.2004 10:42:00 PM

Posts: 15
Joined: 15.Apr.2004
Status: offline

Hi Tom,

How could the problem possibly be the single-homed VPN server?

Pings/Tracert work just fine!

If I put a static route in the VPN server that forces all routes to the local subnet (10.2.1.x) through the ISA server then things work fine! (this way, ISA knows about communications in both directions).

OR, if I set www server's DG to the VPN server then it works fine too (ISA knows nothing about any communications).

The problem only arises when a request is made to a server that doesn't go through ISA, but the response does go through ISA.

Sounds like ISA server is doing some sort of stateful packet filtering and doesnt allow the response from the www server because it didnt know about the initial request.

*****Why wouldn't it show which rule it used to deny the connection?? is that a bug???

Anyways, to answer your question - I cant use ISA as the VPN server because I need to publish many different PPTP servers on my internal LAN. (FYI each vpn server is in a different AD domain and thus uses a different AD database for authenticaion).

For $$$ reasons I cant put ISA on all the internal servers.

Any suggestions? This is driving me nuts!

thanks

(in reply to ZD)

Post #: 5

RE: Bizzare VPN troubles... followup.. ISA BUG? - 20.Apr.2004 12:19:00 AM

tshinder

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

Hi ZD,

OK, I think I'm getting it [Big Grin]

Yes, if the VPN clients need to access a server, then the server needs to be able to reply to the VPN server, not the ISA firewall, because the VPN server performs proxy ARP for VPN clients, so any requests made via VPN have to return along the same path.

Am I getting close?

Thanks!
Tom

(in reply to ZD)

Post #: 6

RE: Bizzare VPN troubles... followup.. ISA BUG? - 20.Apr.2004 12:40:00 AM

Posts: 15
Joined: 15.Apr.2004
Status: offline

Hi Tom,

Kind of.

I think it's just that ISA server has to know about the request from the VPN client before it allows a response from the server on the internal LAN. Otherwise it thinks the www server is crazy and wont allow/route the connection/communication.

It makes sense for it to work this way to protect servers from the external world, however, what I dont understand is if ISA knows that both of those subnets are INTERNAL then why would it block the response from the www server? It shouldn't be touching any communications on the internal LAN between subnets!

It doesn't even show which rule it used to block it so that I can disable it!

So now the only options I have to fix the problem is:
1) use an inefficient route that forces the VPN server to route everything to the ISA server EVEN THOUGH the vpn server has an interface on the local LAN(10.2.1.x).
This way, ISA server knows about the request from the vpn client and will allow the subsequent response from the lan www server.

2) setup an 'internal' RRAS router that is the DG for all the servers on the network (except ISA). This internal router will not block the responses like ISA does. It will then get the static route that's currently in ISA (forward all communications for 10.2.3.x to the VPN server).

Either way, I'm having to do more work because of ISA. Is this a bug or a real feature?

AND why doesnt it show which rule was used to block the communication? That cell in the realtime log is just blank!

any suggestions? or am I nuts?

thanks [Smile]

-ZD

(in reply to ZD)

Post #: 7

RE: Bizzare VPN troubles... followup.. ISA BUG? - 20.Apr.2004 3:29:00 AM

andifur

Posts: 143
Joined: 25.Oct.2001
From: Eastern PA
Status: offline

Not sure if this might help or not. Keep the DG of the web server to the ISA server. Add a static route of your VPN addresses on your web server with the DG of the vpn server.

I am assuming that you are using /24 subnet with the 10.x addresses? I have seen this before in the well almost same situation. We were using alta-vista 98 vpn and ran into the same issues. By passing the ISA or any firewall seemed to do the trick.

Like I stated, not sure if this is going to help, but it is worth a try.

(in reply to ZD)

Post #: 8

RE: Bizzare VPN troubles... followup.. ISA BUG? - 21.Apr.2004 1:38:00 PM

tshinder

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

Hi ZD,

If I understand your config (which I can't say that I do for sure), the return path is not the same as the send path, and all stateful firewalls require that, regardless if whether the host is on the Internal network or not. So, if a VPN client is making a connection to a web server on the Internal network, the Web server is going to respond to the VPN server, not the firewall. The reason for that is the response returns along the same route it was sent.

HTH,
Tom

(in reply to ZD)

Post #: 9

RE: Bizzare VPN troubles... followup.. ISA BUG? - 21.Apr.2004 10:43:00 PM

Posts: 15
Joined: 15.Apr.2004
Status: offline

Thanks Tom. I realize this now, after hours of debugging. If only ISA had was more descriptive in the realtime-log (instead of the blank reason) then it wouldn't have taken me so long to figure it out!

[Smile]

-ZD

(in reply to ZD)

Post #: 10

RE: Bizzare VPN troubles... followup.. ISA BUG? - 22.Apr.2004 3:09:00 PM