WPAD not getting resolved on Windows 2008 DNS Server when deploying ISA Auto Discovery

Due to security reasons WPAD and ISATAP have been by default blocked in Windows server 2008 DNS. There is a GlobalQueryBlockList which blocks these entries. When you try to create a WPAD entry to configure your ISA Auto Discovery, it will fail to resolve the WPAD entry whereas it will resolve the WSPAD entry

To remove the WPAD from the block list type the following command

Dnscmd /config /globalqueryblocklist isatap

This command will override the existing list with ISATAP as the only keyword. Now, you can resolve the WPAD entry from NSLOOKUP

Check http://www.scribd.com/doc/7476327/How-DNS-Works-in-Windows-2008 for more details

Cheers !!

Troubleshooting HTTP Filtering in ISA Server

Most of the time we create a HTTP Filter in ISA but sometimes it does not work the way we would have wanted it to. Let’s see a simple example and try to see what could be the possible problems.

 I have a Created a HTTP Filtering to block http://www.fabrikam.com

Search in: Request URL
Pattern: http://www.fabrikam.com

 I will try opening www.fabrikam.com from my client machine which is configured as SecureNAT Client which means that the internal IP of ISA is the Default Gateway for this machine.

 Request from the Client Machine

 Frame: Number = 46, Captured Frame Length = 408, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-B2-45-06],SourceAddress:[00-15-5D-B2-45-05]
+ Ipv4: Src = 192.168.0.175, Dest = 39.1.1.10, Next Protocol = TCP, Packet ID = 20628, Total IP Length = 394
+ Tcp: Flags=…AP…, SrcPort=6504, DstPort=HTTP(80), PayloadLen=354, Seq=2794349469 – 2794349823, Ack=1140043069, Win=32850 (scale factor 0x2) = 131400
– Http: Request, GET /
Command: GET
      + URI: /

ProtocolVersion: HTTP/1.1

Accept: */*

Accept-Language: en-us

UA-CPU: x86

Accept-Encoding: gzip, deflate

If-Modified-Since: Thu, 07 Aug 2008 18:55:57 GMT

If-None-Match: "a686da39bff8c81:1d9"

UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506)

Host: http://www.fabrikam.com

Connection: Keep-Alive

HeaderEnd: CRLF

 ISA forwards the response from the Web Server (of-course the request and response are NAT’d)

 Frame: Number = 48, Captured Frame Length = 365, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-B2-45-05],SourceAddress:[00-15-5D-B2-45-06]

+ Ipv4: Src = 39.1.1.10, Dest = 192.168.0.175, Next Protocol = TCP, Packet ID = 5425, Total IP Length = 351

+ Tcp: Flags=…AP…, SrcPort=HTTP(80), DstPort=6504, PayloadLen=311, Seq=1140043069 – 1140043380, Ack=2794349823, Win=65181 (scale factor 0x0) = 65181

– Http: Response, HTTP/1.1, Status Code = 304, URL: /

ProtocolVersion: HTTP/1.1

StatusCode: 304, Not modified

Reason: Not Modified

ProxyConnection: Keep-Alive

Connection: Keep-Alive

Via: 1.1 ISA

Date: Thu, 30 Apr 2009 14:28:52 GMT

Content-Location: http://www.fabrikam.com/index.htm

ETag: "a686da39bff8c81:1d9"

Server: Microsoft-IIS/6.0

Last-Modified: Thu, 07 Aug 2008 18:55:57 GMT

Accept-Ranges: bytes

HeaderEnd: CRLF

 ISA logged it as

 Allowed Connection

Log type: Web Proxy (Forward)

Status: 200 OK.

Rule: Internet Access Rule

Source: Internal (192.168.0.175)

Destination: External (www.fabrikam.com 39.1.1.10:80)

Request: GET http://39.1.1.10/

Filter information: Req ID: 0734fb7f; Compression: client=No, server=No, compress rate=0% decompress rate=0%

Protocol: http

User: anonymous

 So what went wrong? The client resolved the http://www.fabrikam.com from the local DNS Server and got the IP as 39.1.1.10. Since he now has the destination address it sent a packet directly marked for the destination 39.1.1.10 with HOST: http://www.fabrikam.com. ISA checked the URI "/" and added the destination IP to complete the URL http://39.1.1.1. Since we have a HTTP Filter for http://www.fabrikam.com it mismatches with the http://39.1.1.1

 

Resolution:

Make the client machines as Web proxy clients. This will make users send the right URL to the ISA Server. Web proxy clients depend on ISA to resolve the public names.

See the below request which came from the web proxy client, as compared to the request came from SecureNAT Client. The request was sent to ISA (192.168.0.254) and not to the destination directly. And the client machine gave the URL to ISA for resolving.

 Request from Web proxy Client

 Frame: Number = 29, Captured Frame Length = 455, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-B2-45-06],SourceAddress:[00-15-5D-B2-45-05]

+ Ipv4: Src = 192.168.0.175, Dest = 192.168.0.254, Next Protocol = TCP, Packet ID = 17248, Total IP Length = 441

+ Tcp: Flags=…AP…, SrcPort=6474, DstPort=Multiling HTTP(777), PayloadLen=401, Seq=4199678470 – 4199678871, Ack=2627683601, Win=32850 (scale factor 0x2) = 131400

– Http: Request, GET http://www.fabrikam.com/

Command: GET

+ URI: http://www.fabrikam.com/

ProtocolVersion: HTTP/1.1

Accept: */*

