ipv6 for hosts behind UTM

Nobody on this ? Does anyone use ipv6 behind UTM ?

I restarted all the setup, everything is now in a /64 including the ISP interface. From inside, it's almost working (see *), I can ping all hosts including the UTM on the internal interface. Hosts with no ipv6 fixed ip get's one from prefix advertisement, all is good. Problem is that I can't ping the UTM ISP interface ipv6 :(

From outside the same, I can ping the ISP ipv6 but none of the internal ! From the UTM, using Support => Tools, I can ping an outside ipv6 using nearest routing -which means ISP interface- but not if I set the internal interface.

It seems that the firewall is blocking internal ipv6 to external and vice versa. I even try to give an ipv6 GW to internal interface (ISP interface), no changes. Also I see in ip -6 r of UTM

2a01:xxxx:yyyy::1 dev eth0.1002 metric 1024   ; ISP ipv6 GW
2a01:xxxx:yyyy::2 dev eth2 metric 1024           ; ISP interface
2a01:xxxx:yyyy::10:254 dev eth2 metric 1024  ; *** This entry should not be here, that's the ip of the second VM ! *** Internal ipv6 is ::10:1
2a01:xxxx:yyyy::/64 dev eth2 proto kernel metric 256
2a01:xxxx:yyyy::/64 dev eth0.1002 proto kernel metric 256
fe80::/64 dev eth2 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0.1002 proto kernel metric 256
fe80::/64 dev eth0.1001 proto kernel metric 256
fe80::/64 dev eth0.100 proto kernel metric 256
fe80::/64 dev eth0.2 proto kernel metric 256
fe80::/64 dev eth0.1000 proto kernel metric 256
fe80::/64 dev eth0.210 proto kernel metric 256
fe80::/64 dev ifb0 proto kernel metric 256

Any help or tip is appreciated.

(*) the second VM can only be reached by the UTM VM and the physical host. Other way it's working like a charm. But that's another story.

Daniel

Me again ;)

what I see in logs is that neighbor sollicitation for external ipv6 get never answered (capture on internal interface)

19:01:35.455562 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has guava, length 32
19:01:35.578057 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:xxxx:yyyy::1, length 32
19:01:36.474502 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has guava, length 32
19:01:36.602368 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:xxxx:yyyy::1, length 32
19:01:37.498390 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has guava, length 32
19:01:37.626370 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:xxxx:yyyy::1, length 32
19:01:38.522412 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has guava, length 32
19:01:39.034301 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:xxxx:yyyy::1, length 32
19:01:39.546318 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has guava, length 32
19:01:40.058373 IP6 2a01:xxxx:yyyy::10:254 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:xxxx:yyyy::1, length 32
19:01:40.457457 IP6 fe80::xyz:ff:zyx:1234 > 2a01:xxxx:yyyy::10:254: ICMP6, neighbor solicitation, who has 2a01:xxxx:yyyy::10:254, length 32
19:01:40.457574 IP6 2a01:xxxx:yyyy::10:254 > fe80::xyz:ff:zyx:1234: ICMP6, neighbor advertisement, tgt is 2a01:xxxx:yyyy::10:254, length 24

but is for internal ipv6 (2 last lines).

Is there a rule to add on firewall to allow those neighbor solicitations/advertisement ?

Daniel

The only way to get around the split of the networks is to have NDP proxy (equivalent of Proxy ARP) which the UTM does not have as a feature. 

The problem is you are running a dual stack LAN but obviously for ipv4 you are NAT'ing so there is no overlapping routes. 

https://community.sophos.com/products/unified-threat-management/f/general-discussion/22186/best-way-to-use-ndp-proxy

Think of it in IPV4 terms:

Your ISP is 1.1.1.1/24

Your UTM External interface is 1.1.1.2/25

Your UTM Internal interface is 1.1.1.129/25 

Your VM is 1.1.1.130/25 with 1.1.1.129 as the default gateway.

If you ping from 1.1.1.130 to 1.1.1.1, the ISP will try to arp for 1.1.1.130 instead of routing it back to 1.1.1.2 because it thinks it is on the same subnet. How would it ever work?

Now in IPV4 you can enable proxy arp to get around this issue so that the UTM external answers any arp request for hosts behind it. 

The link above does have a workaround but it is not a supported method.

I understand your point of vue but remember that ipv6 was (for part) created to avoid all those nating stuff !

UTM can only deal with /64 mask (reason?), so if I understand you right, If I had a /64 not a /48 it should work. If yes I can test this solution as I have a second provider which is given me a /64 but I don't use it.

I believe that Edward is right, something is broken/not working/not implemented (RADVD or other). The only way to use ipv6 with UTM is to NAT ipv6 or 6to4. It's not what I want, it's regression and not the future.

Daniel

Hi Daniel,

It's not that you need a /64 for whatever reason but you need to split up the /48 into smaller networks and route them instead since there is no layer 2 connection to hosts behind the UTM from the ISP side of things. 

The UTM should broadcast that it is the router to the whole /48, then when the firewall sees it it will forward the packets accordingly. The problem (I think) is that the UTM never tells the ISP router, and therefore the rest of the Internet,  that it is the router for the /48 (or /64 if that is how you set it up). This is why pinging from the outside interface works (the ISP router, and the world, can route to that IP address), that the devices on the "inside" can ping the gateway (they are on the same broadcast domain), and that the devices in the inside cannot reach devices on the Internet -- (there is no route back). Since things work without the UTM, it strongly implies the UTM is the problem.

I agree, for me too it's an UTM problem as everything works fine *FROM inside* the UTM.

I did another test on an server I have in DC, host + 2 VM. ISP gave me a /64 which is connected to eth0 with default GW being ISP router. I create an /96 on virbr0, gave ipv6 too my VMs with default route being virbr0 ipv6. Everyting is working like a charm despite the fact that both networks are overlapping.

Daniel

Hi,

finally I got it work! It was an ISP problem, they didn't route correctly the /48 mask. After they modify there rules everything worked like it should.

To summarize:

. UTM need a /64 for internal stuff like dhcp or whatever which means you need at least two /64 range (external and internal) except if next point is not true

. network should not overllaping but I'm not sure about this (I didn't test with a /96 inside the /64 for instance, knowing that dhcp and friends wouldn't work)

. internal UTM ipv6 GW has to be the external UTM ipv6 interface

. client from inside the lan have internal UTM ipv6 GW

Thanks to MasterRoshi and Edward for there help.

Regards

Hi Daniel,

Glad you got it working.

In the end ipv6 is not much different than ipv4 in terms of L2/L3 communication and almost all of the same rules still apply.

Have a good one!

Daniel Huhardeaux said:

 

. client from inside the lan have internal UTM ipv6 GW 

Another point: I discovered that ssh from outside to an internal ipv6 was blocked at some parts of the initial connection: this was due to an MTU of 1500 at the internal ipv6 device. Changing it to 1492 and everything worked flowlessly.

Daniel

Any News here?

I have the same Problem and i also think, the UTM is the Problem.

IPv6 only works with a NAT. I have a delegated /64 Prefix, which i use in my LAN and a /128 on the WAN Interface.

Tracert from outside to my /64 network doesn't work. The /128 on on my WAN Interface can be reached. Seems that there are no routes to my /64 Network from outside, so i have to use NAT.

^^Who is the ISP?

^^Who is the ISP?