DirectAccess forwarding issue on DA server (Vanilla 2008 R2, no UAG)

Sunday, May 30, 2010 2:03 AM

0

I'm running 2008 R2 as an edge server attempting to get DirectAccess working. The infrastructure tunnel comes up just fine, I can ping through the Reredo tunnel to any internal resource. I'm hung up on something fairly odd, and after much searching figured I'd ask here.

I've enabled windows firewall audit logs on the DA server and have noticed the following when a DA client attempts to reach a DA server. Any thoughts on this? Before noticing this I was trying to trace the issue from the client side (netsh trace start scenario=directaccess report=yes capture=yes) which lately has resulted in a STOP 0xA for some reason.

Here's the event that's logged when the client attempts to reach the DC/DNS server. ID 5152.

The Windows Filtering Platform has blocked a packet.

Application Information:

Process ID: 0

Application Name: -

Network Information:

Direction: Forward

Source Address: 2001:0:xxxx:xxxx:c3e:4d03:bd1a:54f

Source Port: 0

Destination Address: 2002:xxxx:xxxx:1:0:5efe:10.16.38.51

Destination Port: 0

Protocol: 0

Filter Information:

Filter Run-Time ID: 74900

Layer Name: Forward

Layer Run-Time ID: 10

Any thoughts? 10.16.38.51 is the DC/DNS server, so this should be allowed with just the infrastructure tunnel up, and it's clear that the client is trying to send traffic as this is showing up on the DA server. This is making me think there's some other firewall rule that is preventing traffic from forwarding, but there's nothing that I've set up via GPO or otherwise that should be doing that.

I've only been able to test this with Teredo so far. IP-HTTPS for some reason is presenting the wrong host name - the cert I've told it to use is a second certificate that was issued and is valid for directaccess.mydomain.com and while DA is configured to use that name, it presents the cert for DIRECTACCESS.cent.mydomain.com - the machine certificate. The certificate being invalid for the name being used of course causes IP-HTTPS to refuse to connect.

All Replies

Sunday, May 30, 2010 4:12 AM

0

This is starting to seem like a one step forward three steps back thing over and over again... I simply cannot rebuild my entire environment, it just wouldn't work. Now I'm getting this lovely mess where incoming teredo is being blocked by the Windows firewall even though the rule is enabled. Sigh. Was this even tested before being released? It seems like a nightmare that requires one to balance on one toe while rubbing your stomach, patting yourself on the head, and reciting the alphabet backwards on top of an airplane's wing traveling at mach 4.
Sunday, May 30, 2010 4:20 AM

0

Back to post one... Rebooting twice made Teredo magically start working. It's worth noting that the only thing not working in this infrastructure is DirectAccess... Go figure. Considering the number of threads I've seen on it I'm not surprised at all.

Sunday, May 30, 2010 7:05 PM

I've narrowed down the block to this filter:

<item>

			<filterKey>{d236257d-934e-4c5e-bec3-0fd601a8b2b7}</filterKey>

			<displayData>

				<name>DirectAccess Policy-DaServerToDnsDc</name>

				<description>Policies to enable the Corp Access Over IPsec and IPv6 remotely</description>

			</displayData>

			<flags numItems="1">

				<item>FWPM_FILTER_FLAG_HAS_PROVIDER_CONTEXT</item>

			</flags>

			<providerKey>{1bebc969-61a5-4732-a177-847a0817862a}</providerKey>

			<providerData/>

			<layerKey>FWPM_LAYER_IPFORWARD_V6</layerKey>

			<subLayerKey>FWPM_SUBLAYER_IPSEC_TUNNEL</subLayerKey>

			<weight>

				<type>FWP_UINT8</type>

				<uint8>0</uint8>

			</weight>

			<filterCondition numItems="2">

				<item>

					<fieldKey>FWPM_CONDITION_IP_DESTINATION_ADDRESS</fieldKey>

					<matchType>FWP_MATCH_EQUAL</matchType>

					<conditionValue>

						<type>FWP_V6_ADDR_MASK</type>

						<v6AddrMask>

							<addr>2002:ae24:1c1d:1:0:5efe:10.16.38.51</addr>

							<prefixLength>128</prefixLength>

						</v6AddrMask>

					</conditionValue>

				</item>

				<item>

					<fieldKey>FWPM_CONDITION_ARRIVAL_INTERFACE_PROFILE_ID</fieldKey>

					<matchType>FWP_MATCH_EQUAL</matchType>

					<conditionValue>

						<type>FWP_UINT32</type>

						<uint32>0</uint32>

					</conditionValue>

				</item>

			</filterCondition>

			<action>

				<type>FWP_ACTION_CALLOUT_TERMINATING</type>

				<calloutKey>FWPM_CALLOUT_IPSEC_FORWARD_INBOUND_TUNNEL_V6</calloutKey>

			</action>

			<providerContextKey>{150b3d76-f85b-41bb-ad84-124a6cb96026}</providerContextKey>

			<reserved/>

			<filterId>83254</filterId>

			<effectiveWeight>

				<type>FWP_UINT64</type>

				<uint64>288230376151711745</uint64>

			</effectiveWeight>

		</item>

