ULA routing broke after 2.7.2 update
-
@gwabber just because I see it ;) don't mean someone will pick up the redmine and fix it quickly.
But yeah, I am only just having my first coffee so maybe I am missing something - but sure seems to me that the IPv6 ula network should be included in the table. I even created a IPv6 rule on that opt5/psk network of mine to allow for the psk subnets and still no ula listed in the table.
-
I know, but you are willing to help and add info to the bugreport, so I appreciate that!
-
@gwabber yeah you would think the ula network should be included in the alias, with the IPv4 ip alias vip, you see that Ipv4 network is listed in the table, and the IPv6 gua is there but not the ula..
I would think it a easy fix.. But playing devils advocate here - it could be something in the tables or how you they populate the tables that doesn't allow to show the ula..
Before they added this feature, I was not aware of way to actually check what was included in the built aliases for address or subnet..
edit: As a work around you should be able to just add the ula network your using specific in the rules vs just having a rule with the subnets alias as the source. You say it works on your lan for your ula? Not a ula user, so would have to setup some stuff to test..
-
@johnpoz said in ULA routing broke after 2.7.2 update:
You say it works on your lan for your ula? Not a ula user, so would have to setup some stuff to test..
Yep, on LAN it does but not from OPT.
-
@Bob-Dig kind of side thing - but those are local pings? Those seem very very high for someting on your lan pinging pfsense lan IP, be it actual IP or vip..
-
@johnpoz said in ULA routing broke after 2.7.2 update:
@Bob-Dig kind of side thing - but those are local pings? Those seem very very high for someting on your lan pinging pfsense lan IP, be it actual IP or vip..
Yeah, I was wondering too, seeing this . But it is my PC to my phone on Wifi, maybe it is half-sleeping, idk.
These are the only networks with ULA for me right now and I changed nothing. -
@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 = 1msLet 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.
-
@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!
-
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. :) -
Thanks for the report! I committed a fix for this - it can be applied with the System Patches package using commit
1c4ca20d3d5910f126f11221f23e1fa21197f225. -
@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.
-
@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!! -
@gwabber Working here great, too.
1c4ca20d3d5910f126f11221f23e1fa21197f225Oops, a little late to the party.
-
@Bob-Dig said in ULA routing broke after 2.7.2 update:
1c4ca20d3d5910f126f11221f23e1fa21197f225
But it's still a party ;)
-
B Bob.Dig referenced this topic on
-
@marcosm Works great on 2.7.2. Routing between ULA subnets on different physical ports (on an APU) "just works" now. Thanks!
-
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!! :) -
A artenpie referenced this topic on
-
B Bob.Dig referenced this topic on
-
@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. -
@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 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...
