ULA routing broke after 2.7.2 update
-
@Bob-Dig said in ULA routing broke after 2.7.2 update:
where can we see what the built-in "subnets"
They added that in the latest updates.. You can see them under diagnostics, tables.
You have to know what opt interface you assigned, other than lan and wan.. if your don't recall which opt is your networks because you named them.. Easiest way is to prob just look at your cmd/ssh console menu
Or if you look at the full url when you go to an interface the opt will be listed
-
@johnpoz Thank you. But these aren't complete, for instance ULA IPv6 VIPs are completely missing. But it still is working for LAN and not for other subnets (OPT). So my guess is that somewhere is the real deal but maybe I am wrong.
-
@Bob-Dig said in ULA routing broke after 2.7.2 update:
@johnpoz Thank you. But these aren't complete, for instance ULA IPv6 VIPs are completely missing. But it still is working for LAN and not for other subnets (OPT). So my guess is that somewhere is the real deal but maybe I am wrong.
Thanks for the info both!
@johnpoz The same problem here, the ULA's are completely missing!
-
@gwabber yeah I see that - just put a gua on my opt5 and added a ula, and its not in the alias.
What was the bug report created? Did you link it to this thread?
-
@johnpoz I saw that @Bob-Dig created the a report here: https://redmine.pfsense.org/issues/15096 He refered to this threat.
-
@gwabber yeah I see that, will add my comments.
Looks like it shows IPv4 vips, just not ula IPv6 vips..
-
@johnpoz Awesome that you pick this up so quickly! Thanks in advance :)
-
@johnpoz But what is weird is that I still can ping my phone in some OPT from my PC in LAN but I can't do it the other way around, unless I set the source to any.
While both tables don't show any ULAs, the rules are treated differently. That was the reason for this thread (I think), not that tables don't show ULAs. -
@Bob-Dig I fixed it temporarely by adding separate allow rule for the ULA, so that works too.
In summary two things are weird:
- The ULA vip is not added to the table
- It still works from the LAN
-
@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 = 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.
-
@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.