IPv6 configuration problem

[chris11256]

Hi All,

 

Am trying to get started configuring IPv6 on my network following from the recent thread. We've been assigned the 2A00:2381:144:100::/56 block from BT which has then been split into the 256 /64 subnets.

 

I've assumed BT have used 2A00:2381:144:100::1 for the managed router's interface, so I configured my firewall outside interface as 2A00:2381:144:100::2. This works and from the firewall CLI I can ping from 2A00:2381:144:100::2 to any other IPv6 address.

 

However my test internal devices can't access IPv6 websites.. I've enabled IPv6 on the firewall itself(plus on the relevant interfaces) and added a defualt route pointing towards the BT router's IPv6 address. The firewall's inside interface has been assigned an address as has the transit vlan on the core switch. This is vlan 101 and is used as a core-firewall transit. A v6 default route has also been set on the core pointing towards 2A00:2381:144:101::2(firewall inside). The vlan i'm testing with has had IPv6 enabled and an address assigned on the core switch. My firewall rules include a generic catch all external traffic which is filtered to student standards). So even though I don't have a specific v6 security rule in place, traffic should still flow.

 

I've also set a static route on the firewall for the test subnet(which in this case is vlan 201 with 2A00:2381:144:1a1 with the core switch vlan IP being 2A00:2381:144:1a1::1). IPv6 unicast routing has also been enabled on the core switch.

 

I'm able to ping from the firewall's external interface to anywhere on the internet. However I can't ping from vlan 201 to anything external on IPv6. I also can't ping from the firewall's internal interface to anything v6 external. I'm at a bit of a loss as to why, as I've followed Palo Alto guidance for enabling IPv6. Any advice for things I can check?

 

Thanks,

 

Chris

[chris11256]

Just to update, not getting very far with this.

 

Double verified that the firewall config is good & IPv6 is enabled. Correct static routes are set outbound & inbound as well.

 

So if anyone has any advice it'd be greatly apprechiated.

[Opendium_Steve]

I'm able to ping from the firewall's external interface to anywhere on the internet. However I can't ping from vlan 201 to anything external on IPv6. I also can't ping from the firewall's internal interface to anything v6 external. I'm at a bit of a loss as to why, as I've followed Palo Alto guidance for enabling IPv6. Any advice for things I can check?

 

 

Just to clarify, I think you have:

 

*BT Router*
  | 2a00:2381:144:100::1/64
  |
  | 2a00:2381:144:100::2/64
