Jim, Thanks for the reply. Note that since I acknowledged the error on May 10th, it hasn't popped up again as new. I haven't restarted the firewall service since that point either though... I've run through the weird-zard again and confirmed that the only adapter selected for the Internal network is the internal NIC. The IP assignments for the Internal network remain (repopulated?) as I described in my post on May 10th. Joe P From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison Sent: Wednesday, May 12, 2010 1:47 AM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Clients - 0xc004002d FWX_E_UNREACHABLE_ADDRESS If you selected more than one adapter, this would be the result. Run through that weirdzard again and make sure only the Internal adapter is selected. Jim From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Pochedley Sent: Monday, May 10, 2010 9:27 AM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Clients - 0xc004002d FWX_E_UNREACHABLE_ADDRESS Jim, These are other errors I'm seeing, and I'm not sure why: Error: The routing table for the network adapter LAN1 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:10.1.6.70-10.1.6.70; Error: The network "External" does not correlate with the network adapters that belong to it. Ranges in adapter "GX1" that do not belong to network "External": 10.1.6.70-10.1.6.70; When networks are configured correctly, the IP address ranges included in each array-level network must include all IP addresses that are routable through its network adapters according to their routing tables. Otherwise valid packets may be dropped as spoofed. Note that this event may be generated once after you add a route, create a remote site network, or configure Network Load Balancing and may be safely ignored if it does not re-occur. I allowed TMG to "define" the internal network by clicking Add Adapter for the Internal network addresses. TMG automatically excluded the 10.1.6.70 address, which is assigned to the RRAS adapter in the server. Hence, I'm not sure why it's being fussed about. Joe P From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison Sent: Monday, May 10, 2010 11:29 AM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Clients - 0xc004002d FWX_E_UNREACHABLE_ADDRESS Joe, Look for signs of other problems in Monitoring / Alerts and in the Windows Application event logs. Generally, when a firewall service (or machine) restart causes "mysterious things", it's because of policy changes that were either misapplied or not applied at all for other reasons. Also, make absolutely sure that you are not assigning IPs via AD user properties that are inappropriate for the VPN clients (or quarantined VPON clients) as you've defined those ranges to TMG. Jim From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Pochedley Sent: Monday, May 10, 2010 7:26 AM To: isalist@xxxxxxxxxxxxx Subject: [isalist] VPN Clients - 0xc004002d FWX_E_UNREACHABLE_ADDRESS We've got VPN (PPTP) setup through TMG, using DHCP to pull IP addresses for the VPN clients. This is essentially the same setup we had under ISA2006... For some reason, this past weekend the VPN began "failing" for the clients... By failing, I mean this... Clients could connect to the TMG server, the VPN connection is established successfully. However clients are not able to communicate with any internal hosts. In looking at the logs, the clients successfully send packets through TMG, and the receiving host receives the packets (confirmed with a packet capture). However, when the internal host tries to reply, TMG blocks the connection with the following: Action: Denied Connection Rule: None - see Result Code Result Code: 0xc004002d FWX_E_UNREACHABLE_ADDRESS Source Network: Internal Destination network: VPN Clients (I'll post full log entries if someone needs more info.) So, TMG recognizes that the destination is on the VPN that it's hosting, but it still thinks the destination IP is unreachable? The issues seems to have started when I restarted the TMG firewall service to update authentication forms (OWA FBA on the TMG server). I received a number of events similar to the following in the event log: Log Name: Application Source: Microsoft Forefront TMG Firewall Date: 5/8/2010 10:30:59 AM Event ID: 21265 Task Category: None Level: Error Keywords: Classic User: N/A Computer: Charon Description: The routing table for the network adapter Internal includes IP address ranges that are not defined in the array-level network VPN Clients, 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: Internal:10.1.6.47-10.1.6.47,10.1.6.63-10.1.6.63,10.1.6.67-10.1.6.67,10.1.6.70-10.1.6.70,10.1.6.223-10.1.6.223,10.1.6.244-10.1.6.244,10.1.6.252-10.1.6.252; The IP addresses listed in each error are presumably ones assigned from DHCP to the VPN clients. Why would restarting the firewall service cause TMG to no longer properly recognize the VPN IP's? Obviously it's a rare occurrence where one needs to restart the TMG firewall service, but it's something I'd done many times under ISA 2006 with no ill effects to the VPN (aside from kicking off active clients, of course). How do I keep it from happening in the future? Joe Pochedley