5

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.

4 Answers 4

2

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.

8
  • - Is transparent proxies are incompatible even if we do not intercept ssl? (we do not already present). - Exact, we have already an automatic distribution of proxy configuration with proxy.pac.
    – Yohann
    May 25, 2012 at 16:48
  • Unless you're requiring proxy authentication, Transparent proxies have almost no benefits other than caching. You can't log/protect what the users are doing, and you're not accelerating anything for SSL, which is becoming more widespread.
    – rmalayter
    May 25, 2012 at 18:39
  • I apologize for the messed up comment above; weird editing issue. Explicit proxies can at least requrie authentication and will log HTTPS connects to the outside world. A transparent proxy just lets HTTPS through unmolested, perhaps logging source and destination IPs. In IPv6, the use of privacy addresses causes those source IP addresses to change frequently. An IP address doesn't equal a specific user in any case. So you're basically giving up on all of the auditing/security/authentication benefits of a proxy if it's a transparent proxy, all you get is acceleration of cached HTTP objects.
    – rmalayter
    May 25, 2012 at 18:46
  • Thanks ! I forgot http authentification ! Actually, we use Basic http proxy authentification. So, if we want to use transparent proxy, we need to find an other way to authentify users (by IP). Maybe with a NAC solution ? We have also a project to migrate all users to Windows 7 in 1 or 2 (or 3..) years. I will seek on that side. Implementing a 802.1x architecture over IPv6 would be a huge challenge !
    – Yohann
    May 25, 2012 at 20:21
  • 802.1x happens at the MAC layer, and should not have a dependency on IP. That assumes, of course, your switches are capable of talking to RADIUS servers over IPv6, which most still probably cannot.
    – rmalayter
    May 26, 2012 at 14:03
0

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.

1
  • We use proxying for caching/security/filtering. We haven't problems for the transport of IPv6. We use a VRF for IPv6 network on our MPLS backbone.
    – Yohann
    May 30, 2012 at 17:07
0
+200

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

3
  • Be careful with disabling ICMP completely (very bad advice). ICMP ECHO (and response) is not the only ICMP traffic and is actually little used for a long time as an attack vector. ICMP Destination Unreachable, Fragmentation Needed, and some other messages are very necessary for the proper function of a network (path mtu discovery, etc...).
    – JGurtz
    Jun 1, 2012 at 18:31
  • I meant disabling ping from LAN (clients) to internet, so LAN to GW, GW - internet (as GW is not in scope of individual clients/users).
    – jirib
    Jun 4, 2012 at 13:39
  • It is OK to disable ICMP ECHO and ECHO REPLY packets (ping uses these). The other ICMP types should not be blocked inside the LAN.
    – JGurtz
    Jun 5, 2012 at 14:52
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .