Freebox Server (Pop V8/ Delta V7 / Revolution V6 / Server Mini 4K)

  • État Close
  • Type de tâche Anomalie
  • Catégorie LAN
  • Assignée à Personne
  • Système d'exploitation Freebox Server V8 (Pop)
  • Sévérité Moyenne
  • Priorité Normale
  • Basée sur la version A PRECISER
  • Due pour la version Non décidé
  • Date d'échéance Non décidé
  • Votes 0
  • Privée Non
Concerne le projet: Freebox Server (Pop V8/ Delta V7 / Revolution V6 / Server Mini 4K)
Ouverte par Marco Fincato (marc0777) - 06/05/2022
Dernière édition par Marios Makassikis (mmakassikis) - 01/06/2022

FS#36610 - IPv6 routing problems while using prefix delegations

Hello,
I’m an Iliad customer in Italy. I think I’ve found a bug in the Iliadbox and I’ve been pointed towards this bugtracker.

I’ve got an Iliadbox, which should be the same as the Freebox Server Pop V8, with firmware version 4.5.5-pre3.

I’ve configured two IPv6 prefix delegations pointing to a OPNsense firewall in the local network. From inside the delegations, so from a host behind OPNsense, I’m able to reach other hosts behind OPNSense and the outside internet. Viceversa, from the internet I can reach both hosts inside the delegations and inside the Iliadbox LAN.

However from inside the delegations I can’t reach the Iliadbox LAN, and from the Iliadbox LAN I can’t reach inside the delegations.

Doing a traceroute from a delegation host to the Iliadbox LAN I get this:

tracert 2a01:x:x:2d0:x:x:x:x

Tracing route to 2a01:x:x:2d0:x:x:x:x over a maximum of 30 hops

  1    34 ms    35 ms    34 ms  OPNsense.local [2a01:x:x:2d2::1]
  2    36 ms    34 ms    35 ms  2a01:x:x:2d0::1
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.

Again, doing a traceroute from an host inside the Iliadbox LAN towards an host behind OPNsense I get:

traceroute 2a01:x:x:2d1:x::x
traceroute to 2a01:x:x:2d1:x::x (2a01:x:x:2d1:x::x), 30 hops max, 80 byte packets
 1  2a01:x:x:2d0::x (2a01:x:x:2d0::x)  0.308 ms  0.286 ms  0.334 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

The requests aren’t being stopped by the firewall, and in the first case I can see them exiting the firewall correctly, while in the second case the firewall detects no incoming traffic.

This lead me to think of a routing problem in the Iliadbox software. Could it be, or is there something else on my side that I haven’t found or I could’ve overlooked?

Thanks,
Marco Fincato

Close par  Marios Makassikis (mmakassikis)
mercredi 1 juin, 2022 07:11:56
Raison de clôture :  Résolu

Cette tache ne dépend pas d'autre tache

Marios Makassikis (mmakassikis)
lundi 9 mai, 2022 11:47:40

Hello Marco,

The requests aren’t being stopped by the firewall, and in the first case I can see them exiting the firewall correctly, while in the second case the firewall detects no incoming traffic.

Are you doing any filtering on ICMPv6 traffic in OPNsense ? The Iliadbox will respond with an ICMPv6 Redirect when it receives a packet from a device that is destined for a host in different local prefix. This informs the sender of a better route to use to reach the destination.

Regarding the second case (firewall not seeing any traffic from a device in the Iliadbox LAN), it looks like the sender is ignoring ICMPv6 Redirects. Googling suggests Windows at least has a knob to accept/ignore such redirects (HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirect), although I am not sure what the default value is. What operating systems are you using ?

edit: If you’re using Windows, checking the behaviour with the firewall disabled is worth testing.

Marco Fincato (marc0777)
vendredi 13 mai, 2022 13:25:55

Hello,

I’ve set explicit rules in OPNsense to allow all ICMPv6 traffic, indeed pinging from a remote host I can reach inside my OPNsense network.

I’ve been testing this both from Windows and Ubuntu and I get the same results, so the Windows Firewall should be out of the equation. Moreover also TCP traffic isn’t getting through, indeed I noticed this problem because if I try to reach the domain pointing to an HTTPS server behind OPNsense I have to manually force it to IPv4 when I’m at home, while it works fine when I’m away from home or connected directly to the OPNsense network.

Marios Makassikis (mmakassikis)
vendredi 13 mai, 2022 15:15:30
I’ve been testing this both from Windows and Ubuntu and I get the same results, so the Windows Firewall should be out of the equation.

Not necessarily. Because traffic flows in both directions, if one host ignores the ICMPv6 Redirect, then it may properly receive packets but fail to send the responses to the proper destination.