Based on what I see there I'm thinking that one of these adapters isn't configured properly. I have native IPv6 disabled on both the internal and external interface... I've tried with it enabled and with it disabled and didn't see a difference, but maybe that is part of the issue - any thoughts on that? All transitional features are enabled per requirements.

Sunday, May 30, 2010 8:28 PM

0

More info: If I try to connect out to the client from a DC the outgoing packet is permitted:

The Windows Filtering Platform has permitted a connection.

Application Information:

Process ID: 4

Application Name: System

Network Information:

Direction: Inbound

Source Address: 2002:xxxx:xxxx::ae24:1c1d

Source Port: 128

Destination Address: 2001:0:xxxx:xxxx:18ab:6d18:bd1a:54f

Destination Port: 0

Protocol: 58

Filter Information:

Filter Run-Time ID: 82619

Layer Name: Receive/Accept

Layer Run-Time ID: 46

and the return packet is dropped:

The Windows Filtering Platform has blocked a packet.

Application Information:

Process ID: 0

Application Name: -

Network Information:

Direction: Forward

Source Address: 2001:0:xxxx:xxxx:18ab:6d18:bd1a:54f

Source Port: 0

Destination Address: 2002:xxxx:xxxx:1:0:5efe:10.16.38.51

Destination Port: 0

Protocol: 0

Filter Information:

Filter Run-Time ID: 82550

Layer Name: Forward

Layer Run-Time ID: 10

This makes me wonder if it's a routing issue, but that doesn't make sense as the DA server can access all internal resources via IPv6.

I know the IPs don't match up, but the two showed up consecutively after attempting to initiate an RDP session to the client from the DC, and that return packet is clearly to the DC and the allowed packet was the only packet sent to the client, so the two correlate.
Sunday, May 30, 2010 9:41 PM

0

I just noticed this as well:

The Windows Filtering Platform has blocked a packet.

Application Information: Process ID: 0

Application Name: -

Network Information:

Direction: Forward

Source Address: 2002:xxxx:xxxx:1:0:5efe:10.16.38.51

Source Port: 0

Destination Address: 2002:xxxx:xxxx:1:0:5efe:10.16.38.62

Destination Port: 0

Protocol: 0

Filter Information:

Filter Run-Time ID: 82577

Layer Name: Forward

Layer Run-Time ID: 10

That's DC1 -> NLS. However, I can access NLS just fine over ISATAP from DC1 and correct me if I'm wrong, but that should get routed through the ISATAP router, which in this setup is the DA server that's dropping packets.
Monday, May 31, 2010 3:23 AM

0

It's working perfectly fine now via IPHTTPS - Teredo is having trouble, but I may just need to try it from a different network.

I know I look like a crazy man talking to myself, but I figure whoever comes into this thread with any ideas would appreciate knowing the current state of my mess as opposed to the state of it whenever I first posted.
Saturday, June 19, 2010 8:02 PM

0
Hello James P. Riley,

Start at this really good guide “DirectAccess for Windows Server 2008 R2”

For troubleshooting connection issues please see the chapters starting with: Fixing Issues with connecting to …

DirectAccess for Windows Server 2008 R2 - Design, Deployment, and Troubleshooting Guides
Author: Joe Davies - Editor: Scott Somahano
Microsoft Corporation - Published: December 2009 - Updated: June 2010
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=647222d1-a41e-4cdb-ba34-f057fbc7198f

Best regards,
Harry
This posting is provided "AS IS" with no warranties, and confers no rights.
- Proposed As Answer by Harry Hi Thursday, July 01, 2010 9:34 AM

DirectAccess forwarding issue on DA server (Vanilla 2008 R2, no UAG)

All Replies

Products

Resources

Solutions

Updates

Trials

Related Sites

Training

Certifications

Other resources

Support by product

Other support links

Not an IT pro?