locked
UAG Directaccess allows only ICMP RRS feed

  • Question

  • ICMP ping (by IP) can travel from client to internal network and from internal network to client but anything else does not work. Looking at the policies shows ICMP is not encrypted and everything else is encrypted (including DNS requests). Looking at the client firewall/monitoring/security associations/main mode is blank, showing again that IPSEC is not connecting. So the question is it the firewall on server or client or is it the certificates, or something completely different?
    Thursday, December 3, 2009 4:49 PM

Answers

  • "Unknown authentication" means certificates authentication which is the first type of authentication.
    "No policy configured" means the machine got a request to negotiate IPsec but couldn't find a matching IPsec rule on its side.

    Notice that the client side error is "Negotiation timed out" and on the server side its "No policy configured". I think the problem is on the server side and the client just times out.

    I noticed you did all the troubleshooting steps on the client side. Could you please check on the DA server the IPsec rules in the wf.msc. Please make sure to check both the "Connection Security Rules" node and the "Monitoring\Connection Security Rules" node. You are looking for at least 2 rules (there could be more depending on your configurations) which start with "UAG DirectAccess Gateway -".

    My guess is that either they're missing in both locations (unlikely since you have them on the client) or they'll be missing from the "Monitoring\Connection Security Rules" node.
    In the latter case the cause could be that your Windows Firewall is turned off. The Windows Firewall must be turned on since it hosts the IPsec engine. Windows Firewall won't interfere with the TMG firewall since TMG disable all Windows Firewall rules and allows the IPsec rules to remain active.

    Eran.
    • Proposed as answer by Eran Ben-Shahar Tuesday, December 8, 2009 8:26 AM
    • Marked as answer by Erez Benari Tuesday, December 8, 2009 4:03 PM
    Tuesday, December 8, 2009 8:17 AM
  • Hi,

    TMG doesn't turn off Windows Firewall completely. All of the firewall rules are managed by TMG and not by windows firewall, but IPsec is still managed by Windows Firewall.

    You do not need to touch these settings. Windows firewall must be ON for IPsec to work. ICMP doesn't require IPsec, and that's why it works even when windows firewall is off.

    To check that windows firewall is indeed ON (this is enforced by the UAG DA GPO), please run the following command:

    netsh advfirewall show currentprofile

    You should see the following output in case it's on

    Public (or Private) Profile Settings:
    ----------------------------------------------------------------------
    State                                 ON

    Tuesday, May 18, 2010 9:10 AM

