Announcement

Collapse
No announcement yet.

DNS DHCP option 006 not being applied to VPN clients via RRAS

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • DNS DHCP option 006 not being applied to VPN clients via RRAS

    EDIT: The solution to this problem is found in post #4

    I have a Server 2003 SP2 machine that is running RRAS and is the endpoint for a PPTP VPN. The RRAS server is set to assign IP address using DHCP. The DHCP Server is a Small Business Server 2008 machine. The scope options are set up to hand out the SBS machine as the DNS server. When RRAS starts up on the 2003 server it grabs 10 DHCP leases from the SBS server. I can see those RRAS acquired leases in the Address Leases window in Server Manager (the icons of the leases that the RRAS server grabbed are different from other clients). However, when my Vista SP1 machine connects to the VPN I receive a different DNS server (which happens to be the LinkSys RV082 router).

    I've deleted all DHCP leases that RRAS claimed from the SBS server and then restarted the RRAS service on the 2003 machine. RRAS then successfully re-requested DHCP leases from the SBS machine. Connecting via the VPN still gives me a different DNS server than what is set in the scope options. I have checked the PPTP connectoid to make sure that no IP information is manually set. It is set to get both IP and DNS info via DHCP. DHCP clients on the LAN in the office receive the proper DNS server settings. I created a new VPN connectoid from scratch just to see what would happen. Nothing changed. What I find strange is that ipconfig /all shows this for both my original and newly created VPN connectoid:

    Code:
    PPP adapter AOI test for DHCP:
    
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : AOI test for DHCP
       Physical Address. . . . . . . . . :
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.168.119(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.255
       Default Gateway . . . . . . . . . : 0.0.0.0
       DNS Servers . . . . . . . . . . . : 192.168.168.1
       NetBIOS over Tcpip. . . . . . . . : Enabled
    Notice that the default gateway is missing and the "DHCP Enabled: No", but yet the connectoid's TCP/IPv4 properties show that both IP configuration and DNS servers are obtained automatically! Furthermore, if DHCP was truly disabled, I wouldn't even be getting any IP information, not wrong information.The above ipconfig output could be a red herring or it might be significant. I'm at a loss at the moment. What could possibly be the issue? Your thoughts are appreciated.

    --Wes

    P.S. I placed this in the general networking forum since I'm not sure if this is a server 2003 issue, a Vista issue or some other networking component's issue
    Last edited by Nonapeptide; 2nd May 2009, 02:10. Reason: Noticed something new ; edit #2 mentioned solution
    Wesley David
    LinkedIn | Careers 2.0
    -------------------------------
    Microsoft Certifications: MCSE 2003 | MCSA:Messaging 2003 | MCITP:EA, SA, EST | MCTS: a'plenty | MCDST
    Vendor Neutral Certifications: CWNA
    Blog: www.TheNubbyAdmin.com || Twitter: @Nonapeptide || GTalk, Reader and Google+: [email protected] || Skype: Wesley.Nonapeptide
    Goofy kitten avatar photo from Troy Snow: flickr.com/photos/troysnow/

  • #2
    Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

    I have exactly the same set up as you, W2K3 server running PPTP at the office using DHCP to assign vpn clients ip addresses and a Vista machine at home acting as the VPN client. I do get my work DNS servers as the DNS servers for the VPN connection so that seems OK for my VPN connection as opposed to yours.

    Like you though I do get DHCP enabled = no, which seems strange. If you look at the properties of the tcpv4 protocol of the connectoid it clearly is set for DHCP. Maybe this is a VPN anomoly as it's obvious that we're both getting valid addresses from the DHCP pool from the company DHCP server.

    As far as the default gateway is concerned that's normal as the default gateway is the VPN connection itself. I've pasted the output of the route print statement on my vista machine to illustrate the point. My home network is 192.168.1.0/24 and my work network is 64.28.42.0/26:

    IPv4 Route Table
    ================================================== =========================
    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.102 4245
    0.0.0.0 0.0.0.0 On-link 64.28.42.16 21
    64.28.42.0 255.255.255.192 On-link 64.28.42.16 21
    64.28.42.16 255.255.255.255 On-link 64.28.42.16 276
    64.28.42.40 255.255.255.255 192.168.1.1 192.168.1.102 4246
    64.28.42.63 255.255.255.255 On-link 64.28.42.16 276
    127.0.0.0 255.0.0.0 On-link 127.0.0.1 4531
    127.0.0.1 255.255.255.255 On-link 127.0.0.1 4531
    127.255.255.255 255.255.255.255 On-link 127.0.0.1 4531
    169.254.0.0 255.255.0.0 On-link 192.168.1.102 4521
    169.254.255.255 255.255.255.255 On-link 192.168.1.102 4501
    192.168.1.0 255.255.255.0 On-link 192.168.1.102 4501
    192.168.1.102 255.255.255.255 On-link 192.168.1.102 4501
    192.168.1.255 255.255.255.255 On-link 192.168.1.102 4501
    224.0.0.0 240.0.0.0 On-link 127.0.0.1 4531
    224.0.0.0 240.0.0.0 On-link 192.168.1.102 4504
    224.0.0.0 240.0.0.0 On-link 64.28.42.16 21
    255.255.255.255 255.255.255.255 On-link 127.0.0.1 4531
    255.255.255.255 255.255.255.255 On-link 192.168.1.102 4501
    255.255.255.255 255.255.255.255 On-link 64.28.42.16 276

    You'll notice that the second 0.0.0.0 route is On-Link and has a lower metric than the 192.168.1.1 gateway. This means that all traffic destined for a non-local address is going through the VPN connection. I confirmed this by performing a tracert to www.google.com and it went through the VPN connection and my work network.

    Comment


    • #3
      Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

      Originally posted by joeqwerty View Post
      As far as the default gateway is concerned that's normal as the default gateway is the VPN connection itself.
      It's funny how you take things for granted until stuff goes wrong. As soon as things go wrong, everything looks suspicious... "My default gateway, is it always like that?! And DHCP Enabled... is that in a client or server context?! Wait... what's "Autoconfiguration" anyways?! Split tunneling... why isn't that turned on?! What's that black helicopter doing outside my window?!"


      Originally posted by joeqwerty View Post
      I've pasted the output of the route print statement on my vista machine to illustrate the point. (snip)

      You'll notice that the second 0.0.0.0 route is On-Link and has a lower metric than the 192.168.1.1 gateway. This means that all traffic destined for a non-local address is going through the VPN connection. I confirmed this by performing a tracert to www.google.com and it went through the VPN connection and my work network.
      That's pretty much what my 'route print' looks like as well. That's also my experience with tracert. My remote IP is what shows up in tracert or www.ShowMyIP.com. I can surf around and connect to WAN resources via the VPN, it's just that DNS option isn't getting set as I would expect. For giggles, I ran dhcploc on the RRAS server and it shows the SBS machine as the only DHCP server in the subnet (as I suspected... and a rogue DHCP server was ruled out by some previous troubleshooting, but I like to be annoyingly thorough).

      Funny, I thought I had split tunneling set up... and that black helicopter isn't going away either.
      Wesley David
      LinkedIn | Careers 2.0
      -------------------------------
      Microsoft Certifications: MCSE 2003 | MCSA:Messaging 2003 | MCITP:EA, SA, EST | MCTS: a'plenty | MCDST
      Vendor Neutral Certifications: CWNA
      Blog: www.TheNubbyAdmin.com || Twitter: @Nonapeptide || GTalk, Reader and Google+: [email protected] || Skype: Wesley.Nonapeptide
      Goofy kitten avatar photo from Troy Snow: flickr.com/photos/troysnow/

      Comment


      • #4
        Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

        Here's what I found after doing some additional research:

        When I was testing my VPN connection I noticed that the DNS servers from my corporate office were listed twice.

        When a DHCP client boots up it normally sends a DHCPInform packet as part of the DHCP transaction. This DHCPInform packet is a request for DHCP options configured on the DHCP server, such as DNS servers, router, etc.

        I checked my RRAS server and saw that it was set up as a DHCP relay agent with the ip address of my DHCP server as the "destination" to send DHCP packets to.

        When I removed the DHCP relay agent option from the RRAS server I found that my VPN connection only had the company DNS servers listed once. On a hunch I changed the DNS servers configured on the TCP/IP properties of the NIC of the RRAS server and found that my VPN connection now listed these new DNS servers.

        When I reconfigured my RRAS server as a DHCP relay agent my VPN connection got both the DHCP server DNS servers as well as the RRAS server DNS servers.

        This leads me to the following conclusions:

        When the RRAS server is NOT configured as a DHCP relay agent it does not forward the DHCPInform packets from the VPN client to the DHCP server. The client does NOT receive any options that are configured on the DHCP server. The VPN client does receive the DNS servers configured on the RRAS server itself.

        When the RRAS server is configured as a DHCP relay agent it does forward the DHCPInform packets to the DHCP server, which then returns the DHCP options. The VPN client also gets the DNS servers configured on the RRAS server itself, which explains why my VPN connection listed both sets of DNS servers when the RRAS server was configured as a DHCP relay agent and only the RRAS server's DNS settings when it wasn't.

        So my questions to you are:

        1. Does the RRAS server have DNS servers configured on it's NIC TCP/IP Properties?

        2. Is the RRAS server configured as a DHCP relay agent with the correct DHCP server ip address plugged in?

        Comment


        • #5
          Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

          Wow, Joe. That was some great sleuthing.

          Originally posted by joeqwerty View Post
          1. Does the RRAS server have DNS servers configured on it's NIC TCP/IP Properties?
          Yes it does. The DNS server on the NIC is not the SBS server. I'm in the uncomfortable stage where I'm transitioning from a workgroup to a domain and some of those settings haven't been changed yet. Interesting, if I had changed the RRAS server's static DNS settings I might never have learned this valuable lesson.

          Originally posted by joeqwerty View Post
          2. Is the RRAS server configured as a DHCP relay agent with the correct DHCP server ip address plugged in?
          Ummm… it is now. It wasn't set up as a relay agent in the first place.

          Originally posted by joeqwerty View Post
          When the RRAS server is NOT configured as a DHCP relay agent it does not forward the DHCPInform packets from the VPN client to the DHCP server. The client does NOT receive any options that are configured on the DHCP server. The VPN client does receive the DNS servers configured on the RRAS server itself.
          That looks about right, but that makes me puzzled. That seems like rather dumb default behavior on the surface. Maybe there's something that I'm totally missing. Here's what puzzles me. Why is the RRAS service getting 10 DHCP leases from the DHCP server in the first place if the scope options aren't going to be applied anyway? Or are the leases only for IP address / subnet mask info and all other options are discarded. If that's the case… umm… why? (I’m composing a "Dear Microsoft," letter in my head as I type this )

          Actually, I do remember a long discussion that I had on Google Groups about a year ago where someone helped be understand that the configuration settings on the RRAS server are what is applied to the VPN connections. But for some reason that never entered my mind in this case because I was focused on the DHCP leases.





          Okay, so it looks like I'm getting the proper DNS settings applied to my VPN client now. Thanks for the help Joe! I may start a new thread however since even though I've got my PPTP adapter showing the proper DNS server, I still can't resolve names across the VPN. 'ping omega' doesn't resolve, but 'ping [ip]' works. Furthermore even when nslookup is shown as pointing to the remote office SBS server for DNS, putting in dns names (even the FQDN for the remote office computers, eg omega.domain.local) returns with my ISP's DNS suffix and a completely foreign IP address: omega.cinci.rr.com 208.69.36.132. *sigh*

          I need some more tea.
          Wesley David
          LinkedIn | Careers 2.0
          -------------------------------
          Microsoft Certifications: MCSE 2003 | MCSA:Messaging 2003 | MCITP:EA, SA, EST | MCTS: a'plenty | MCDST
          Vendor Neutral Certifications: CWNA
          Blog: www.TheNubbyAdmin.com || Twitter: @Nonapeptide || GTalk, Reader and Google+: [email protected] || Skype: Wesley.Nonapeptide
          Goofy kitten avatar photo from Troy Snow: flickr.com/photos/troysnow/

          Comment


          • #6
            Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

            OK, I've never figured out the whole "quote" thing so I'm going to cut and paste some of your post in bold font and my thoughts in regular font:


            That looks about right, but that makes me puzzled. That seems like rather dumb default behavior on the surface. Maybe there's something that I'm totally missing. Here's what puzzles me. Why is the RRAS service getting 10 DHCP leases from the DHCP server in the first place if the scope options aren't going to be applied anyway? Or are the leases only for IP address / subnet mask info and all other options are discarded.

            The RRAS server will acquire as many ip addresses as it is configured for ports, so if you have 5 PPTP ports and 5 LT2P ports it will acquire 10 ip addresses for connections and it will acquire one additional ip address if the RRAS server is configured for routing. As far as getting the addresses and not the options, the RRAS server acts as a sort of proxy for the VPN client and acquires ip addresses (before any client ever connects) on behalf of the client without acting as a client itself. The normal DHCP transaction that's performed between a LAN client and a DHCP server is not performed because the VPN client has no way of sending the normal DHCP UDP broadcasts to the DHCP server until it has a DHCP address from the RRAS server and therefore a connection to the internal network. After it acquires an ip address from the RRAS server it's able to send the DHCPInform packet to the DHCP server to get the options by way of the RRAS server's DHCP relay agent if it's configured to be a relay agent. If the RRAS server is not configured as a DHCP relay agent then it gives the VPN client an ip address from the pool it has acquired from the DHCP server on behalf of the VPN clients (PPTP and L2TP ports). The reason the VPN client gets the DNS servers that are configured on the RRAS server itself is because the DHCP relay agent option is not required and the VPN client has to get DNS servers from somewhere, so the RRAS server gives the client it's DNS servers.


            Okay, so it looks like I'm getting the proper DNS settings applied to my VPN client now. Thanks for the help Joe! I may start a new thread however since even though I've got my PPTP adapter showing the proper DNS server, I still can't resolve names across the VPN. 'ping omega' doesn't resolve, but 'ping [ip]' works. Furthermore even when nslookup is shown as pointing to the remote office SBS server for DNS, putting in dns names (even the FQDN for the remote office computers, eg omega.domain.local) returns with my ISP's DNS suffix and a completely foreign IP address: omega.cinci.rr.com 208.69.36.132. *sigh*

            Try running a tracert to the ip address and FQDN and see if the packets take different paths. You can also run a packet sniffer from the VPN client, from the RRAS server, and from the internal DNS server to watch the DNS queries to see where they're coming from and where there going to when you try to resolve internal names from the VPN client.

            Long winded I know, but this is an interesting one. Once I get my teeth into something I usually don't let go until I'm either satisfied that I understand it completely or I'm satisfied that I've done everything I can to understand it but don't (some things are just beyond me and a man has to know his limitations).
            Last edited by joeqwerty; 2nd May 2009, 04:59.

            Comment


            • #7
              Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

              Originally posted by joeqwerty View Post
              OK, I've never figured out the whole "quote" thing
              I just hit the "quote" button when replying to the post and then copy and paste the [QUOTE=(nickname);(PostID)] tag for each consequitive quote. Thusly, it would look like this: (I had to use parenthesis instead of brackets since vBulletin tags get formatted even in code blocks)
              Code:
               (QUOTE=joeqwerty;161423)Blah blah blah.(/quote)
              You don't say!
              (QUOTE=joeqwerty;161423)Blah blah blah!(/quote)
              Bork bork bork!
              I also use Word to type my posts in since I've had more than one occasion of a lengthy, detailed post getting blown away by browser mishaps. Moving on…

              Originally posted by joeqwerty View Post
              The RRAS server will acquire as many ip addresses as it is configured for ports, so if you have 5 PPTP ports and 5 LT2P ports it will acquire 10 ip addresses for connections and it will acquire one additional ip address if the RRAS server is configured for routing.
              Okay. I thought it retrieved DHCP addresses in blocks of 10. For instance, I've got the default 127 L2TP and 127 PPTP ports (and one PPPOE port) in my RRAS console but only 10 DHCP leases are taken at a time. No big deal, I guess.

              Originally posted by joeqwerty View Post
              As far as getting the addresses and not the options, the RRAS server acts as a sort of proxy for the VPN client and acquires ip addresses (before any client ever connects) on behalf of the client without acting as a client itself.
              Yeah… see, I thought that it would also pass the other scope options to the VPN clients but apparently that's not the case…

              Originally posted by joeqwerty View Post
              The normal DHCP transaction that's performed between a LAN client and a DHCP server is not performed because the VPN client has no way of sending the normal DHCP UDP broadcasts to the DHCP server until it has a DHCP address from the RRAS server and therefore a connection to the internal network. After it acquires an ip address from the RRAS server it's able to send the DHCPInform packet to the DHCP server to get the options by way of the RRAS server's DHCP relay agent if it's configured to be a relay agent.
              I think this is where the crux of my misunderstanding lies. I was expecting the full DHCP scope options to be retrieved and retained by the RRAS server in the first place when it reserves it's batch of leases. I didn't expect their to be a necessity for the DHCPInform packet to pass directly from the client to the DHCP server (because, in my mind, the expected behavior was for the RRAS server to use the DHCPInform packet and then retain the retrieved options and apply them to the VPN client upon connection).

              Originally posted by joeqwerty View Post
              If the RRAS server is not configured as a DHCP relay agent then it gives the VPN client an ip address from the pool it has acquired from the DHCP server on behalf of the VPN clients (PPTP and L2TP ports). The reason the VPN client gets the DNS servers that are configured on the RRAS server itself is because the DHCP relay agent option is not required and the VPN client has to get DNS servers from somewhere, so the RRAS server gives the client it's DNS servers.
              At the risk of being annoying to lots of folks, it still seems counterintuitive. In my mind (strange place that it is), I expected the all scope options to be retrieved and… oh wait, I think I've beaten that equine to death. I'll get off it now.

              Originally posted by joeqwerty View Post
              Try running a tracert to the ip address and FQDN and see if the packets take different paths.
              Tracert to omega's IP from VPN client to the remote LAN is just two hops:
              1. RRAS Server [192.1686.168.120] (I just noticed that that IP is in the range taken from the DHCP server, and not the static IP on the LAN. Strange how there are some things that you never notice.)
              2. Omega [192.168.168.6]

              So that looks nice and normal. Until…

              Tracert omega.domain.local
              "Unable to resolve target system name omega.alphaomega.local."

              Here's some ipconfig /all info from the VPN client. I know, it looks ugly in code brackets since it just keeps running to the right without wrapping around. I made some notes too:
              Code:
               C:\Users\Wesley>ipconfig /all
              
              Windows IP Configuration
              
                 Host Name . . . . . . . . . . . . : Neuro
                 Primary Dns Suffix  . . . . . . . :
                 Node Type . . . . . . . . . . . . : Hybrid
                 IP Routing Enabled. . . . . . . . : No
                 WINS Proxy Enabled. . . . . . . . : No
                 DNS Suffix Search List. . . . . . : remotedomain.
                                                     cinci.rr.com
              
              PPP adapter AOI Temp:
              
                 Connection-specific DNS Suffix  . : remotedomain.local (Good!)
                 Description . . . . . . . . . . . : AOI Temp
                 Physical Address. . . . . . . . . : (I didn't edit this out. Nothing was here.)
                 DHCP Enabled. . . . . . . . . . . : No
                 Autoconfiguration Enabled . . . . : Yes
                 IPv4 Address. . . . . . . . . . . : 192.168.168.119(Preferred)
                 Subnet Mask . . . . . . . . . . . : 255.255.255.255
                 Default Gateway . . . . . . . . . : 0.0.0.0
                 DNS Servers . . . . . . . . . . . : 192.168.168.6 (Remote SBS Server. This is good.)
                                                     192.168.168.1 (Remote LinkSys Gateway. If I can replace this with a small SonicWall TZ device, I'll beat this LinkSys with a bat. Sorry Biggles. :) )
                 NetBIOS over Tcpip. . . . . . . . : Enabled
              
              Wireless LAN adapter Wireless Network Connection: (This is the adapter on my laptop that is actively connecting me to the interwebs. The physical LAN port is not used.)
              
                 Connection-specific DNS Suffix  . : cinci.rr.com (Go Reds! And take the Bengals with you!!)
                 Description . . . . . . . . . . . : Intel(R) Wireless WiFi Link 4965AGN
                 Physical Address. . . . . . . . . : 00-1D-E0-50-CC-E5
                 DHCP Enabled. . . . . . . . . . . : Yes
                 Autoconfiguration Enabled . . . . : Yes
                 Link-local IPv6 Address . . . . . : fe80::54c2:be82:f65f:6552%10(Preferred)
                 IPv4 Address. . . . . . . . . . . : 192.168.11.101(Preferred)
                 Subnet Mask . . . . . . . . . . . : 255.255.255.0
                 Lease Obtained. . . . . . . . . . : Friday, May 01, 2009 11:38:26 AM
                 Lease Expires . . . . . . . . . . : Saturday, May 02, 2009 11:38:23 AM
                 Default Gateway . . . . . . . . . : 192.168.11.1
                 DHCP Server . . . . . . . . . . . : 192.168.11.1
                 DNS Servers . . . . . . . . . . . : 65.24.7.10 (Cinci.rr's DNS server. Strange, I thought I set my DNS servers to OpenDNS… hmmm…)
                                                     65.24.7.11
                 NetBIOS over Tcpip. . . . . . . . : Enabled
              Originally posted by joeqwerty View Post
              You can also run a packet sniffer from the VPN client, from the RRAS server, and from the internal DNS server to watch the DNS queries to see where they're coming from and where there going to when you try to resolve internal names from the VPN client. Long winded, I know, but this is an interesting one. Once I get my teeth into something I usually don't let go until I'm either satisfied that I understand completely it or satisfied that I've done everything I can to understand it but can't (some things are beyond me and a man has to know his limitations).
              Okay, here's what I've noticed. And before I get started, I'm thinking this is now moving to an SBS 2008 issue more than anything else. This may have to get fractured and moved to a new forum. Anyways… If I launch nslookup on the VPN client (now the remote office's SBS server is properly listed as my default DNS server. Yay!), set it to "d2" mode (exhaustive debugging) and type 'omega' I ultimately get this returned (I'll not post the whole results):
              Code:
               Name:    omega.cinci.rr.com
              Address:  208.69.36.132
              However, here's where I think it gets really weird. On computers in the remote office who do not have a DHCP lease or reservation on the SBS server, the result of any query for a local DNS name (leftmost name or the FQDN) always results in rcode = SERVFAIL. However, if I then give that computer a DHCP reservation (I use reservations in that small office to make remembering everyone's IP easier) or just a regular old DHCP lease the DNS query works perfectly and I can resolve local DNS names. I can always resolve public DNS names regardless of where a computer got it's IP from. I should also say that I use forwarders on the DNS server (OpenDNS).

              I searched around to no avail so far. I found this sort-of related article. As a result I turned off root hints and restarted the DNS services. No change. I didn't dare go tweaking the registry just yet.

              Also of note: no computers have been officially joined to the domain yet. However, that seems of little importance to me since any computer should be able to use that server as the DNS server and get name resolution for local DNS records. Indeed, in this business that is a necessity since not all computers that will VPN into the network are or can be members of the domain.

              Ultimately, it seems that there is some kind of protective measure turned on on the SBS machine that only allows certain machines to query for local DNS records. Even the RRAS server itself can't get the SBS machine to resolve local records since it has static IP info (and hasn't yet been made a member of the domain… I'm not sure yet if domain membership affects this issue any). I'm going to ruminate on this and tackle it on Monday. Always nice to have something to look forward to after the weekend…
              Wesley David
              LinkedIn | Careers 2.0
              -------------------------------
              Microsoft Certifications: MCSE 2003 | MCSA:Messaging 2003 | MCITP:EA, SA, EST | MCTS: a'plenty | MCDST
              Vendor Neutral Certifications: CWNA
              Blog: www.TheNubbyAdmin.com || Twitter: @Nonapeptide || GTalk, Reader and Google+: [email protected] || Skype: Wesley.Nonapeptide
              Goofy kitten avatar photo from Troy Snow: flickr.com/photos/troysnow/

              Comment


              • #8
                Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

                I'm going to stick with my copy, paste, and bold method.

                Okay. I thought it retrieved DHCP addresses in blocks of 10. For instance, I've got the default 127 L2TP and 127 PPTP ports (and one PPPOE port) in my RRAS console but only 10 DHCP leases are taken at a time. No big deal, I guess.

                That make sense. I only have 3 PPTP ports, so my RRAS server only acquires 4 ip addresses. If you have more than 10 ports it looks like it acquires 10 ip addresses at a time.

                Yeah… see, I thought that it would also pass the other scope options to the VPN clients but apparently that's not the case…

                It does seem counterintuitive but maybe it's because of how the RRAS server "holds" the ip addresses it acquires from the DHCP server. Maybe it holds them in memory or in a temporary file.

                I think this is where the crux of my misunderstanding lies. I was expecting the full DHCP scope options to be retrieved and retained by the RRAS server in the first place when it reserves it's batch of leases. I didn't expect their to be a necessity for the DHCPInform packet to pass directly from the client to the DHCP server (because, in my mind, the expected behavior was for the RRAS server to use the DHCPInform packet and then retain the retrieved options and apply them to the VPN client upon connection).

                Again, this seems counterintuitive but I can confirm from my network traces that upon start up the RRAS server only sends the DHCPdiscover and DHCPRequest packets to the DHCP server. This happens when you start the RRAS service. When you stop the RRAS service any ip addresses acquired by the RRAS server are released. I can confirm from my network traces that when the VPN client connects to the RRAS server the VPN client sends the DHCPInform packet to the DHCP server, which then sends the DHCP scope options to the VPN client.

                Tracert to omega's IP from VPN client to the remote LAN is just two hops:
                1. RRAS Server [192.1686.168.120] (I just noticed that that IP is in the range taken from the DHCP server, and not the static IP on the LAN. Strange how there are some things that you never notice.)
                2. Omega [192.168.168.6]

                So that looks nice and normal. Until…


                That occurs if the RRAS server is configured for routing on the IP tab of the RRAS server properties. The RRAS server has to acquire an ip address from the DHCP server for it's PPP Wan interface because it's the endpoint of the VPN connection and in order to provide routing for the VPN client the RRAS server has to have an interface and an ip address on the same network as the VPN client, otherwise routing wouldn't work. Note that the PPP Wan interface is only active when a VPN client is connected.

                Tracert omega.domain.local
                "Unable to resolve target system name omega.alphaomega.local."


                That is strange. Here's what I found in my testing: When I initially connected my VPN client to the RRAS server I was able to run nslookup and resolve internal single label or FQDN names with no problem. I then ran ipconfig/flushdns on my internal DNS servers and was no longer able to resolve internal names from the VPN client. At this point I ran a packet capture on my internal DNS server and filtered on DNS packets. I connected the VPN client and ran nslookup and performed a query for an internal host. On the DNS server I looked at the DNS query from the VPN client and saw that it came back as "Query for rsitshost.neo.rr.com" (rsitshost is an internal host). So it seems that RoadRunner appends the neo.rr.com amd rr.com suffixes to DNS queries that go through it's network. (I have Time Warner cable internet at home, which is RoadRunner). This is pretty strange as all my home hosts use my wireless router for DNS, which itself is comfigured to use OpenDNS for it's DNS. This doesn't explain why my earlier queries worked though. I'm stumped on the DNS aspect at this point...

                This has certainly given me something interesting to puzzle about this weekend, although with family, yard work, etc. I haven't had much time to tinker with this. Priorities and such...

                Comment


                • #9
                  Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

                  Originally posted by joeqwerty View Post
                  That is strange. Here's what I found in my testing: When I initially connected my VPN client to the RRAS server I was able to run nslookup and resolve internal single label or FQDN names with no problem. I then ran ipconfig/flushdns on my internal DNS servers and was no longer able to resolve internal names from the VPN client. At this point I ran a packet capture on my internal DNS server and filtered on DNS packets. I connected the VPN client and ran nslookup and performed a query for an internal host. On the DNS server I looked at the DNS query from the VPN client and saw that it came back as "Query for rsitshost.neo.rr.com" (rsitshost is an internal host). So it seems that RoadRunner appends the neo.rr.com amd rr.com suffixes to DNS queries that go through it's network. (I have Time Warner cable internet at home, which is RoadRunner). This is pretty strange as all my home hosts use my wireless router for DNS, which itself is comfigured to use OpenDNS for it's DNS. This doesn't explain why my earlier queries worked though. I'm stumped on the DNS aspect at this point...

                  This has certainly given me something interesting to puzzle about this weekend, although with family, yard work, etc. I haven't had much time to tinker with this. Priorities and such...
                  Yeah. I'm baffled. What puzzles me further is that my VPN connection is not a split tunnel set up. Every bit of network traffic that goes from my computer to something other than my local subnet will be passed through my VPN connection. So, Road Runner shouldn't be able to append anything since it's all encrypted traffic. That makes me wonder if it's some kind of behavior that our Windows clients are doing… ? I haven't had a chance to look into it, but I thought I'd toss that thought out.
                  Wesley David
                  LinkedIn | Careers 2.0
                  -------------------------------
                  Microsoft Certifications: MCSE 2003 | MCSA:Messaging 2003 | MCITP:EA, SA, EST | MCTS: a'plenty | MCDST
                  Vendor Neutral Certifications: CWNA
                  Blog: www.TheNubbyAdmin.com || Twitter: @Nonapeptide || GTalk, Reader and Google+: [email protected] || Skype: Wesley.Nonapeptide
                  Goofy kitten avatar photo from Troy Snow: flickr.com/photos/troysnow/

                  Comment


                  • #10
                    Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

                    Hello,

                    I have almost the same problem, but our RAS clients don't receive any of DHCP options.

                    Here is my configuration:
                    - RAS server on Windows Server 2008 SP2 Enterprise x64: configured as VPN and NAT (LAN IP address: 172.16.0.2, WAN: 194.xxx.xxx.xxx)
                    - DHCP server on Windows Server 2008 Enterprise x64 (LAN IP: 172.16.0.2)

                    On RAS Server I've added LAN interface (which is connected to my DHCP server) to DHCP Relay Agent list, so now there are both - my LAN interface and also Internal interface, which is there by default. I also added my DHCP server's IP address to the list of DHCP servers on DHCP Relay Agent properties. I haven't configured anything else on DHCP Relay Agent.

                    The problem is that XP clients always receive DHCP options, but Vista or Windows 7 clients don't receive them.

                    DHCP configuration:
                    Network: 172.16.0.1/24
                    Range: 172.16.0.11-100
                    GW: 172.16.0.1
                    DNS1: 194.xxx.xxx.xxx/26
                    DNS2: 194.xxx.xxx.xxx/26
                    WINS: 194.xxx.xxx.xxx/26

                    I really can't understand why Windows XP clients receive DHCP options, but Vista+ clients don't (or maybe sometimes they do).

                    Also, if I watch DHCP Relay Agent windows I only see come request received on Internal interface, but none on my LAN interface. Also, there are no Replies received.

                    I really don't know how to solve this problem because I'm very confused why some clients receive options and some don't.

                    Thank you for your help!

                    Best wishes,
                    Marko

                    Comment


                    • #11
                      Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

                      Originally posted by Nonapeptide View Post
                      What's that black helicopter doing outside my window?!"
                      sorry.. that was me....:P nice TV

                      sigpic


                      Please do show your appreciation to those who assist you by leaving Rep Point

                      Comment


                      • #12
                        Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

                        Interestingly, I was just going through some Transcender practice exams (Thanks Train Signal! ) for my 70-297 and one question involved wether or not to turn on the DHCP Relay Agent for the VPN server. I knew immedaitely that I should because of your explanation of this to me Joe. Sure enough, in the explanation of the answer, the topic of the DHCP Inform packet came up and it was explicitly stated that it only gets transmitted if the VPN server is a relay agent. Funny how you'll never know about something and then when you learn about it it shows up everywhere.
                        Wesley David
                        LinkedIn | Careers 2.0
                        -------------------------------
                        Microsoft Certifications: MCSE 2003 | MCSA:Messaging 2003 | MCITP:EA, SA, EST | MCTS: a'plenty | MCDST
                        Vendor Neutral Certifications: CWNA
                        Blog: www.TheNubbyAdmin.com || Twitter: @Nonapeptide || GTalk, Reader and Google+: [email protected] || Skype: Wesley.Nonapeptide
                        Goofy kitten avatar photo from Troy Snow: flickr.com/photos/troysnow/

                        Comment


                        • #13
                          Re: DNS DHCP option 006 not being applied to VPN clients via RRAS

                          Thanks for the updated info Non. You're well on your way to guru-hood (or guru-dom).

                          Comment

                          Working...
                          X