locked
exception filter for Teredo on Vista SP1 RRS feed

  • Question

  • As WDK mentions as below,

    Exceptions that allow applications to receive unsolicited traffic over Teredo through a firewall must be created using Windows Filtering Platform APIs. This is accomplished by opening incoming and outgoing application-based exceptions (Application <app name>) at the Teredo Sublayer of ALE for IPv6 traffic. This ensures that only applications with the Teredo exception can use Teredo.

     

    I have one question, beside implementation of an exception at FWPM_SUBLAYER_TEREDO, does the 3rd part vendor need implement other exceptions in their own sublayer at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6? As you know, we all do our job on our own sublayers.

     

    How MS handles it? please hint me, thank you.

     

     

    Monday, November 5, 2007 9:34 AM

Answers

  •  ylei wrote:

    ...beside implementation of an exception at FWPM_SUBLAYER_TEREDO, does the 3rd part vendor need implement other exceptions in their own sublayer at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6?

     

    I think so -- assuming you have a default block filter sitting at your ALE_AUTH_RECV_ACCEPT_V6 sublayer. Filters at AUTH_LISTEN_V6 or RESOURCE_ASSIGNMENT_V6 allows the teredo interface to become qualify; Filters at AUTH_RECV_ACCEPT_V6 allows only white-listed inbound connections to be accpeted.

     

    For example, if you want only foo.exe to receive teredo traffic from a particular remote address, you would need --

     

    1) A default block filter (i.e. filter w/ no conditions) registered at the FWPM_SUBLAYER_TEREDO sublayer of AUTH_LISTEN_V6 or RESOURCE_ASSIGNMENT_V6. You don't have to register one if there is one there already (e.g. if Windows Firewall is running). This is required or otherwise the teredo interface will remain at offline state.

     

    2) A filter that registered at the same layer/sublayer above which permit foo.exe to listen(). When foo.exe does a listen(), the teredo interface will then come out of dormancy.

     

    3) A default block filter (i.e. filter w/ no conditions) registered at your sublayer under ALE_AUTH_RECV_ACCEPT_V6 .

     

    4) A filter that registered at the same layer/sublayer as in 3) which allows foo.exe from accepting incoming connects from the peer you trust.

     

    Hope this helps,

    Biao.W.

    Thursday, November 8, 2007 2:02 AM

All replies

  •  ylei wrote:

    ...beside implementation of an exception at FWPM_SUBLAYER_TEREDO, does the 3rd part vendor need implement other exceptions in their own sublayer at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6?

     

    I think so -- assuming you have a default block filter sitting at your ALE_AUTH_RECV_ACCEPT_V6 sublayer. Filters at AUTH_LISTEN_V6 or RESOURCE_ASSIGNMENT_V6 allows the teredo interface to become qualify; Filters at AUTH_RECV_ACCEPT_V6 allows only white-listed inbound connections to be accpeted.

     

    For example, if you want only foo.exe to receive teredo traffic from a particular remote address, you would need --

     

    1) A default block filter (i.e. filter w/ no conditions) registered at the FWPM_SUBLAYER_TEREDO sublayer of AUTH_LISTEN_V6 or RESOURCE_ASSIGNMENT_V6. You don't have to register one if there is one there already (e.g. if Windows Firewall is running). This is required or otherwise the teredo interface will remain at offline state.

     

    2) A filter that registered at the same layer/sublayer above which permit foo.exe to listen(). When foo.exe does a listen(), the teredo interface will then come out of dormancy.

     

    3) A default block filter (i.e. filter w/ no conditions) registered at your sublayer under ALE_AUTH_RECV_ACCEPT_V6 .

     

    4) A filter that registered at the same layer/sublayer as in 3) which allows foo.exe from accepting incoming connects from the peer you trust.

     

    Hope this helps,

    Biao.W.

    Thursday, November 8, 2007 2:02 AM
  • Thank you very much, I may get your points.

     

    Now I understand why in WDK docs there are

    "Required Windows Filtering Platform Exceptions for Teredo" and "Required Firewall Exceptions for Teredo".

     

    the former is dealing with FWPM_SUBLAYER_TEREDO and the latter is for our own sublayer.

     

    One more question, do you have any suggestion on testing Teredo Security Model? How can I make sure Teredo is ready and what kind of existing apps. using Teredo?

     

    Thanks.

     

     

    Thursday, November 8, 2007 9:33 AM
  • Hi Biao,

    Is it necessary to have a block filter at both (AuthListen or ResAssign) and RecvAccept for Teredo to operate correctly?

    I added a default block for RecvAccept and I now see Router Solicitations going out of my box. However I don't believe I have a test environment capable of full Teredo operation.

    In my scenario Windows Firewall will be turned off.

    Any information you can provide would be helpful.

    Thanks,
    Jonathan Kelley

    Monday, May 12, 2008 3:08 PM
  •  Biao Wang [MSFT] wrote:

    ...if you want only foo.exe to receive teredo traffic from a particular remote address, you would need --

     

    1) A default block filter (i.e. filter w/ no conditions) registered at the FWPM_SUBLAYER_TEREDO sublayer of AUTH_LISTEN_V6 or RESOURCE_ASSIGNMENT_V6. You don't have to register one if there is one there already (e.g. if Windows Firewall is running). This is required or otherwise the teredo interface will remain at offline state.

     

    2) A filter that registered at the same layer/sublayer above which permit foo.exe to listen(). When foo.exe does a listen(), the teredo interface will then come out of dormancy.

    ...

     

    To answer Jonathan's question, 1) above is actually not necessary.

     

    Thanks for pointing this out.

     

    Thanks,

    Biao.W.

    Wednesday, May 21, 2008 3:46 AM