*Firewall*
  | 2a00:2381:144:101::2/64
  |
  | 2a00:2381:144:101::1/64 (I'm assuming?)
*Core Switch*
  | 2a00:2381:144:1a1::1/64
  |
  | 2a00:2381:144:1a1::/64
*Test Device*

You don't mention whether you can ping the firewall from the test device. I suspect this will work, and if so the most likely culprit is probably routing:

 

The BT router needs a static route "2a00:2381:144:100::/56 via 2a00:2381:144:100::2" so that it knows to route everything for your internal network via the firewall. I suspect this might be what's missing. I can traceroute to your firewall's external address, but if I try tracerouting to the internal address I get a "host unreachable" response from the BT router. That strongly suggests that BT have configured the router to expect the entire /56 network to be directly connected to the router, whereas it actually wants to have 2a00:2381:144:100::/64 directly connected and 2a00:2381:144:100::/56 routed via the firewall.

 

So, I recommend:

 

BT router:

• 2a00:2381:144:100::/64 directly connected.
  
• 2a00:2381:144:100::/56 via 2a00:2381:144:100::1 (firewall)
  
• default via leased line
  

 

Firewall:

• 2a00:2381:144:100::/64 directly connected to the internet interface.
  
• 2a00:2381:144:101::/64 directly connected to the LAN interface
  
• 2a00:2381:144:180::/57 via 2a00:2381:144:101::1 (core switch)
  
• default via 2a00:2381:144:100::1 (BT router)
  
• Networks 2a00:2381:144:102::/64 to 2a00:2381:144:17f::/64 are left unused.
  

 

And for the switch:

• 2a00:2381:144:101::/64 directly connected to VLAN 101 (core-firewall transit)
  
• default via 2a00:2381:144:101::1 (firewall)
  
• Networks 2a00:2381:144:180::/64 to 2a00:2381:144:1ff::/64 can be assigned to individual VLANs
  

 

This gives you up to 128 possible VLANs (excluding the core-firewall transit), and putting everything downstream of the core switch in the same /57 (instead of /56) makes the routing tables simple. IPv6 is designed to be used in this hierarchical way, with the netmasks getting longer as you go downstream of the internet - it allows you to keep the routing tables small and simple, albeit by wasting some of the address space.

 

I hope that makes sense anyway

[chris11256]

Many thanks for this. Yes I can ping the firewall's internal interface from my test server.

 

I suspect I have a bit of a fight on my hands trying to explain thia to BT support.

 

Many thanks for the advice. It's all a rough plan beyond the internal network i've configured, So am more than happy to adjust the addressing plan.

 

I'll update this thread in due course, although after today I'm off until January.

Edited December 13, 2019 by chris11256

[Opendium_Steve]

I suspect I have a bit of a fight on my hands trying to explain thia to BT support.

 

To be fair to BT, their techies are usually really good... unfortunately you have to battle your way through lots of management types before you can talk to a techie.

 

The last time I was involved with a new BT leased line install, the IPv6 addresses and routing were all set up sensibly out of the box. Prior to the installation, we got an email that basically said "here are your IPv4 settings, and your IPv6 network is blah::/56 with the router on blah::1/64 and everything else routed via blah::2/64". I've no idea why you would ever have a /56 directly connected to the router, seems bonkers to me

[Davit2005]

I have a Draytek at home and had to put a route to the internal IPV6 networks via the firewall WAN interface. In the end I just used a summary address.

 

I had to junk the BT Business hub because it did not support IPv6 routing to route the traffic via my firewall. BT were pretty clueless when I asked them what IPv6 addresses I should be using for gateway etc and I had to work it out myself with a lot of trial and error, you can be lucky and get a engineer that knows a bit about it.

[chris11256]

To be fair to BT, their techies are usually really good... unfortunately you have to battle your way through lots of management types before you can talk to a techie.

 

The last time I was involved with a new BT leased line install, the IPv6 addresses and routing were all set up sensibly out of the box. Prior to the installation, we got an email that basically said "here are your IPv4 settings, and your IPv6 network is blah::/56 with the router on blah::1/64 and everything else routed via blah::2/64". I've no idea why you would ever have a /56 directly connected to the router, seems bonkers to me

 

 

That documenatation was never provided(or it was and my predecessor lost it). So I had to chase BT for ages.

 

In the end I was provided this 2A00:2381:144:100::/56 ASSIGNED and thats it!

Edited December 13, 2019 by chris11256

[chris11256]

Just to update my own thread. I've now got IPv6 working on the IT & Server vlans. I just need to do the access lists before rolling it out on others.

 

The problems I encountered were because I didn't tick the right box when applying an IPv6 address to the firewal's internall interface. So after checking it, I now have IPv6 connectivity.

[Davit2005]

Well done.

 

I had a whole lot of pain getting IPv6 to route from an internal Layer 3 stack switch (2930f). I tried static routes for hours, link locals and globals addresses. In the end I setup OSPFv3 just for IPv6 and that worked without an issue was a steep learning curve of trial and error.

Edited January 17, 2020 by Davit2005

[chris11256]

Thankfully our network is fairly simply topology wise, so just needed a default route on the core and then some static routes on the firewall.

 

Need to experiment with our BYOD wifi though, in my last school the NM said he had problems getting user-ID to work properly with BYOD & IPv6, so that'll be some out of term fiddling around.

[Opendium_Steve]

Need to experiment with our BYOD wifi though, in my last school the NM said he had problems getting user-ID to work properly with BYOD & IPv6, so that'll be some out of term fiddling around.

There's a big gotcha with user ident and IPv6, unfortunately. What I write below is from the perspective of how Opendium UTM systems work (since that's what I'm most familiar with), but I imagine it's largely the same for other firewalls/filters:

 

For Windows workstations, where possible, we authenticate each web connection using Kerberos single-signon auth, and this works equally well for v4 and v6. This also gives us a "who's currently using each workstation" mapping. For things that we can't auth on a per-connection basis (apps that won't do Kerberos, stuff that hits the transparent proxy, non-web traffic), we infer the username by looking at the current workstation->username mapping. Each workstation is basically identified by its IP or MAC address.

 

