> Let one HA setup with xxx::2 and xxx::3 as their WAN and xxx::1 defined as
> CARP.
> Now let xxx::10 defined as IP alias on parent xxx::1 (the WAN CARP), same
> prefix length as for the xxx::1.
>
> Clearly for packets coming in for xxx::1 (CARP), the system works as designed
> (master gets them, backup no).
> But for packets coming in for xxx::10 alias, the packets randomly reach both
> systems, just as if we were in the wrong configuration where two hosts have
> the same IP : whatever switch/router sits in front of WAN interface gets mad.
I have made an additional discovery. And my description wasn't accurate enough.
If I set things up exactly as above: it works. It fails as soon as NPt gets
in the way. Here's how.
WAN
primary xxx:dd00::2 /57 secondary xxx:dd00::3 /57
carp xxx:dd00::1 /57
alias xxx:dd01::10 /57 (on above carp xxx:dd00::1)
LAN
primary xxx:dd81::2 /64 secondary xxx:dd81::3 /64
carp xxx:dd81::1 /64
NPt
external xxx:dd01:: /64 internal xxx:dd81:: /64
On the LAN side, let a box with IP xxx:dd81::10 (/64), gateway to
xxx:dd81::1
For the remaining assume the primary is actually master, and the secondary is
backup.
Now I think my description of the context of the issue is right and true.
Problem is indeed this:
Packets incoming on WAN for xxx:dd01::10 are in error, going randomly to
primary and secondary.
If test pinging from the host at xxx:dd81::10 to the outside, all echo requests
are captured correctly on the WAN of the master. But echo replies come back
randomly to the master and the backup.
I now recognize clearly NPt gets in the way. I know you will ask why NPt? The
provider I have to live with for now, in front of my WAN *cannot* (for now,
they say), set things so they properly route our /56 to us through a PtP
subnet. I wouldn't have NPt at all, and would have no aliases to define, and
would not have any question to ask. But they can't proceed (hardly believable,
yes) for now.
The above trick using NPt, splitting the /56 subnet in two /57 halves, one used
on the WAN, allows me to re-use some part of the second half on the LAN after
NPt magic. That's the reason of the numbering above: dd01 actually translate to
dd81 which is on the next /57 of the /56. I think I'm not mistaken saying
there is nothing else I could do to use the IPv6 block as long as they don't
route it properly to our WAN. And without HA setup, it actually works fine.
But with CARP in the way, IP aliases on the WAN carp which happen to be
reflected on the LAN through NPt, do get into trouble.
It probably is much more expected than a bug, but maybe some wizard here will
have a clever idea (short of changing provider - which is in the plan anyway
but will take months) to overcome this?
Thanks again!
--
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
