Forefront TMG and ISA Server
Forefront Unified Access Gateway & Intelligent Application Gateway 2007
Cheers !!!
Category Archives: ISA Server
Configuring DHCP Relay on ISA Server and Allow VPN connections
I was trying to configure DHCP Relay on ISA Server but wasn’t able to figure out the correct rules. While searching on the internet I came across an article http://www.isaserver.org/tutorials/2004dhcprelay.html which explains the process. I created the two rules mentioned in the article but it dint work.
Then after a while I was able to get it working with the set of rules shown below.
Where, DHCP Server is the actual DHCP server in my internal network. I created a computer object with the IP address of the DHCP Server.
Create a custom protocol as below
Name: DHCP Relay
Protocol: UDP
Direction: Send Recieve
Port: 67
Restart the RRAS service after applying the changes in ISA.
Cheers !!!
ISA Server 2006 NLB Issue with the L3 Switches
Recently I worked on the similar issue with a customer and thought of writing a definite solution for this issue. We resolved the issue by enabling the multicast mode on the ISA Servers. By default, the NLB on ISA Server works in Unicast mode. For getting it worked with the L3 switch we need to change it to the multicast mode. This issue is related to the Windows NLB but since ISA Server uses the Windows Integrated NLB so it inherits the same limitation.
I came across a nice article which describes the Unicast and the Multimode with NLB http://blogs.technet.com/networking/archive/2008/12/09/balancing-act-what-you-really-ought-to-know-about-windows-server-nlb.aspx
To change the Unicast mode to the Multicast mode follow the below steps
- Make sure you have the SP1 installed for the ISA Server 2006
- Remove the NLB settings from the ISA nodes and Disable the NLB on is the ISA nodes
- Follow the article http://support.microsoft.com/kb/938550
- Download the Hotfix from the above article and unzip it on your ISA machine
-
Run the following command to see what mode are you running in
Cscript KB938550.wsf /array:OBSERVER1 /show
-
If it shows that the interface you are tyring to enable the NLB is in Unicast mode then run the following command to change it to the Multicast mode
Cscript KB938550.wsf /array:<Array Name> /nlb:multicast /net1:<network Name>
Where: Array Name is the name of your Array and the Network Name is the name of the network on which you are trying to enable the NLB
-
To change the ISA servers back to the Unicast mode run the following command
Cscript KB938550.wsf /array:<Array Name> /nlb:unicast /net1:<network Name>
At times you may come across an issue where you tried to enable the NLB with Unicast mode and then were not able to make it working because you were using the L3 switch. Since, you enabled the NLB and if you tried to assign any virtual IPs then it won’t allow you to remove those. If you are not able to remove them even after removing the NLB settings manually then follow the below settings
- Stop the Firewall service
-
Manually deleted the subkeys under the following Registry keys from both ISA Servers
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWlbsParametersAdapters
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWlbsParametersInterface
- Removed the VIPs from the ISA NIC
- Restart the Firewall Service
Enjoy
Microsoft Supported ISA Server 2006 to TMG Migration Paths
- ISA Server Standard Edition to Forefront TMG Standard Edition
- ISA Server Standard Edition to Forefront TMG Enterprise Edition standalone server
- ISA Server Enterprise Edition to Forefront TMG Enterprise Management Server (EMS)
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:
- Writing this configuration I am assuming that you have single Edge server role.
- 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
- In the ISA Console, click Firewall Policy on left and then click Toolbox tab on extreme right hand side bar
- Go to Protocols and click New Protocol
- Name that protocol "MTLS" and click next
- Click new and select TCP, direction is Outbound and Port range is 5061 to 5061. Click ok and click next
- Click Next on Secondary Connections page
- 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
- Go to the Firewall Policy and go to the Toolbox on right bar
- Under Toolbox click network objects and click new
- 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.
- Click Ok
**Repeat these steps to create Computer objects for Web Conferencing and A/V roles.
Create Access Rule
- Right click on Firewall Policy, select New and click "Access Rule"
- Name the Rule as Access Edge and Click Next
- Select Allow and click Next
- On Protocols page click Add and select the MTLS protocol we created above. Also, select HTTPS and click Next
- Under the Access Rule source click Add and select External under networks. Click Next
- Under the Access Rule Destination click Add and select Perimeter under networks. Click Next.
- Under User Sets page let the default "All users" be selected
- 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:
- Three Computer Objects in ISA named "Access Edge", "Web Conferencing" and "A/V Edge"
- Inbound MTLS protocol.
- Creating the NAT relationship for Access Edge and Web Conferencing
- Three Server Publishing rules
- 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
- Click networks under configuration in ISA console
- Go to network rules on the middle pane
- From the right pane click "Create new network rule"
- Name the network rule as "OCS Access" and click Next
- Under the Sources page click add and select "Access Edge" and "Web Conferencing" computer objects we created earlier. Click Next
- Under the Traffic Destination page click Add and select external. Click next
- On network relationship page, select network Address Translation (NAT) and click Next
- Click Finish
Create Server Publishing Rules
- Go to Firewall Policy, right click select new and click Non-web server protocol publishing rule
- Name it "MTLS Access" and click Next
- Under the Select Server, enter the IP address for the OCS Access Edge and click Next
- 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.
- Click Next
- On the network listener IP addresses page select External and click Addresses to select the appropriate public IP mapped with this role
- 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:
- Make sure that you are able to access the servers internally
- When using PING as a connectivity verifier method then make sure you are able to ping the server(s) from the ISA Server
- Try changing the connectivity verifier method from PING to HTTP URL
Cheers
ISA Rules for Exchange 2007 Edge in DMZ and HUB in Internal
Found an interesting article which explains the process
Cheers
Things Required when publishing Exchange OWA using ISA Server 2006
ISA Server is a great resource when it comes to publishing the internal resources out on the internet for external access. One of the most common scenarios is the publishing of Exchange OWA through ISA Server. ISA Server can publish the Exchange OWA for Exchange 2000/2003/2007 and so on.
There are few things which are required when publishing Exchange OWA through ISA. You may ask questions like Do you want to have users to authentication on ISA? Are you using any monitoring tool which needs to record the clients IP? What protocols do you want to publish? Are you going to have a DMZ network or not? What will be your Exchange architecture?
Once you have all the answers to the questions as above you can publish the Exchange OWA without any issues.
Let me tell you what needs to be done in some scenarios or questions like above.
Do you want to have users to authentication on ISA?
This question is important because ISA server can authenticate the users before getting them connected to the back-end servers. This provides another layer of defense in protecting your internal resources. When coming across this question, I would recommend you say "yes" as it makes sense to authenticate users on your firewall. If you are doing so, then you have to select "All Authenticated Users" or the AD groups you created in ISA while publishing the Exchange OWA. Also, while creating the web listener you have to select the appropriate Authentication mechanism. ISA supports
Active Directory: Windows Active Directory. ISA should be part of domain to use it
LDAP (Active Directory): Only Windows Active Directory is supported as to be used for LDAP queries. This is used when ISA is in workgroup
RADIUS: RADIUS is a standard and can be used in both scenarios if ISA is part of domain or not.
RADIUS OTP: RADIUS One Time Password provides a secure way of connecting to the resources (not covering in detail)
SecureID: (Not Covering)
Are you using any monitoring tool which needs to record the clients IP? What protocols do you want to publish?
ISA being a NAT device, it replaces the source with its own IP on the exiting interface and changes back when the response comes back. So, if you are using any monitoring utility then most of the time with default configuration, you will see only ISA’s internal/DMZ IP not the client IP. To make this work the way you want you have to select the option "the request should appear from the original client" under the "TO" tab of the published rule property page.
There can never be the set of questions which are applicable to all organizations/companies which they can go through the implement the technology. Every company has its own needs when it comes to securing their resources.
Now, that you have got a glimpse of what to ask before implementing the ISA Server lets see what are the things you need to keep in mind while implementing the OWA publishing. Again, the requirements might change depending on the scenario in which ISA is being deployed. But, most of the things would remain same for almost all scenarios.
When publishing OWA through ISA you have to take care of few things. Like:
- The public name which will be used to access OWA, the name of Server certificate on ISA and the name you put as public name in the OWA publishing rule should be same. Ex. If my public name is OWA.TEST.COM then you should have a server authentication certificate already installed on ISA with the name of OWA.TEST.COM or *.TEST.COM
- The Server authentication certificate on ISA should have a private key associated with it. Public key is always there.
- If you aren’t using the host headers on your exchange server then remove the check mark from the option "Forward the original host header in place of the original"
- When you authentication on ISA select "All Authenticated Users" or specific user set under the users tab. If you select "All Users" then your authentication will be bypassed whatever it may be. "All users" should be used when you are using "No Authentication" on ISA Server.
- Under the Listener select a specific IP address of the OWA.
- Under Authentication LDAP or RADIUS should be selected if your ISA is not a domain member
- Under Authentication Delegation tab select the appropriate authentication which you are using on the Exchange server
- One thing ISA cannot do is to delegate the credentials in a FBA to FBA scenario. If you are using Forms Based Authentication on your Exchange Servers then you have to change it to the Integrated Authentication or Basic Authentication
- You should always use Exchange Web Client Access Publishing rule when publishing OWA because of additional settings involved in this. Don’t use the normal web publishing rule.
Hope the points help you to configure Exchange OWA through ISA Server successfully
Cheers
Inderjeet 