For BYOD, users normally authenticate by 802.1x, or captive portal, which gives us a "who's currently using each device" mapping. Individual web connections themselves can't be authenticated, so the user name is always inferred from the "device->username" mapping. Again, a device is identified by its IP or MAC address.

 

If your UTM is plugged directly into your wifi network (i.e. a layer 2 connection), everything is easy - you just identify the device by its MAC address, and this works for any protocol. This is also Smoothwall's recommended configuration so I imagine they do the same thing here.

 

If your BYOD network is routed rather than being connected directly to your UTM (i.e. a layer 3 connection), your UTM can't see the MAC address any more and relies on the IP address instead. IPv4 addresses are stable over longish periods of time, so that's fine, and IPv6 addresses are also stable if you're using stateful-DHCPv6. If you're not using stateful-DHCPv6, the device will almost certainly turn on "privacy extensions" which means its IPv6 address changes every few minutes and breaks user ident. Android devices don't support stateful-DHCPv6 and I think Google are on record stating that they have no intention of ever supporting it (thanks Google...). Also, for 802.1x, your wifi needs to report a "Framed-IP-Address" and "Framed-IPv6-Address" RADIUS attribute - for v4 this is well supported these days, but for v6 I'm not sure.

 

I mentioned that sometimes we still have to use the current workstation->username mapping even for non-BYOD networks. This means that you'll want to use stateful-DHCPv6 on those networks too. That's not a big deal because you're not usually having to deal with Android devices on those networks.

 

Summary

If your wifi networks have layer 2 connections to the UTM, user ident should work equally well for both IPv4 and IPv6. If your wifi networks don't have layer 2 connections to UTM, user ident for IPv6 will be problematic, especially if you plan on supporting Android.

[Davit2005]

Personally I would always terminate BYOD on a firewall. It is much easier to keep separation there without the need for complex hard to manage ACLs on a layer 3 switch.

[Opendium_Steve]

Personally I would always terminate BYOD on a firewall. It is much easier to keep separation there without the need for complex hard to manage ACLs on a layer 3 switch.

I agree in most cases (and you usually need multiple routing tables too, not just ACLs!). But some times it would be preferable to use a routed network instead of stretching a layer 2 network across several interconnected sites though.

 

Also, although we offer advice on how best to set things up when people are building new services, its a fact of life that we do end up retrofitting our systems into less-than-ideal network designs. Unfortunately "Congratulations on buying your new filter, and now you have to rip out and redesign your entire network" isn't something we can do.

Edited January 17, 2020 by Opendium_Steve

[chris11256]

I might well end up sticking with DHCPv6 for BYOD and not support IPv6 on Android devices, I'm using DHCPv6 for the domain side of things anyway.

[chris11256]

Another update with a gotcha that's come up. Both the Palo Alto Agentless user ID & User ID agent don't support dual stack IPv6 with Active Directory as your user source. They both simply report the IP address that was used to do the initial computer login. So as I've given my domain controllers IPv6 addresses, user ID then only reports the IPv6 address as that's what was used to do the domain login. Handy that only IT computers have IPv6 currently.

 

I've been told the only workaround is some kind of script that does User ID via the XML API. As I'm no good at scripting that'll be fun.

Edited January 21, 2020 by chris11256