Accept-Language: en-us

UA-CPU: x86

Accept-Encoding: gzip, deflate

If-Modified-Since: Thu, 07 Aug 2008 18:55:57 GMT

If-None-Match: "a686da39bff8c81:1d9"

UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506)

Host: http://www.fabrikam.com

ProxyConnection: Keep-Alive

Pragma: no-cache

HeaderEnd: CRLF

  ISA’s Response to the above web proxy request

 Frame: Number = 30, Captured Frame Length = 1514, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-B2-45-05],SourceAddress:[00-15-5D-B2-45-06]

+ Ipv4: Src = 192.168.0.254, Dest = 192.168.0.175, Next Protocol = TCP, Packet ID = 5032, Total IP Length = 1500

+ Tcp: Flags=…A…., SrcPort=Multiling HTTP(777), DstPort=6474, PayloadLen=1460, Seq=2627683601 – 2627685061, Ack=4199678871, Win=65134 (scale factor 0x0) = 65134

– Http: Response, HTTP/1.1, Status Code = 502, URL: http://www.fabrikam.com/

ProtocolVersion: HTTP/1.1

StatusCode: 502, Bad gateway

Reason: Proxy Error ( The request was rejected by the HTTP filter. Contact your ISA Server administrator. )

Via: 1.1 ISA

Connection: close

ProxyConnection: close

Pragma: no-cache

Cache-Control: no-cache

ContentType: text/html

ContentLength: 4076

HeaderEnd: CRLF

+ payload: HttpContentType = text/html

 ISA Logs it as below

 Denied Connection

Log type: Web Proxy (Forward)

Status: 12217 The request was rejected by the HTTP filter. Contact your ISA Server administrator.

Rule: Internet Access Rule

Source: Internal (192.168.0.175)

Destination: External (192.168.0.254:777)

Request: GET http://www.fabrikam.com/

Filter information: Req ID: 0734fb82; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; Blocked by the HTTP Security filter: URL contains sequences which are disallowed

Protocol: http

User: anonymous

 

 

So, next time you configure the HTTP filtering in ISA, make sure you do NetMon traces to make sure you are doing it correctly.

 

Cheers !!

Publishing OCS 2007 Edge Server Roles using ISA Server 2006

When publishing OCS 2007 Edge server roles there are two ways to configure it. First, you may have all OCS edge server roles on Public IP and second, to have Access Edge and Web conferencing roles on private IP and have them published through ISA Server using NAT. Remember, A/V role still requires Public IP whatever method you choose.

Assumptions:

1. Writing this configuration I am assuming that you have single Edge server role.
2. ISA Server is configured as 3-Leg Firewall

Ports Required

Role		External User Port Requirements	Internal User Port Requirements
Access Edge Server		5061,443	5061
A/V Edge Server		443,3478 50,000-59,999	443, 5062 50,000-59,999
Web Conferencing Edge Server		443	8057

Protocols Required in ISA

Protocol Name	Protocol Type	Protocol Direction	Port Range
Mutual Transport Layer Security (MTLS)	TCP	Outbound	5061-5061
Simple Traversal of UDP through NAT (STUN)	TCP	Outbound	50,000-59,999
	UDP	Send	*50,000-59,999
	UDP	Send	3478-3478

 

Method 1: You have all OCS Edge server roles on public IP

On ISA Server 2006 we have to create three computer objects and then create three Access rules to allow traffic from external users. We will have to create two custom protocols named MTLS (Port 5061 TCP) and STUN (TCP 50,000-59,999, UDP 50,000-59,999, and UDP 3478)

