The Ip Address Specified For Communication Between This Forefront Tmg
We just deployed our first Forefront TMG server, and for the most part it is going well. However, I have quite of entries in my event viewer of the following:Forefront TMG detected Windows Filtering Platform filters that may cause policy conflicts on the server. The following providers may define filters that conflict with the Forefront TMG firewall policy: unnamed provider(s).The IP address specified for communication between this Forefront TMG computer (oldIPaddressusedfortestin g) and other array members is not bound to a network adapter installed on this computer. The IP address specified for intra-array communication must be bound to a network adapter installed on the computer.The routing table for the network adapter LAN includes IP address ranges that are not defined in the array-level network Internal, to which it is bound. As a result, packets arriving at this network adapter from the IP address ranges listed below or sent to these IP address ranges via this network adapter will be dropped as spoofed.
To resolve this issue, add the missing IP address ranges to the array network. The following IP address ranges will be dropped as spoofed: External:Forefront TMG was unable to decompress a response body from photography.shop.ebay.com because the following error occurred: The data is invalid. This error may occur when the available memory is insufficient, the response is corrupted due to a network problem, or the server returns an illegal response.I apologize if these are separate issues, the messages feel quite vague to me and I'm not sure if they're related or not. I can answer any infrastructure questions you may have - thanks!
TMG does not support IPv6 currently so not much point leaving IPv6 enabled on the box.Only the internal nic is allowed to have a dns entry - and this should be pointing to internal DNS servers only. All other FTMG nics should be blank in respect to DNS ip addresses. The internal DNS servers use their forwarding tabs to make external dns requests.You also have two default gateways - are you using ISP-R on the TMG box?Why are you using an interarray nic? They ceased to be needed after ISA 2006 sp1 unless your network is SO busy the internal nics cannot cope?Look in networking - internal - properties - addresses - in the internal address ranges, have you included the FULL subnet? For example,if you are using 10.1.0.0 as the internal network (although you appear to be using a 24 bit mask) then it would look like:10.1.0.0 - 10.1.255.255Any additional internally accessible networks should also be listed here and MUST include the network ID and the broadcast address. For some reason, when we disabled IPv6, client VPN stopped working. Here's how/why we turned it back on:I would love to disable IPv6, if you can help with a fix/workaround?We are using ISP-R.I never intentionally configured a interarray NIC - this is only Standard edition, I wasn't aware you could even do that.
Should I disable it? If so, how?The 10.1.1.0/24 network is on the other end of a site-to-site VPN - should it still be included in internal? The VPN is working fine as is, but there are strange 'errors' related to it in the event log:Description: Forefront TMG cannot locate a route to the LINC remote site.As a result, a connection cannot be established.
To establish the IPsec site-to-site connection, you must update the routing table.The local tunnel endpoint of VPN site-to-site network LINC is incorrect.Server OORT cannot connect to the remote site using the 207.63.134.130 local tunnel endpoint. I tried to fix this error:The IP address specified for communication between this Forefront TMG computer (oldIPaddressusedfortestin g) and other array members is not bound to a network adapter installed on this computer. The IP address specified for intra-array communication must be bound to a network adapter installed on the computer.using this article:But it did not work.
The other errors reported still stand. Any thoughts?Tonight I will be switch ISP-R to ISP load balancing + failover, and setting our 2nd ISP connection to 0%. Hopefully that will be accepted? TMG didn't complain, but I also didn't hit 'apply' yet. The reason for this is we need certain internal servers to be published on specific IPs, which are located on the second ISP connection. Not sure if this change affects any ideas you might have?
I tried this again:For some reason it worked this time? My only remaining errors are:Description: Forefront TMG detected Windows Filtering Platform filters that may cause policy conflicts on the server OORT. The following providers may define filters that conflict with the Forefront TMG firewall policy: unnamed provider(s).MS says you can safely ignore this , but I find that less than an ideal solution.
Here's another link describing it in a bit more detail:However, if you look closely at both of those, the provider is Microsoft Corp - mine is 'unnamed provider.' The netsh command, however, yields this:Categories:BootTimeRuleCategory Microsoft Forefront Threat Management GatewayFirewallRuleCategory Microsoft Forefront Threat Management GatewayStealthRuleCategory Microsoft Forefront Threat Management GatewayConSecRuleRuleCategory Windows FirewallMaybe that 4th option is causing this weird message? OK - here goes.The Concurrent TCP Connections from One IP Address Limit Exceeded error alert was signaled 9 times.Exactly what it says on the packet. What are these IP addresses relating to?The Denied Connections per Minute from One IP Address Limit Exceeded error alert was signaled 1 timesLinked to the above - what is the device at this IP address?The Non-TCP Sessions from One IP Address Limit Exceeded error alert was signaled 15 timesand again hereThe secure channel to the domain controller cannot be verifiedThis one is a cause for concern if the box is joined to the domain. What rules do you have in place to allow the TMG and DC's to communicate in both directions?Does the TMG System Policy allow for the traffic also?The WFP Filter Conflict Detected error alert was signaled 8 timesThis was a bug but I had thought that it had been corected with SP1, the SP1 update and the rollups. Confirm you have deployed ALL TMG updates.A policy rule blocks FTP uploadsNo issue here - just informing you that the rules that include FTP traffic have not been right-clicked, configure FTP and the check box for FTP read-only cleared.Strict RPC compliance is enforced in an access rule that allows traffic to or from the Local Host networkSame here. Traffic between the local host and internal that use RPC do not need to be as secuer as rpc traffic elsewhere.
Righjt-click rules between localhost and internal, click configure rpc and uncheck the strict rpc compliance box.The Compression by Unsupported Method warning alert was signaled 1 timesInformationalThe Compression Failure (Decompression Failed) warning alert was signaled 14 timesInformationalThe Configuration error warning alert was signaled 4 timesBIG issue - read my articleThe IP Spoofing warning alert was signaled 1 timessame againThe rest are just informational - for example the dns message is as it should be (blank dns on all adaptors except the internal). The Concurrent TCP Connections from One IP Address Limit Exceeded error alert was signaled 9 times.The Denied Connections per Minute from One IP Address Limit Exceeded error alert was signaled 1 timesThe Non-TCP Sessions from One IP Address Limit Exceeded error alert was signaled 15 timesThese IP addresses appear to be random - sometimes it's my PC, sometimes it's our DC, often it's an anonymous wireless or kiosk user (we are a library with public internet access). I notice they happen more often when the CPU is spiking - I have not determined the cause yet, but it is not uncommon to see CPU at 100% during the middle of the day. Disabling NIS and IDS have no effect.There are currently no specific rules that permit DC and TMG access, however, this error has not reappeared since I created that log.The WFP Filter Conflict Detected error alert was signaled 8 timesI opened a ticket with MS and during the course of that call we confirmed that all appropriate rollups/SP had been installed. Not sure why this one won't go away.Strict RPC should be disabled for the whole internal range? I have a rule that disables it for 1 server, which does WMI monitoring (PRTG), but the rest seem to be OK.the IP spoofing error was triggered by a static route placed incorrectly - that is also resolved now.I will try adding a vCPU during our next maintenance window, although I'm hesitant to do so because we're only at 100 users.
The physical CPU is a X5540 - should be no trouble at all for such a load. Aside from that, the only issue is the WFP Filter Conflict which MS says to ignore. Still no luck - I have disabled NIS, local AV (ESET NOD32), IDS, web filter and web caching. The CPU is still at 100% during daytime hours, due to wspsrv (according to procmon - kernel CPU sometimes reaches 550%).In the past, I have read that virtualization is not a good choice for 'real time' applications - I'm starting to wonder if that is the issue I'm experiencing here.Because all of the original issues have fallen by the wayside, I am awarding points and will create new questions as necessary for individual issues.
Thanks for all your assistance! Your call - if the questions involvement FTMG though they will likely come my way.FTMG virtualised is not an issue as long as the host and the guests are suitably resourced.That said, resourcing generally is vital for FTMG within the environment. For example, an FTMG server with 20GB RAM and 4 x quad processors will act awfully if there is only one poorly-specced DC that is having to resolve all the DNS name resolutions, AD group lookups etc or the bandwidth/links between FTMG and the DC's are rubbish. I have been thinking quite a bit abuot that - even though I only have 150 users during peak hours, maybe the fact that I have a 50Mb connection being pounded on is causing more stress than the TMG Capacity Planner would suggest.
I am going to try an additional vCPU and 2GB more RAM (we are running standard, I believe 4GB is the limit?) before migrating to a physical.Our DC is also a VM with a dual 10Gb uplink and an average utilization rate of 3%. I appreciate any other suggestions you may have regarding this?
Note that extended support from Microsoft for the Microsoft Forefront Threat Management Gateway ends in 2020 (for more information, check ). Therefore, ASG Technologies does not recommend that you use this platform in new deployments.
Create directory for log filesCreate a directory C:Log and grant full access to user NETWORK SERVICE for the log files, in case troubleshooting is necessary.If you want to save the log files at a different location, create a corresponding directory and configure the log (see in the 'Create Secure Logon environment' section). Configure web-server service rolesThe IIS 6 compatibility mode must be activated for installing the WSL Frontend components for Microsoft IIS, while ASP.NET is required for executing the Web Secure Logon web services and websites.To enable IIS 6 compatibility mode and ASP.NET. Start the Windows 2008 R2 Server Manager. Click Add Role Service under Roles ► Web Server (IIS):. Select entry ASP.NET in the next dialog. The dependent role services are automatically marked. Select at least IIS 6 Metabase Compatibility and IIS 6 Scripting Tools under IIS 6 Management Compatibility and click Next to start installation.
The IIS 6 compatibility mode is only required for installation. After installation has been completed, this role service can, if necessary, be removed. Configure IP address and SSL port in IISThis table lists and describes the setting for HTTPS: DesignationValueTypeHTTPSIP AddressInternal IP Address (e.g., 10.2.1.99).Port3345SSL certificateCertificate for internal communication (e.g., wslfrontend.mydomain.local).This table list and describes the settings for HTTP: DesignationValueTypeHTTPIP AddressInternal IP Address (e.g., 10.2.1.99).Port8081Host NameInternal FQDN (e.g., wslfrontend.mydomain.local).To configure the IP address and the SSL port. Open the IIS 6 management console and right-click Default Web Site. Select Edit Bindings from the context menu.
The Ip Address Specified For Communication Between This Forefront Tmg Computer
Select HTTPS in the Type field. Then, select the internal IP address in the IP address list and set Port to 3345. For SSL communication, select the internal server certificate from the certificate list (e.g., mydomain.local). Wildcard certificates (e.g.,.mydomain.local) may be used.
Edit the binding for HTTP and change the port to 8081.Install WSL FrontendTo install the WSL Frontend components. Execute the FrontEndTMGSetup.exe package on each Microsoft Forefront TMG server being used.
The setup must be executed with administrative permissions. Specify which Microsoft Forefront TMG version is installed on the current server. Set the internal IPv4 address of the TMG-Server.
Specify the destination folder. Set the physical folder (publishing folder) for the web applications. Select the target web site. Specify the application pool and application name for the Frontend services. The default application pool ( WSLAppPool) will be properly set up if it does not exist. Set the application pool and application name for the Notification Service. Specify the application pool for the TMG Admin Service.
Specify the application pool for the Frontend Service. Click Install. Check the installation by calling this website from the current server. Web Secure Logon web filter components are installed later in the installation process. At the end of the installation, the web filter is automatically registered for the selected Microsoft TMG product.
In the TMG console, check whether the Web Secure Logon web filter has been correctly registered under System ► Web filter.If the web filter is not in the list, restart the TMG Firewall service. Use the TMG console or execute this command line in the input prompt. If you are connected to the TMG server via RDP, you might have to re-establish the connection (reconnect) for changes to take effect. Configure Microsoft Forefront TMGEach of the following topics consists of a general parameter overview (table) as well as a detailed description of the configuration procedure.For information on the special configurations for the log on of certificates/SmartCards, see below. If the task pane is not visible, activate the menu item Task Pane in the View menu or click the arrow icon on the right. Open the Network Objects section and click New ► Web Listener.
Enter the name WebSecureLogon-WebListener and click Next. Select option Require SSL secured connections with clients and click Next. Select External from the network list. Click Select IP Addresses and select Specified IP addresses on the Forefront TMG computer and the selected network in the subsequently displayed dialog. Subsequently add the external IP address to the list of the Selected IP Addresses and click OK.
The changed IP address of the External network is displayed. Click Next. Select Assign a Certificate for each IP Address, select the previously selected IP address and click Select Certificate. Select the certificate for the external host name (e.g., my.company.com) and click Next. The dialog for configuring the Authentication Settings displays.
For logon with user name/password, OneTimePass, SMS, RADIUS, etc., select option No Authentication. For logon with certificate/SmartCard, see below.Publish WorkspaceParameter overview: DesignationValueTypeWeb Site Publishing RuleNameWorkspace accessDescriptionHTTPS communication from outside towards the WorkspaceActionAllowFromAnywhereToInternal FQDN of the web server/load balancer under which the Workspace is accessible (e.g., portal.mydomain.local).Optional: IP address of the web server/load balancer.Forward the original Host-Header instead of the actual one.TrafficHTTPS (optional HTTP with redirect to HTTPS). Optionally, you can enter the IP address or the computer name of the web server or load balancer.
Enter the relative path to the Workspace on the previously selected web server/load balancer, usually /Workspace /. Click Next. Configure the parameters for the external address, e.g., from the Internet, in the next dialog. Select the Public Name, e.g., my.company.com, for Accept requests for This Domain Name (type below). Specify the virtual directory of the Workspace as Path, usually /Workspace /. Activate option Forward the Original Host Header instead of the actual one and click Next. Select the previously created wSL Web Listener (see above) and click Next.
Change the default value for the Authentication Delegation to No Delegation, but client may authenticate directly and click Next. Confirm your changes in the next dialog All Users and click Next. The system displays a summary of the settings. Click Finish to create the rules.Publish WSL logon pagesUse this rule to publish the WSL logon pages.Parameter overview: DesignationValueTypeWeb Site Publishing RuleNamewSL Logon Pages AccessDescriptionHTTPS communication from outside towards the WSL logon pages.ActionAllowFromAnywhereToInternal FQDN of the web server/load balancer under which the WSL logon pages are accessible (e.g., wslfrontend.mydomain.local).Optional: IP address of the web server/load balancer.Forward the original Host-Header instead of the actual one.TrafficHTTPS (optional HTTP with redirect to HTTPS). This value is specified by the Web Listener.ListenerwSL Web ListenerPublic NameRequests for the following web sites as well as a list of the external addresses (e.g., my.company.com)PathsExternal Path: Same as the internal.Internal Path: virtual directory of the WSL logon pages, e.g., /DMZServices/.Authentication DelegationNo Delegation, and client cannot authenticate directlyUsersAll UsersBridgingHTTPS to port 3345To publish the log-on pages.
Open the TMG management console and select Firewall Policy in the left-hand navigation. Subsequently select the Tasks tab on the right-hand side in the task pane and click Publish Web Site. Alternatively, right mouse click Firewall Policy and select New ► Web Site Publishing Rule from the context menu. Follow the steps as guided by the wizard:.
Enter the name wSL Logon Pages Access and click Next. Select option Allow and click Next. Select the publishing type. You usually have to select Publish a single Website or load balancer here. See the help menu of the Microsoft ISA/TMG Server for further options. Click Next. Select option https as the Server Connection Security.
Enter the internal address for the WSL logon pages; e.g., wslfrontend.mydomain.local. Optionally, you can enter the IP address, the computer name of the web server, or load balancer. Specify the virtual directory of the WSL logon pages on the web server/load balancer, usually /DMZServices/. Click Next. Configure the parameters for the external address, e.g., from the Internet, in the next dialog. Select the Public Name, e.g., my.company.com, for Accept requests for This Domain Name (type below).
Specify the virtual directory of the WSL logon pages as Path, usually /DMZServices/. Click Next. Select the previously created Web Secure Logon Web Listener (see above) and click Next. Leave the default value for the Authentication Delegation on No Delegation, and Client cannot authenticate directly and click Next.
Confirm your changes in the next dialog All Users and click Next. You receive a summary of the settings. If you have not defined web servers/load balancers yet, you can create them via New. Example:Menu: New ► ComputerName: wslbackend.mydomain.localIP Address: 10.1.1.190Description: WSL Backend Services Webserver/Loadbalancer. Confirm your changes in the next dialog All Users and click Next.
A summary of the settings displays. Click Finish to create the rules. Continue with the step below.Apply firewall policy settingsClick Apply to accept the configuration for the TMG Server.Advanced configuration for certificate/SmartCard logonFor logon via certificate or SmartCard, additional parameters are required for the WSL Frontend server and for the Web Secure Logon configuration.
This prompts the TMG Server to request the user certificate (or SmartCard) from the user. You need to create a new user group as well as an additional web publishing rule for the WSL Frontend configuration. The Certificate Revocation List (CRL) check for user certificates is executed by the TMG Server.
Ensure that the root certificate of the CA contains the URL for the CRL list.Create user group. Open the Users section in the Task Pane under Firewall Policy. Click New.
The Wizard for creating a user group starts. Enter the user group name, for example WebSecureLogonCertAuthUsers, and click Next. Click Add ► Radius and select the option All Users in this Namespace in the subsequently displayed dialog. Click Finish to create the group.Web publishing rule. Create a web publishing rule with the name Web Secure Logon Cert Authentication (similar to the rule in above) under Firewall Policy.
Select a temporary virtual directory, e.g., /WebSecureLogonCertAuth/. as the Path.