ULA routing broke after 2.7.2 update

[gwabber]

Hey all,

English is not my first language, so I will try to explain my problem as clear as possible

Since I updated to pfsense 2.7.2, my ULA routing broke and behaves strange.

What is my situation?
I have three subnets:

Regular LAN

• IPv4 range
• IPv6 GUA range via track
• IPv6 ULA range via VIP

WiFi Vlan
Vlan 103

• IPv4 range
• IPv6 GUA range via track
• IPv6 ULA range via VIP

Server VLAN
Vlan 178

• IPv4 range
• IPv6 GUA range via track
• IPv6 ULA range via VIP

What still works?
IPv4 routing. Everything is fine
IPv6 GUA routing. Everyting works

I can still access ULA ranges from the regular LAN to the vlans. I can ping and traceroute devices in the other vlans

Whats is broken?
From the Wifi and the server vlan, I can't access devices on other vlans. Also they can't ping the ULA address of the firewall of their own subnet.

This worked before. I didn't change any settings. The only thing I did was preform the update. I have rebooted the firewall multiple times. The devices on the subnet aswell. What could possibly go wrong?

Thanks in advance!

[Bob.Dig]

@gwabber I tested this with 23.09.1 and to me it looks like that the built-in subnet alias wasn't working for me on that other subnet but it is working for the LAN. When I changed the source to any on that other subnet, ping went through even towards LAN.

I asked the question before and didn't get an answer, where can we see what the built-in "subnets" actually contain. Maybe @johnpoz knows the answer, even if it is IPv6 related in this context.

[gwabber]

@Bob-Dig Thanks for your reply!

It sucks, but it's good to read that I am not the only one with this problem! Even the detail that it does work on the LAN applies to my situation.
Setting the source to "any" did do the trick for me! So thank you for that!
I want to keep this setting, but does this have any security flaws?

I hope @johnpoz may help us :) Maybe there is a possibillity to edit the "subnets" alias?

[Bob.Dig]

@gwabber I created a bug report.

[johnpoz]

@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

[Bob.Dig]

@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.

[gwabber]

@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!

[johnpoz]

@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?

[gwabber]

@johnpoz I saw that @Bob-Dig created the a report here: https://redmine.pfsense.org/issues/15096 He refered to this threat.

[johnpoz]

@gwabber yeah I see that, will add my comments.

Looks like it shows IPv4 vips, just not ula IPv6 vips..

[gwabber]

@johnpoz Awesome that you pick this up so quickly! Thanks in advance :)

[Bob.Dig]

@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.

[gwabber]

@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

[johnpoz]

@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.

[gwabber]

I know, but you are willing to help and add info to the bugreport, so I appreciate that!

[johnpoz]

@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..

[Bob.Dig]

@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.

[johnpoz]

@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..

[Bob.Dig]

@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.

[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.