Creating Protocol

1. In the ISA Console, click Firewall Policy on left and then click Toolbox tab on extreme right hand side bar
2. Go to Protocols and click New Protocol
3. Name that protocol "MTLS" and click next
4. Click new and select TCP, direction is Outbound and Port range is 5061 to 5061. Click ok and click next
5. Click Next on Secondary Connections page
6. Click Finish

**Repeat the above steps to create the STUN protocol. Check the directions mentioned in the above table to create the protocol correctly.

Create Computer Object

1. Go to the Firewall Policy and go to the Toolbox on right bar
2. Under Toolbox click network objects and click new
3. Select Computer and Name the object as "Access Edge". Give the IP address of the Access Edge role. This IP is your Public IP you assigned on the OCS Edge server.
4. Click Ok

**Repeat these steps to create Computer objects for Web Conferencing and A/V roles.

Create Access Rule

1. Right click on Firewall Policy, select New and click "Access Rule"
2. Name the Rule as Access Edge and Click Next
3. Select Allow and click Next
4. On Protocols page click Add and select the MTLS protocol we created above. Also, select HTTPS and click Next
5. Under the Access Rule source click Add and select External under networks. Click Next
6. Under the Access Rule Destination click Add and select Perimeter under networks. Click Next.
7. Under User Sets page let the default "All users" be selected
8. Click Finish

**Repeat these steps to create access rules for Web conferencing and A/V role. When you are finished creating the rules, they may look like

Access Rule Name	Rule Action	Protocols	Access Rule Source	Access Rule Destination	User Sets
Access Edge	Allow	HTTPS MTLS/SIP	External	Access Edge	All Users
A/V Edge	Allow	HTTPS STUN	External	A/V Edge	All Users
Web Conferencing Edge	Allow	HTTPS	External	Web Conferencing Edge	All Users

 

Method 2: When using NAT for Access Edge and Web conferencing

We need:

1. Three Computer Objects in ISA named "Access Edge", "Web Conferencing" and "A/V Edge"
2. Inbound MTLS protocol.
3. Creating the NAT relationship for Access Edge and Web Conferencing
4. Three Server Publishing rules
5. One Access Rule for A/V Edge

Protocol Name	Protocol Type	Protocol Direction	Port Range
Mutual Transport Layer Security (MTLS)	TCP	Inbound	5061-5061

 

Creating the computer objects

Follow the steps mentioned in Method 1 for creating the computer objects

Creating the Inbound MTLS Protocol

Follow the steps mentioned in the Method 1 for creating the protocol. Remember to change the direction to inbound.

Creating the NAT Relationship between Access Edge and Web Conferencing

1. Click networks under configuration in ISA console
2. Go to network rules on the middle pane
3. From the right pane click "Create new network rule"
4. Name the network rule as "OCS Access" and click Next
5. Under the Sources page click add and select "Access Edge" and "Web Conferencing" computer objects we created earlier. Click Next
6. Under the Traffic Destination page click Add and select external. Click next
7. On network relationship page, select network Address Translation (NAT) and click Next
8. Click Finish

Create Server Publishing Rules

1. Go to Firewall Policy, right click select new and click Non-web server protocol publishing rule
2. Name it "MTLS Access" and click Next
3. Under the Select Server, enter the IP address for the OCS Access Edge and click Next
4. Under the Select protocol page, select the MTLS protocol which we created in previous step. The protocol will only appear here if it is inbound. No outbound protocols appear here.
5. Click Next
6. On the network listener IP addresses page select External and click Addresses to select the appropriate public IP mapped with this role
7. Click Finish

**Repeat the above steps to create two server publishing rules for HTTPS Server. Associate these rules with Access Edge and Web Conferencing IP addresses.

Creating the Access Rule for A/V Edge

Follow the steps in Method 1 to create access rule to allow traffic for A/V Edge server.

 

Internal error (1359) when accessing a published Web farm

CAUSE:

This error is generated mostly when the back end server nodes participating in the web server farm aren’t responding to the connectivity verification from the ISA Server. When you receive this kind of error then under the Monitoring > Connectivity Verifiers, you will see that the server(s) are disconnected. This may be due to network issues or server not available.

RESOLUTION:

1. Make sure that you are able to access the servers internally
2. When using PING as a connectivity verifier method then make sure you are able to ping the server(s) from the ISA Server
3. Try changing the connectivity verifier method from PING to HTTP URL

 

Cheers