locked
How to configure IP address filtering for DA clients? RRS feed

  • Question

  • Hi!

    We have Direct Access clients working and accessing intranet resources OK, including old IPv4 servers. There is, however, one Unix server in intranet that has IP address filtering applied. Currently, its access list contains the IP range containing all of the appropriate intranet Windows workstation IP's 192.168.0.10/24.

    The problem is that, the DA clients are unable to connect to that server.
    When watched with whatsmyip.org net site, the DA client shows an internet address 88.123.123.123.
    The UAG Direct Access server intranet-facing IP is 192.168.1.10.
    The access model in UAG DA is end-to-edge.

    How to configure the Unix server IP access list to allow also DA clients to connect?

    Kind regards,
    Kari

    Friday, September 10, 2010 7:40 AM

Answers

  • If you are using NAT64, the source IPv4 address for DA clients will be the IP address of the UAG internal (intranet) interfaces (or interfaces if you have several UAG servers). In your case, this should be 192.168.1.10.

    I assume here that the unix host is not configure with IPv6 addressing...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Kari O Monday, September 20, 2010 8:32 AM
    Friday, September 10, 2010 11:08 AM
  • You cannot use IPv4 addresses with DirectAccess, you will need to use names...

    You may need to create a new fake DNS record to achieve what you need, but ultimately the IPv4 address seen by Unix will be the IPv4 address of the UAG internal interface

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Erez Benari Wednesday, September 15, 2010 12:11 AM
    Monday, September 13, 2010 2:48 PM
  • If you create a fake A record in DNS (uxsrv1.corp.contoso.com) the DNS64/NAT64 components will automatically translate this into an IPv6 address and should allow the client to access the IPv4-only Unix resource.

    All the above IPv4 source IP address stuff above still applies...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Kari O Monday, September 20, 2010 8:31 AM
    Wednesday, September 15, 2010 7:44 PM
  • Now I got more info of the problem when I traced traffic with MS Network Monitor on DA server:

    With net view \\uxsrv1 command, the DA client only tries TCP 445 connection (six times within ten seconds) and then results in System error 53, the network path was not found.

    When tried on the DA console, the same command first tries three TCP 445 connections, then one UDP 137 and finally falls back to TCP 139 protocol, which succeeds.

    So the key question now is that, how to set the DA client to try TCP 139 connection, too?
    That would let the DA clients to connect to Unix UNC shares.

    • Marked as answer by Kari O Monday, September 20, 2010 8:32 AM
    Friday, September 17, 2010 7:40 AM

