Home / server / Questions / 392588
In Process
Yohann
Asked: 2012-05-26 02:37:57 +0800 CST

Enterprise IPv6 Migration - End of proxypac ? Start of Point-to-Point ? +10K users

  • 772

Let's start with a diagram : Company in IPv4

We can see a "typical" IPv4 company network with :

  • An Internet acces through a proxy
  • An "Others companys" access through an dedicated proxy
  • A direct access to local resources

All computers have a proxy.pac file that indicates which proxy to use or whether to connect directly. Computers have access to just a local DNS (no name resolution for google.com for example.)

By the way ... The company does not respect the RFC1918 internally and uses public addresses! (historical reason). The use of internet proxy explicitly makes it possible to not to have problem.

What if we would migrate to IPv6?

Step 1 : IPv6 internet access

Internet access in IPv6 is easy. Indeed, just connect the proxy in Internet IPv4 and IPv6. There is nothing to do in internal network : Internet access IPv4 and IPv6

Step 2 : IPv6 AND IPv4 in internal network

And why not full IPv6 network directly? Because there is always the old servers that are not compatible IPv6 ..

Option 1 : Same architecture as in IPv4 with a proxy pac

This is probably the easiest solution. But is this the best?

I think the transition to IPv6 is an opportunity not to bother with this proxy pac!

Option 2 : New architecture with transparent proxy, whithout proxypac, recursive DNS

Oh yes!

In this new architecture, we have:

  • Explicit Internet Proxy becomes a Transparent Internet Proxy
  • Local DNS becomes a Normal Recursive DNS + authorative for local domains
  • No proxypac
  • Explicit Company Proxy becomes a Transparent Company Proxy
  • Routing
    • Internal Routers reditect IP of appx.ext.example.com to Company Proxy.
    • The default gateway is the Transparent Internet proxy.

Questions

  • What do you think of this architecture IPv6?
  • This architecture will reveal the IP addresses of our internal network but it is protected by firewalls. Is this a real big problem? Should we keep the explicit use of a proxy? -How would you make for this migration scenario? -And you, how do you do in your company?

Thanks! Feel free to edit my post to make it better.

migration proxy ipv6 transparent-proxy ipv4

4 Answers

  1. Well transparent proxies don't work for SSL traffic unless you deploy an alternative trusted root to each device, so you lose many security and auditing benefits there, and introduce new ones.

    I would go with option 2, but using an explicit proxy, fire-walling everything else off. If internal machines don't use your proxy, they don't get access to the internet. You should already have tools in place to distribute proxy configuration automatically via scripting, Windows Group Policies, DHCP, or DNS/proxy.pac.

    Simpler is usually better.

    • 2

  2. I would rebate with another question. Why do you really need proxying? Because of the RFC1918 incompatibility? It fully justifies the usage of proxy when you choose not to rebuild your IPv4 architecture to use 10.x.x.x addresses (my ISP used to give us non-RFC1918 addresses but used a NAT, now we have 10.x.x.x and the NAT of course). Or, do you use proxying for caching/security/filtering/auditing?

    If the answer to first question is true, then I would go for a very simple option 1: put a very simple IPv6 router on your border, update your DHCP(s) to broadcast an IPv6 prefix and make your IPv6 traffic go through your router. Since you already need to upgrade your middle routers (those that stand between client hosts and border router) this doesn't add an extra hardware cost.

    This has the advantage of keeping IPv4 alive and available for machines not supporting it, which will behave the same as before.

    In order to answer your questions: 1) your architectural choice (on the figure) shows no support for IPv6 to client machines, which is a real waste 2) "revealing" IPs is common in IPv6 because there is no NATting. You just need a little extra care to firewalling, and privacy addresses (as stated in the other answer) protect the privacy of client machines against out-of-domain servers.

    • 0

  3. I would keep ip4/ipv6, some devices are quite dumb and cannot be upgraded anyway. If you can separate by vlans.

    Then use explicitely http proxy. Do not use transparent proxy. Why? You can easily detect that there's misconfigured application or device trying to go to internet. You should distinguish between "normal" traffic and "strange" traffic. Information about mandatory usage of http proxy should be part of employees education.

    You can setup one http proxy which would forward particular domains to other parent proxy (for your specific customers' websites). This solves pac file trouble, you define in clients' applications only one http proxy.

    Do not enable recursive dns in your LAN! DNS tunneling works! Do not enable ping outside of LAN (ICMP tunneling), there's no need for clients! Enable recursive dns only for your http proxy or the applications which really need to make dns queries.

    According to a analysis only 20 % of network administrators know what is leaving their network :D

    I really like idea to give clients http[s] access via remote client (RDP, citrix...), but this seems quite costly.

    This is nice reading - http://undeadly.org/cgi?action=article&sid=20091025011137

    • 0

  4. One other thing to consider is a phased approach where a new network of IPv6-only hosts access the old LAN via NAT64/DNS64.

    It seems likely you will want to run dual-stack for a while. The same approach can be used to fix non-compliance with RFC1918 by proxying/NATing 10.x.x.x v4 addresses to the old LAN. That's assuming your public IPs are hijacked. If you have obtained the allocation from IANA/ARIN/etc... then it's not a problem.

    • 0