ULA routing broke after 2.7.2 update

johnpoz

@Bob-Dig so I just setup a ula on my lan, and pinging it from my pc that I only have a ula added too it, no gua and good response time and yup your right it works.. So the ula vip must be on the lan alias..

$ ping -6 fdd2:b1af:dbd6:9::253

Pinging fdd2:b1af:dbd6:9::253 with 32 bytes of data:
Reply from fdd2:b1af:dbd6:9::253: time=2ms
Reply from fdd2:b1af:dbd6:9::253: time=1ms
Reply from fdd2:b1af:dbd6:9::253: time=1ms
Reply from fdd2:b1af:dbd6:9::253: time=1ms

Ping statistics for fdd2:b1af:dbd6:9::253:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2ms, Average = 1ms

Let me fire up something on one of my other networks that I can easy do ula setup on and test.. But from that testing I would say the ula is allowed via the subnets source, and just not shown in the table.. Let me see what is the easiest way I can setup something with ula on one of my other networks with a client I can easy test with.

edit:
Yeah - very odd, so it works on lan.. But not on another interface.. Added a ula vip, and using the subnets alias as source can not ping. Changed the ipv6 rule to any as source.. And then can ping.

root@pihole:/home/pi# ping6 fdd2:b1af:dbd6:3::253
PING fdd2:b1af:dbd6:3::253(fdd2:b1af:dbd6:3::253) 56 data bytes
^C
--- fdd2:b1af:dbd6:3::253 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5122ms

root@pihole:/home/pi# ping6 fdd2:b1af:dbd6:3::253
PING fdd2:b1af:dbd6:3::253(fdd2:b1af:dbd6:3::253) 56 data bytes
64 bytes from fdd2:b1af:dbd6:3::253: icmp_seq=1 ttl=64 time=0.570 ms
64 bytes from fdd2:b1af:dbd6:3::253: icmp_seq=2 ttl=64 time=0.528 ms
64 bytes from fdd2:b1af:dbd6:3::253: icmp_seq=3 ttl=64 time=0.522 ms
64 bytes from fdd2:b1af:dbd6:3::253: icmp_seq=4 ttl=64 time=0.500 ms
^C
--- fdd2:b1af:dbd6:3::253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3075ms
rtt min/avg/max/mdev = 0.500/0.530/0.570/0.025 ms
root@pihole:/home/pi#

edit2.. So added specific rule to allow the ula prefix using as source, and that works - so yeah seems like for other than lan the ula vips are not being added to the alias.

Bob.Dig

@johnpoz said in ULA routing broke after 2.7.2 update:

edit2.. So added specific rule to allow the ula prefix using as source, and that works - so yeah seems like for other than lan the ula vips are not being added to the alias.

Which can't bee seen anyways. Thanks!

the other

hey there,
I stumbled over the same problem today (after reading it here)...
No Ping, no nothing with Aliases / VIPs... :(
Same here: it worked before updating
Since I normally use v4 in my home net I didn't notice til today...
And yes, the workaround (entering Source ANY > do not like that) and entering source NETWORK > pv6-prefix plus subnetID /64 does the trick (like that better).
BUT: this is another straw on my back concerning implementation of v6 (not all pfsense's fault, more ISP and such). Working with ULAs (when ISP is giving "dynamic" v6 prefixes) sux, but hey, it works / worked. Now with the lost VIPs it just gets on my nerves, changing my rulesets yet again...
PLEASE fix that soon, so that Aliases and VIPs for ULAs work again...that's my xmas wish this year. :)

marcosm

Thanks for the report! I committed a fix for this - it can be applied with the System Patches package using commit 1c4ca20d3d5910f126f11221f23e1fa21197f225.

johnpoz

@marcosm said in ULA routing broke after 2.7.2 update:

1c4ca20d3d5910f126f11221f23e1fa21197f225

I am now seeing the ula vips on both the lan, and another opt interface I put a ula on in the tables

And via simple ping test the opt subnets alias as source is allowing the ula range now.

gwabber

@marcosm Wow, that is very quick, thank you!

I am new to the system patches package. Should I just insert the commit and hit save?

edit;
never mind, tried it and it works! Awesome!!

Bob.Dig

@gwabber Working here great, too.

1c4ca20d3d5910f126f11221f23e1fa21197f225

Oops, a little late to the party.

gwabber

@Bob-Dig said in ULA routing broke after 2.7.2 update:

1c4ca20d3d5910f126f11221f23e1fa21197f225

But it's still a party ;)

artenpie

@marcosm Works great on 2.7.2. Routing between ULA subnets on different physical ports (on an APU) "just works" now. Thanks!

the other

Hello team!
Thanx a lot for getting the patch done and indeed, here too, it works and my ULA problem is gone.
So you got me my xmas present even before xmas, truly thankful and best wishes to everyone out there!!! Great and quick work!! :)

Bob.Dig

@gwabber Maybe this patch has a problem and someone else can verify this:
Today I tried to add IPv6 to another interface via Track Interface, no matter what I did, the interface didn't got an IPv6-address. I then disabled the auto-patching, rebooted and there was the IPv6-address. I then re-enabled auto-patching and everything still works as expected after another reboot.

gwabber

@Bob-Dig I looked into my firewall and I replicated your issue, so you are not the only one! I guess it is a bigger issue.

Bob.Dig

@gwabber Thanks. So I let @marcosm know, if he isn't already aware of it.

the other

@Bob-Dig Hey there, same here: had v6 on 3 out of 9 (v)Interfaces running. Read your post and tried adding another one.
Set everything under Interfaces exactly as the others (track Interface > WAN), picked a Subnet prefix ID, picked a fitting ULA prefix etc...

first: interface does not get an GUA IPv6, so yeah, same here
second: other interface's GUA v6 was gone, took around 5 minutes til they were back...
third: in that time no DNS via unbound, ping with IP to 8.8.8.8 okay, ping to google.com...not okay. Came back eventually.

So after 15 minutes an 2-3 try outs: everything working except that "new" v6 interface, which does not get GUA or ULA. Unbound has to be started manually again.
Even disabling and enabling the interface again did not get a v6...

marcosm

The original issue/patch does not affect what address is added to the interface. If the interface that is set to track does not get an IPv6 address, that is a separate issue that would need its own redmine report (with exact steps to reproduce). If you reproduce the issue, does Status > Interfaces show the IPv6 address?

gwabber

@marcosm thanks for your reply!

Just checked it. The statuspage also doesn't show the IP address.

Bob.Dig

@marcosm said in ULA routing broke after 2.7.2 update:

The original issue/patch does not affect what address is added to the interface. If the interface that is set to track does not get an IPv6 address, that is a separate issue that would need its own redmine report (with exact steps to reproduce). If you reproduce the issue, does Status > Interfaces show the IPv6 address?

This patch is the reason that one can not set another interface to Track Interface. Or to be more precise, that interface will not get GUA-IPv6. Disabling this patch will fix this. So I don't think that there should be another redmine?

I have uninstalled the patch and removed any ULAs (and VIPs) I had, so I am not able to do much more testing on this.

gwabber

@Bob-Dig @marcosm It is indeed typical the problems started with the fix. I have not enough experience with pfsense or BSD to know why this occurs.

marcosm

Disabling "Auto Apply" for the patch and rebooting is not a good test since that option does not affect reboots and it may have worked after the reboot because of something unrelated. A more proper test could be to reapply interface settings before and after the patch to see if there's any difference with the IPv6 addresses.

gwabber

@marcosm indeed... without the reboot, my interface still doesnt get an IPv6 address on " track"