Since the OPNsense device is effectively a router, you could have it advertise a route to the delegated prefix in the Iliadbox LAN. This sample configuration for radvd will send router advertisements containing a Route Information Option (RIO) field:

interface em0 {
  AdvSendAdvert on;
  AdvDefaultPreference low;
  route 2001:db8:a:b::/64 {
  };
};

Where em0 is the interface on OPNsense connected to the Iliadbox LAN. This way, hosts should learn the direct route to reach the delegated prefix (2001:db8:a:b::/64).

Unfortunately, this may not be sufficient as support for RIO depends on the host. On Ubuntu, the accept_ra_rt_info_max_plen defaults to 0, which means that all RIOs are ignored. Setting it to 128 makes the above configuration work in my test setup.

Marco Fincato (marc0777)
dimanche 15 mai, 2022 21:04:04

I need to read more about IPv6 because there still are a lot of things that I never heard of before!

Enabling Router Advertisement did improve the situation. For reference, this are the settings I applied on OPNsense:

While I’m still not able to reach inside the firewall from the LAN, at least the firewall is seeing the request, so this is a big progress. Indeed the routing table from the client on the LAN side have been updated and now point to OPNsense for the two delegated prefixes.

ip -6 route

::1 dev lo proto kernel metric 256 pref medium
2a01:x:x:2d0::/64 dev eth0 proto ra metric 1024 expires 85930sec pref medium
2a01:x:x:2d1::/64 via fe80::x:x:x:87f9 dev eth0 proto ra metric 1024 expires 1330sec pref medium
2a01:x:x:2d2::/64 via fe80::x:x:x:87f9 dev eth0 proto ra metric 1024 expires 1330sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::x:x:x:f882 dev eth0 proto ra metric 1024 expires 1330sec mtu 1500 pref medium

At this point I think it should only be a matter of finding what’s blocking the requests on or after OPNsense, since now they are being sent to the correct route.

Thanks a lot for the help so far, and let me know if you have any other suggestion
Marco Fincato

Marios Makassikis (mmakassikis)
lundi 16 mai, 2022 05:46:39

I’d make sure both IPv4 and IPv6 forwarding is enabled. This is probably already the case otherwise clients behind OPNsense wouldn’t be able to reach the Internet, but it’s an easy check to make. Remember these are separate sysctl settings.

I suggest temporarily disabling the actual firewalling on OPNsense, so you know whether you’re debugging a routing issue or a firewalling one.

While I’m still not able to reach inside the firewall from the LAN, at least the firewall is seeing the request, so this is a big progress.

How are you checking this ? Is that a ping to the firewall itself ?

Have you tested from inside the firewall to the LAN ?

I usually reach for tcpdump to debug this sort of problems. For example, when running a ping from the LAN to inside the firewall, can you see the packets exit the “inner” interface ?
For reference, that would be (as root): tcpdump -ni <interface_name> icmp6
If you don’t see them packets exit, it’s likely a firewall issue.
If you see the packets exit, then either the target host is not receiving them (firewall issue on the host ? If you’re testing using ping, remember Windows defaults to blocking incoming pings), or it is sending replies in the wrong direction.

I’ve set explicit rules in OPNsense to allow all ICMPv6 traffic, indeed pinging from a remote host I can reach inside my OPNsense network.

Do you pass all ICMPv6 traffic in all directions, or did you set specific IP prefixes ?

Marco Fincato (marc0777)
lundi 30 mai, 2022 10:18:38

Hello, I ended up to completely reconfiguring IPv6 on OPNsense, and now everything seems ot be working as it should! Probably while first configuring everything I made some mistake that I didn’t notice.

To have a working configuration I disabled DHCPv6 on the Iliadbox and set the next hop for the prefixes I was interested in as the OPNSense link-local IP.

On OPNSense I configured the WAN with DHCP on IPv4 and SLAAC on IPv6, and disable the “Block private networks” option, this creates a new gateway, that has to be marked as “Upstream Gateway”.
On the LAN side IPv4 is static and set to a value chosen by me (10.0.0.1/24), while IPv6 is also static but with an IP on the delegation from the Iliadbox (2a01:*:*:2d1::1/64).
At this point OPNSense was detecting the traffic and all I had to do was configure the firewall as needed.

Here are some screenshots of my configuration, in case someone wants to replicate a similar setup.

Since the problem was on my end since the beginning I think the issue can be closed!

Thanks for the support and the input for trying to solve the problem.

Marios Makassikis (mmakassikis)
mercredi 1 juin, 2022 07:11:51

Hello Marco,

Thanks for reporting back and sharing the working configuration !

Chargement...