All replies

  • If you are using NAT64, the source IPv4 address for DA clients will be the IP address of the UAG internal (intranet) interfaces (or interfaces if you have several UAG servers). In your case, this should be 192.168.1.10.

    I assume here that the unix host is not configure with IPv6 addressing...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Kari O Monday, September 20, 2010 8:32 AM
    Friday, September 10, 2010 11:08 AM
  • Hmmm... I think that the source IPv4 address for DA clients is not the same as IP address of the UAG internal interface, at least in our configuration.

    I tested so that, after modifying the Unix server IP access list, I pinged the Unix server from the DA console, and it replied OK.
    However, when I pinged the Unix server from a DA client, only ping timeouts existed.

    AFAK, the NAT64 check box was checked by default, when we created the DA configuration, so it should not be that one.

    What should be done to correct the problem?

    Kind regards,
    Kari

    Friday, September 10, 2010 8:00 PM
  • Are you trying to ping the UNIX server by name or IPv4 address?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, September 10, 2010 11:01 PM
  • By IPv4. Btw, tomorrow I'm able to test it again. I guess that the DNS client caches or maybe TMG intranet configuration change delay may have affected the test and to be sure, I must confirm if there have been any side effects in the last test. Anyway, today I was able to ping the Unix from UAG console, and next night a reboot is scheduled on the UAG/DA server, so tomorrow I will test it again from the client.

    Monday, September 13, 2010 12:35 PM
  • You cannot use IPv4 addresses with DirectAccess, you will need to use names...

    You may need to create a new fake DNS record to achieve what you need, but ultimately the IPv4 address seen by Unix will be the IPv4 address of the UAG internal interface

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Erez Benari Wednesday, September 15, 2010 12:11 AM
    Monday, September 13, 2010 2:48 PM
  • Okay...
    Say the IP of the Unix server is 192.168.5.10, so do there have to be such A record in AD DC/DNS server:
    uxsrv1=192.168.5.10
    or something IPv6-alike?

    Wednesday, September 15, 2010 7:33 PM
  • If you create a fake A record in DNS (uxsrv1.corp.contoso.com) the DNS64/NAT64 components will automatically translate this into an IPv6 address and should allow the client to access the IPv4-only Unix resource.

    All the above IPv4 source IP address stuff above still applies...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Kari O Monday, September 20, 2010 8:31 AM
    Wednesday, September 15, 2010 7:44 PM
  • The Unix server IP access list and the source IP issue is now OK.
    All of the intranet Windows server UNC shares open to the DA clients OK, too.

    Anyway, there is something that prevents internet-connected DA clients to access Samba shares.

    When tested on the DA server console (or a DA client connected to LAN):

    C:\>ping uxsrv1
    Pinging uxsrv1.ad.local [192.168.5.10] with 32 bytes of data:
    Reply from 192.168.5.10: bytes=32 time=2ms TTL=250
    Reply from 192.168.5.10: bytes=32 time=2ms TTL=250
     :
    C:\>net view \\uxsrv1
    Shared resources at \\uxsrv1
     
    Share name  Type  Used as  Comment
    ----------------------------------------------------------------
    share1    Disk
    share2    Disk
    The command completed successfully.

    But when tested on a DA client in internet:
     
    C:\>ping uxsrv1
    Ping-isäntä: uxsrv1.ad.local [2002:d58a:8ffa:8001::c123:b123] 32 tavua tietoja:
    Vastaus isännältä 2002:d58a:8ffa:8001::c123:b123: aika=11 ms
    Vastaus isännältä 2002:d58a:8ffa:8001::c123:b123: aika=10 ms
     :
    Ping-tilastot 2002:d58a:8ffa:8001::c123:b123:
        Paketit: Lähetetty = 4, Vastaanotettu = 4, Kadonnut = 0
                 (0% hävikki),
    Arvioitu kiertoaika millisekunteina:
        Pienin = 9 ms, Suurin = 11 ms, Keskiarvo = 10 ms
     
    C:\>net view \\uxsrv1
    [System error 53.
    Network path was not found.]

    Could it be a LM authlevel issue? Remember that DA client accesses Unix shares OK when connected to LAN but not when connected to internet.

    How to debug this?

    Kind regards,
    Kari

    Thursday, September 16, 2010 3:32 PM
  • Not having much luck are you!

    Have you tried using the FQDN in the connection?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, September 16, 2010 3:44 PM
  • Yes, net view \\uxsrv1.ad.local results in same error (System path was not found)
    Thursday, September 16, 2010 4:06 PM
  • Now I got more info of the problem when I traced traffic with MS Network Monitor on DA server:

    With net view \\uxsrv1 command, the DA client only tries TCP 445 connection (six times within ten seconds) and then results in System error 53, the network path was not found.

    When tried on the DA console, the same command first tries three TCP 445 connections, then one UDP 137 and finally falls back to TCP 139 protocol, which succeeds.

    So the key question now is that, how to set the DA client to try TCP 139 connection, too?
    That would let the DA clients to connect to Unix UNC shares.

    • Marked as answer by Kari O Monday, September 20, 2010 8:32 AM
    Friday, September 17, 2010 7:40 AM
  • Hi Kari,

    Are you able to net view to any server?

    Check your Main Mode connections and see if any have KerberosV5 as the authentication method to see if your intranet tunnel is open.

    Or, if the UNIX server is a management server, put it in the management servers group.

    Are you able to ping by FQDN? Single label names will appendix the DNS suffix that is in the clients search list.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Tuesday, September 21, 2010 4:09 PM
  • Tom confirmed NetBIOS is not supported with IPv6 on the other thread :(

    Can you force the UNIX host to use CIFS (TCP445) as this should work with DA clients...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, September 21, 2010 9:30 PM
  • Jason,

    This is an interesting interoperability issue. I'll see if we have any information on this.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Wednesday, September 22, 2010 1:48 PM