All replies

  • To add more info to this problem: I can ping internal resources through Teredo and IPHTTPS. One thing though is my CRL is not accessable from the outside, is this needed for toredo traffic? If it is do you need to create an exclusion in your NRPT for the CRL server?
    Friday, December 4, 2009 5:42 AM
  • Hi,

    You are correct to assume the problem is the IPSec. To know what is the exact issue, you can use the Windows7 networking troubleshooting.
    To use it:
    1. Right-click the network status indicator and select "Troubleshoot problems".
    2. Either enter a specific folder(first option), here you can use a net path to one of the DCs.
    3. Or select the "...different problem" and choose "Connect to your workplace using DirectAccess".
    4. The diagnostics will inform what caused the IPSec faliure.
    5. You can either post the results here, or try to resolve it yourself.(if its certificate or policy related)

    Max.
    Sunday, December 6, 2009 10:27 AM
  • Hi Max, thx for posting
    3. I selected connect to your workplace using Directaccess
    4. Diagnostics show a DNS error "The DNS server isn't responding"
    Troubleshooter created 2 etl log files that i need to grab a viewer for.
    Monday, December 7, 2009 4:46 AM
  • well I thought the SvcTraceViewer.exe was going to actually show me some info like a netmon capture but it does not look like it has any info in it or i have absolutely no idea how to use it (latter more likely).
    Still if I am not getting DNS its either the certificate not working to bring up the IPSEC tunnel or a firewall rule that is blocking. Does anyone know which exact rules are required to pass the IPSEC  connections on client and server?

    As a side note I do has a case open with MS but work stopped once i mentioned UAG as they do not support beta/rc, but UAG RTM'd Dec 4th so technically that does not apply anymore and i should get support.
    Monday, December 7, 2009 2:54 PM
  • Ok, following the Directaccess troubleshooting guide here http://technet.microsoft.com/en-us/library/ee624056(WS.10).aspx  I have collected some info that has got me closer. The question is what does "unknown authentication" and "no policy configured" mean?


    STEP 2

    netsh namespace show policy

    DNS Name Resolution Policy Table Settings

    Settings for oracle.domain.com
    ----------------------------------------------------------------------
    Certification authority                 : DC=com, DC=domainr, CN=domainServices
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Bypass proxy

     

    Settings for directaccess.domain.com
    ----------------------------------------------------------------------
    Certification authority                 : DC=com, DC=domain, CN=domainServices
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Bypass proxy

     

    Settings for .domain.com
    ----------------------------------------------------------------------
    Certification authority                 : DC=com, DC=domain, CN=domainServices
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              : 2002:xxxx:9fa7::xxxx:9fa7
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Bypass proxy

     

     

     


    STEP 3

    netsh namespace show effective

    DNS Effective Name Resolution Policy Table Settings


    Settings for oracle.domain.com
    ----------------------------------------------------------------------
    Certification authority                 : DC=com, DC=domain, CN=domainServices
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Bypass proxy

     

    Settings for directaccess.domain.com
    ----------------------------------------------------------------------
    Certification authority                 : DC=com, DC=domain, CN=domainServices
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Bypass proxy

     

    Settings for .domain.com
    ----------------------------------------------------------------------
    Certification authority                 : DC=com, DC=domain, CN=domainServices
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              : 2002:xxxx:9fa7::xxxx:9fa7
    DirectAccess (Proxy Settings)           : Bypass proxy

     

     

     

    STEP 4
    ping 2002:xxxx:9fa7::xxxx:9fa7
    YES 4 replys

     

     


    STEP 5

    nslookup -q=aaaa enterprise.domain.com 2002:xxxx:9
    fa6:8000:0:5efe:192.168.26.15
    DNS request timed out.
        timeout was 2 seconds.
    Server:  UnKnown
    Address:  2002:xxxx:9fa6:8000:0:5efe:192.168.26.15

    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    *** Request to UnKnown timed-out

     

     

    Directaccess Client cannot Establish to the Directaccess Server

    3. yes 4 rules exist
    clients access enabling tunnel
    clients corp tunnel
    clients DNS tunnel
    exempt NLA

    4. Yes same four noted in 3.

    5. Public profile:
    Unidentified network
    Ok

    6. netsh advfirewall monitor show mmsa
    No SAs match the specific criteria.

    7. netsh advfirewall monitor show qmsa
    No SAs match the specific criteria.

    Personal/certificates shows machine cert for Client
    Trusted Root Cert Auth/Certificates has root CA cert

     

     


    Client Side windows/security error logs with auditing IPSEC


    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/7/2009 6:19:49 PM
    Event ID:      4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      directaccesstest.domain.com
    Description:
    An IPsec main mode negotiation failed.

    Local Endpoint:
     Local Principal Name: -
     Network Address: 2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 2002:xxxx:9fa7::xxxx:9fa7
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: Unknown authentication
     Role:   Initiator
     Impersonation State: Not enabled
     Main Mode Filter ID: 96588

    Failure Information:
     Failure Point:  Local computer
     Failure Reason:  Negotiation timed out

     State:   Sent first (SA) payload
     Initiator Cookie:  7185696bc2cdc3bf
     Responder Cookie: 0000000000000000
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4653</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12547</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2009-12-08T01:19:49.306259200Z" />
        <EventRecordID>2799</EventRecordID>
        <Correlation />
        <Execution ProcessID="420" ThreadID="3296" />
        <Channel>Security</Channel>
        <Computer>directaccesstest.domain.com</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="LocalMMPrincipalName">-</Data>
        <Data Name="RemoteMMPrincipalName">-</Data>
        <Data Name="LocalAddress">2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0</Data>
        <Data Name="LocalKeyModPort">500</Data>
        <Data Name="RemoteAddress">2002:xxxx:9fa7::xxxx:9fa7</Data>
        <Data Name="RemoteKeyModPort">500</Data>
        <Data Name="KeyModName">%%8223</Data>
        <Data Name="FailurePoint">%%8199</Data>
        <Data Name="FailureReason">Negotiation timed out
    </Data>
        <Data Name="MMAuthMethod">%%8194</Data>
        <Data Name="State">%%8202</Data>
        <Data Name="Role">%%8205</Data>
        <Data Name="MMImpersonationState">%%8217</Data>
        <Data Name="MMFilterID">96588</Data>
        <Data Name="InitiatorCookie">7185696bc2cdc3bf</Data>
        <Data Name="ResponderCookie">0000000000000000</Data>
      </EventData>
    </Event>

     

     

     

     


    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/7/2009 6:19:54 PM
    Event ID:      4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      directaccesstest.domain.com
    Description:
    An IPsec main mode negotiation failed.

    Local Endpoint:
     Local Principal Name: -
     Network Address: 2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 2002:xxxx:9fa7::xxxx:9fa7
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: IKEv1
     Authentication Method: Unknown authentication
     Role:   Initiator
     Impersonation State: Not enabled
     Main Mode Filter ID: 0

    Failure Information:
     Failure Point:  Local computer
     Failure Reason:  No policy configured

     State:   No state
     Initiator Cookie:  2910ccee2d342b10
     Responder Cookie: 0000000000000000
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4653</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12547</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2009-12-08T01:19:54.073113600Z" />
        <EventRecordID>2800</EventRecordID>
        <Correlation />
        <Execution ProcessID="420" ThreadID="3296" />
        <Channel>Security</Channel>
        <Computer>directaccesstest.domain.com</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="LocalMMPrincipalName">-</Data>
        <Data Name="RemoteMMPrincipalName">-</Data>
        <Data Name="LocalAddress">2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0</Data>
        <Data Name="LocalKeyModPort">500</Data>
        <Data Name="RemoteAddress">2002:xxxx:9fa7::xxxx:9fa7</Data>
        <Data Name="RemoteKeyModPort">500</Data>
        <Data Name="KeyModName">%%8222</Data>
        <Data Name="FailurePoint">%%8199</Data>
        <Data Name="FailureReason">No policy configured
    </Data>
        <Data Name="MMAuthMethod">%%8194</Data>
        <Data Name="State">%%8201</Data>
        <Data Name="Role">%%8205</Data>
        <Data Name="MMImpersonationState">%%8217</Data>
        <Data Name="MMFilterID">0</Data>
        <Data Name="InitiatorCookie">2910ccee2d342b10</Data>
        <Data Name="ResponderCookie">0000000000000000</Data>
      </EventData>
    </Event>

     

     

     

    Server Side windows/security error logs with auditing IPSEC

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/7/2009 6:19:57 PM
    Event ID:      4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      DIRECTACCESS.domain.com
    Description:
    An IPsec main mode negotiation failed.

    Local Endpoint:
     Local Principal Name: -
     Network Address: 2002:xxxx:9fa7::xxxx:9fa7
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: Unknown authentication
     Role:   Responder
     Impersonation State: Not enabled
     Main Mode Filter ID: 0

    Failure Information:
     Failure Point:  Local computer
     Failure Reason:  No policy configured

     State:   No state
     Initiator Cookie:  4af2a30639c58b41
     Responder Cookie: 9cfa09787de841cb
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4653</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12547</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2009-12-08T01:19:57.728051700Z" />
        <EventRecordID>17067</EventRecordID>
        <Correlation />
        <Execution ProcessID="424" ThreadID="520" />
        <Channel>Security</Channel>
        <Computer>DIRECTACCESS.domain.com</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="LocalMMPrincipalName">-</Data>
        <Data Name="RemoteMMPrincipalName">-</Data>
        <Data Name="LocalAddress">2002:xxxx:9fa7::xxxx:9fa7</Data>
        <Data Name="LocalKeyModPort">500</Data>
        <Data Name="RemoteAddress">2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0</Data>
        <Data Name="RemoteKeyModPort">500</Data>
        <Data Name="KeyModName">%%8223</Data>
        <Data Name="FailurePoint">%%8199</Data>
        <Data Name="FailureReason">No policy configured
    </Data>
        <Data Name="MMAuthMethod">%%8194</Data>
        <Data Name="State">%%8201</Data>
        <Data Name="Role">%%8206</Data>
        <Data Name="MMImpersonationState">%%8217</Data>
        <Data Name="MMFilterID">0</Data>
        <Data Name="InitiatorCookie">4af2a30639c58b41</Data>
        <Data Name="ResponderCookie">9cfa09787de841cb</Data>
      </EventData>
    </Event>

     

     

     

     

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/7/2009 6:19:58 PM
    Event ID:      4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      DIRECTACCESS.domain.com
    Description:
    An IPsec main mode negotiation failed.

    Local Endpoint:
     Local Principal Name: -
     Network Address: 2002:xxxx:9fa7::xxxx:9fa7
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: Unknown authentication
     Role:   Responder
     Impersonation State: Not enabled
     Main Mode Filter ID: 0

    Failure Information:
     Failure Point:  Local computer
     Failure Reason:  No policy configured

     State:   No state
     Initiator Cookie:  4af2a30639c58b41
     Responder Cookie: cf6687b58d65936f
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4653</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12547</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2009-12-08T01:19:58.896051700Z" />
        <EventRecordID>17068</EventRecordID>
        <Correlation />
        <Execution ProcessID="424" ThreadID="520" />
        <Channel>Security</Channel>
        <Computer>DIRECTACCESS.domain.com</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="LocalMMPrincipalName">-</Data>
        <Data Name="RemoteMMPrincipalName">-</Data>
        <Data Name="LocalAddress">2002:xxxx:9fa7::xxxx:9fa7</Data>
        <Data Name="LocalKeyModPort">500</Data>
        <Data Name="RemoteAddress">2002:xxxx:9fa6:8100:945f:yyyy:640f:e3c0</Data>
        <Data Name="RemoteKeyModPort">500</Data>
        <Data Name="KeyModName">%%8223</Data>
        <Data Name="FailurePoint">%%8199</Data>
        <Data Name="FailureReason">No policy configured
    </Data>
        <Data Name="MMAuthMethod">%%8194</Data>
        <Data Name="State">%%8201</Data>
        <Data Name="Role">%%8206</Data>
        <Data Name="MMImpersonationState">%%8217</Data>
        <Data Name="MMFilterID">0</Data>
        <Data Name="InitiatorCookie">4af2a30639c58b41</Data>
        <Data Name="ResponderCookie">cf6687b58d65936f</Data>
      </EventData>
    </Event>

    Tuesday, December 8, 2009 5:05 AM
  • It does look like a machine certificate issue.
    You can check out the section conserning the machine certificate in http://blogs.technet.com/edgeaccessblog/archive/2009/10/27/deep-dive-into-uag-directaccess-certificates.aspx

    Generally speaking you need both the client machine and the server machine have a valid certificate issued by the authority selected during the configuration stage.

    Max.
    Tuesday, December 8, 2009 7:32 AM
  • "Unknown authentication" means certificates authentication which is the first type of authentication.
    "No policy configured" means the machine got a request to negotiate IPsec but couldn't find a matching IPsec rule on its side.

    Notice that the client side error is "Negotiation timed out" and on the server side its "No policy configured". I think the problem is on the server side and the client just times out.

    I noticed you did all the troubleshooting steps on the client side. Could you please check on the DA server the IPsec rules in the wf.msc. Please make sure to check both the "Connection Security Rules" node and the "Monitoring\Connection Security Rules" node. You are looking for at least 2 rules (there could be more depending on your configurations) which start with "UAG DirectAccess Gateway -".

    My guess is that either they're missing in both locations (unlikely since you have them on the client) or they'll be missing from the "Monitoring\Connection Security Rules" node.
    In the latter case the cause could be that your Windows Firewall is turned off. The Windows Firewall must be turned on since it hosts the IPsec engine. Windows Firewall won't interfere with the TMG firewall since TMG disable all Windows Firewall rules and allows the IPsec rules to remain active.

    Eran.
    • Proposed as answer by Eran Ben-Shahar Tuesday, December 8, 2009 8:26 AM
    • Marked as answer by Erez Benari Tuesday, December 8, 2009 4:03 PM
    Tuesday, December 8, 2009 8:17 AM
  • Hey Eran,

    i too face the same issue and in my setup in the DA server if i go to Monitoring\Connection Security Rules in wf.msc the rules are missing. but it is available in the connection Security rules. Checked to see if the windows firewall is off but it is turned on. Is there any thing else that we should start or run to get the rules in the path Monitoring\Connection Security Rules.

    Kindly help in this regard.

    thanks and appreciate in advance!!!

    Rajesh
    Regards, R@j
    Wednesday, February 3, 2010 11:54 PM
  • Hey Rajesh,

    When you say the windows firewall is turned on, which profiles are actaully active?
    The UAG-DA IPsec rules are configured to work only on the private/public profiles. If for some reason, none of the NICs on your DA server are identified as private or public then the IPsec rules won't be active.
    Please run the following command and share the output:
    netsh adv mon show current

    Thanks,
    Eran.
    Thursday, February 4, 2010 8:15 AM
  • Having exact same problem as Jackal99 - and my da client troubleshooting steps have yielded the same results.

    Per Eran's recommendations, I checked the connection security rules and monitoring\connection security rules.  Both have the following:
    DirectAccess Policy-DaServerToCorp
    DirectAccess Policy-DaServerToDnsDc

    Is that correct?

    I've been searching the web for days looking for help on direct access setup and this thread describes my problems as well.  I appreciate any insight.

    When client is on the internet, I can ping the IPv6 address of internal servers including app1 and dc1, but I can't ping the DNS names.  netsh advfirewall monitor show qmsa and mmsa yield no security associations on both the da client and da server.  can't access internal file server or websites.
    Thursday, February 4, 2010 9:44 PM
  • Not sure if thei helps, but I appear to be able to reproduce a problem like that with our system.  From a DA Client if I open a VPN connection to the office I am and I am unable to access anything.  Just as described though I am able to ping the internal servers using IPv6, but that is all I can do.  Once I reboot the DA client it connects again and everything works with DA.  

    I am thinking that when I open the VPN it can see the DA test URL and thinks it is internal so it stops, but then the DA DNS seems to take precedence over the VPN Connection so even with the VPN open I can't access anything by name i have to use IP addresses.

    Like I said not sure if that helps at all.
    Friday, February 5, 2010 12:23 AM
  • well I thought the SvcTraceViewer.exe was going to actually show me some info like a netmon capture but it does not look like it has any info in it or i have absolutely no idea how to use it (latter more likely).
    Still if I am not getting DNS its either the certificate not working to bring up the IPSEC tunnel or a firewall rule that is blocking. Does anyone know which exact rules are required to pass the IPSEC  connections on client and server?

    As a side note I do has a case open with MS but work stopped once i mentioned UAG as they do not support beta/rc, but UAG RTM'd Dec 4th so technically that does not apply anymore and i should get support.

    Check the Main Mode and Quick Mode output in the Monitoring Node on the client.
    Do you see NTLMv2 authenticated tunnels?
    Do you see Kerberos authenticated tunnels?

    I suspect that you're see NTLMv2 but no Kerberos.

    Do you have a computer certificate installed on the client? What entity issued the certificate? Is that the same entity that issued by UAG server's machine certificate?

    Thanks!
    Tom
    MS ISDUA Anywhere Access Team
    Friday, February 5, 2010 4:16 PM
  • Eran,

    I'm having the same error messages, and in fact, my Windows Firewall on the DAS is turned off, and managed by TMG. Adding a group policy for the DAS only turning on the firewall for standard profile doesn't override TMG.

    Would you know how I might enable the Windows Firewall?

    Thanks.

    Monday, May 17, 2010 9:01 PM
  • Hi,

    TMG doesn't turn off Windows Firewall completely. All of the firewall rules are managed by TMG and not by windows firewall, but IPsec is still managed by Windows Firewall.

    You do not need to touch these settings. Windows firewall must be ON for IPsec to work. ICMP doesn't require IPsec, and that's why it works even when windows firewall is off.

    To check that windows firewall is indeed ON (this is enforced by the UAG DA GPO), please run the following command:

    netsh advfirewall show currentprofile

    You should see the following output in case it's on

    Public (or Private) Profile Settings:
    ----------------------------------------------------------------------
    State                                 ON

    Tuesday, May 18, 2010 9:10 AM
  • Not sure if thei helps, but I appear to be able to reproduce a problem like that with our system.  From a DA Client if I open a VPN connection to the office I am and I am unable to access anything.  Just as described though I am able to ping the internal servers using IPv6, but that is all I can do.  Once I reboot the DA client it connects again and everything works with DA.  

    I am thinking that when I open the VPN it can see the DA test URL and thinks it is internal so it stops, but then the DA DNS seems to take precedence over the VPN Connection so even with the VPN open I can't access anything by name i have to use IP addresses.

    Like I said not sure if that helps at all.


    Hi Dan,

    When you establish a VPN connection from the DA client, the DA client configuration will not long apply, since the DA client will be able to detect the Network Location Server and turn off the NRPT, in addition, it will be able to connect to the DC and enable the domain profile. Ping isn't protected by IPsec by default, so that's probably why you're able to ping internal resources without establishing the DA IPsec tunnels.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, May 18, 2010 3:10 PM
  • I have same problems with IPSEC tunnels. I founded a GPO which turns advanced firewall domain profile to disabled state and this policy is applied to UAG server. I block this policy inheritance to UAG box and now IPSEC works like charm! Thanks guys for guidance to solve my problem :D
    Wednesday, January 12, 2011 7:01 PM