ISA Firewall client - Authentication issue

I need a view of your layout. Where is the protected server? DMZ or inside?
What users are you talking about? Internal? External VPN? List of source IP addresses?

The protected server sits in the DMZ and the users attemptiing to access it are from the internal network ( Server 2000 AD)

It will be an authentication issue.

Use this link as a starting point assuming the server is a web based service.
What exactly are you seeing in the log when you make the connection attempt?

Keith, let me give you a bit more information on our situation as I realise I have been quite vauge thus far.

We have two networks on our local site, a network that most of the staff use (our "Internal" network) and a secure network with an SQL server we would like our staff to be able to access (our "External" network). We first setup the routing and made a firewall rule allowing all data from "internal" to "external".

This works fine and we can access the external network from our internal network without any problems.

The issue arrises when we start to secure the connection. The first, and most important security feature is user authentication. We created a group on the ISA server and added a test user to it. We installed the firewall client onto an "Internal" computer and it automaticly detects the ISA server. However, we now cannot access the "External" network with the test user.

The ISA server is on the same domain as the test user and when the firewall client is connected to the ISA server the following sessions appear:
Session Type       Client IP                 Source Network   Client Username                           Client Host Name
Firewall Client      *TestComputerIP*  Internal               DOMAIN\TestUser                        *TestComputerName*
SecureNAT          *TestComputerIP*  Internal                                                                 *TestComputerIP*
Firewall Client      *TestComputerIP*  Internal               DOMAIN\*TestComputerName*$   *TestComputerName*

We have tried adding the user to the firewall rule as both a "Windows User" and also using "LDAP" but to no avail.

Thanks very much for your help on this, we are totally stumped at this end.

OK. This is the way I would do this assuming I have your view correct. This is guess work to start with as you habe given me no insight to your environment (servers, locations etc).

                          Internet
                                  |
                            router/adsl
                              192.168.100.1/24
                                  |
                               192.168.100.2/24 (ISA external)
                                  |
                                  |-------------------- 192.168.50.1/24 (ISA Perimeter) ----- 192.168.50.2/24 (SQL Server)
                                  |
                                192.168.10.1/24 (ISA Internal)
                                  |
                     -----------------------------  Internal LAN with DC's etc

open the gui
select configuration - networks
Select network rules
change the rules so that 'internal and perimeter' are routing between each other, not using NAT
change 'perimeter to external' to NAT instead of routing

select firewall policy
click the last icon on the right at the top of the screen (this toggles on/off the system policy rules).
Amend all the options as necessary so that rpc, ladp, kerberos, dhcp etc are allowed between internal and perimter.
crette a new access rule allowing all protocols FROM internal, local host and perimter TO internal, local host and perimter.
Apply the policy.

This now gives you a scenario where the perimeter and the internal are effectively one network looking from the inside.
If you need to allow external users to get to the SQL box, you can publish the SQL box sitting on the 192.168.50.2 address and still not let external users on to your internal network.
Authentication will be performed by AD (as the sql box will have access securely to active directory).
Just make sure that your internal systems either point to the ISA as their default gateway or if you have other subnets, that there are routing table entries so they know how to get to the 192.168.50.0 subnet and back again ewtc.

Hi Keith,

Thanks again for your help on this.

I have setup the ISA server as you suggested but I am still having some problems.

The ISA server will allow traffic from the internal network to the perimiter network when user autentication is not being used (IE All Users is allowed) however the problem comes when we enable user authentication.

The ISA can see our AD on the internal network, so I dont think there is a problem finding the authentication information.

We are using the firewall client for our connections and I have noticed the "Define Firewall Client Settings" under "ISA Server Administration" on the general tab.

For the sake of this test, I would like to allow all protocalls to be allowed from internal to perimiter for one user and no-one else. Once this is done, I can go about locking down protocalls and adding certificate security.

Thanks again for your help, I really feel ISA is the key for our security, and we are so close to getting there.

Not sure if we are talking the same thing. The client is normally controlled from configuration - networks then from within the properties of the internal network. (or the perimeter of course if an ISA client is running on the DMZ)

The Firewall Client is set to be enabled on the internal (and the perimeter) networks.

I am now wondering if there may be a problem with the roles the server has been given by the active directory, and thats why it is having trouble authenticating users that connect from the firewall client.

I will have a look into it, anything else I should look out for?

Just for clarity, you are not running the ISA client on the servers as well, are you?

No, the client is currently only running on one test laptop.

Should the client be running on the servers?

God no... :) Will be on again when I get home

Thanks for your help. We were able to solve the issue by reinstalling ISA, but your help was useful in making this call.

Thank you :)