ipv6: can ping GUA address in different VLAN, but not ULA.

[chpalmer]

@jknott said in ipv6: can ping GUA address in different VLAN, but not ULA.:

@chpalmer said in ipv6: can ping GUA address in different VLAN, but not ULA.:

I think their use of the word "routable" is misleading as I believe they mean it has to be within the same subnet. Your operating across interfaces thus routing between the addresses.

That is incorrect. They are routeable, but not over the public Internet. They're used just like the RFC1918 addresses on IPv4.

Yep- like I said in my last post..
Looks like your right according to these. IMO it should be routable accross the platform.

[Tanya]

OK, so basically we all agree and think it should work.
That's good, that would mean that the concept of what I'm trying to achieve seems OK.

The bad thing is that - currently - it does not work.
No idea yet if that is caused my a bug, a misconfiguration on my part (missing or wrong firewall rules?) or both?

Does anyone have a clue?

[awebster]

Make sure that these aren't checked in the Interface configuration each VLAN.

[Tanya]

@awebster

Thanks for the suggestion.
I'll check that when I'm back at work on Monday (it's 18:20 over here, working day is done :) )

I'm quite convinced the first option is unchecked, otherwise the ipv4 ping 192.168.x.x would't pass either (it does).
I'm not so sure about the second option. If the default setting is OFF then it is probably still off. I can't remember turning it on, anyway.

But both need doublechecking on Monday. I'll get back with the results when that's done.

[Tanya]

@awebster said in ipv6: can ping GUA address in different VLAN, but not ULA.:

Make sure that these aren't checked in the Interface configuration each VLAN.

I have just double-checked and can confirm that both options are unchecked on all of the VLAN interfaces

[xianic]

I was writing a post asking for help with the same think but I thing though I might have solved it. The setup I have is:

• GUAs on the VLAN interface are statically assigned, tracked should work just as well and would probably be less work for me.
• A /64 ULA prefix for each VLAN on the RA page, e.g fdxx:xxxx:xxxx:a::/64 on VLAN10 and fdxx:xxxx:xxxx:b::/64 on VLAN11
• fdxx:xxxx:xxxx:a::1 and fdxx:xxxx:xxxx:b::1 virtual addresses assigned to each interface
• A firewall rule on VLAN10 interface to allow all traffic from fdxx:xxxx:xxxx:a::/64 to a specific host on VLAN11

Then I can ping the host on VLAN11 from a host on VLAN10. I'm having trouble allowing TCP through at the moment, some more debugging will be required there. Hopefully this is helpful to you.

[Tanya]

@xianic said in ipv6: can ping GUA address in different VLAN, but not ULA.:

• A firewall rule on VLAN10 interface to allow all traffic from fdxx:xxxx:xxxx:a::/64 to a specific host on VLAN11

Then I can ping the host on VLAN11 from a host on VLAN10. I'm having trouble allowing TCP through at the moment, some more debugging will be required there. Hopefully this is helpful to you.

I'm certainly going to check that firewall rule and try if I can get something done that way.
If I understand correctly, the rule you added grants access from (all) your machines on VLAN10 to a single machine on VLAN11?

In my situation, I would need all my machines from the first VLAN to be able to access all of the hosts in the 2nd VLAN. Vice versa, all machines in VLAN2 should only be able to reach a very limited number of machines in VLAN1.

That's how the ip4-equivalent is set up.

@xianic said in ipv6: can ping GUA address in different VLAN, but not ULA.:

• GUAs on the VLAN interface are statically assigned, tracked should work just as well and would probably be less work for me.
• A /64 ULA prefix for each VLAN on the RA page, e.g fdxx:xxxx:xxxx:a::/64 on VLAN10 and fdxx:xxxx:xxxx:b::/64 on VLAN11
• fdxx:xxxx:xxxx:a::1 and fdxx:xxxx:xxxx:b::1 virtual addresses assigned to each interface

Do the Virtual IP and the static GUA still work after you reboot pfsense?
IIRC there is a problem with track interface and virtual IPs where after the reboot the interface only has the virtual IP and no longer the GUA.
That's something I read on the forums and also experienced as such when I was seeing if a virtual IP could help me out with this problem.

Anyhow, you gave me a few things to try. I'll get back with the results soon.

[Tanya]

To do some further testing, I have made a setup with 3 virtual machines

• a new pfSense (version 2.4.3)
• a Windows client (Win7, firewall disabled)
• a 2nd Windows client (Win7, firewall disabled)

These 3 are totally isolated from the rest of my network.
I tried to setup pfSense with as little changes as possible (no VPN, ...), just the ipv6 stuff.

• The WAN is set to auto (DHCP) but not connected (so track interface won't work)

• LAN with Static IPv6: fddd:666:666:90::1

• VLAN91 with Static IPv6: fddd:666:666:91::1

• VLAN92 with Static IPv6: fddd:666:666:92::1

• LAN: RA = assisted

• VLAN92: RA = Stateless DHCP

I put 1 Win client on LAN and one on VLAN92.

The client on LAN:

• got ping replies from the client on VLAN92

The client on VLAN92:

• got ping timeout from the client on LAN
• got ping timeout from the pfSense's interface ipv6 address on LAN

When I copied the "Default Allow LAN IPv6 to any rule" from LAN to VLAN92, both ping commands from VLAN92 started giving replies (I left them running while applying the firewall rule)

...

And then ... I rebooted the firewall.

After the reboot, none of the ping commands seem to work anymore, all just give timeout. (I left them running while rebooting the firewall)

Strange thing is:

• no configuration was changed on the firewall
• no configuration was changed on any of the virtual machines

I can see no changes in the config before the reboot, and the config after the reboot.
Still, it worked before and it doesn't after.
Whatever I do, I can no longer get it to work.

[Tanya]

@xianic said in ipv6: can ping GUA address in different VLAN, but not ULA.:

I was writing a post asking for help with the same think but I thing though I might have solved it. The setup I have is:

• GUAs on the VLAN interface are statically assigned, tracked should work just as well and would probably be less work for me.
• A /64 ULA prefix for each VLAN on the RA page, e.g fdxx:xxxx:xxxx:a::/64 on VLAN10 and fdxx:xxxx:xxxx:b::/64 on VLAN11
• fdxx:xxxx:xxxx:a::1 and fdxx:xxxx:xxxx:b::1 virtual addresses assigned to each interface
• A firewall rule on VLAN10 interface to allow all traffic from fdxx:xxxx:xxxx:a::/64 to a specific host on VLAN11

That doesn't work for me, as - like I more or less suspected - the GUA disappears from the interface after a reboot, and the Virtual IP is assigned to the interface instead.
The net result is that the clients now only get ULA addresses and no longer a GUA.
Hence: no internet access.

In your case, maybe the GUA stays in place because you have defined them as static rather than track interface?

[Tanya]

Anyone with an idea / suggestion / recommendation / something I could try ?
I have run out of ideas, and - alas - made little to no progress at all.

[chpalmer]

@tanya said in ipv6: can ping GUA address in different VLAN, but not ULA.:

In your case, maybe the GUA stays in place because you have defined them as static rather than track interface?

Your using "Track Interface"? If so what interface are you tracking?

[Tanya]

@chpalmer

That's the WAN interface I'm tracking.
Even if I wanted to, the dropdown list doesn't let me select anything else. It's WAN or nothing.
The Track Interface part in itself is working.
It's just that when I add an IP alias (and reboot) that it stops working: the GUA is no longer assigned to the interface, but the virtual IP is.
(even though the configuration it itself is unchanged)

That is IIRC a known bug or issue, I've seen it in a few other posts as well.

[Tanya]

Any other suggestions?

I have tried everything that was suggested and everything I could think of, but no success so far.

Two weeks ago I have created a bug report for the scenario I described above (post 15) where a working setup with ULA addresses stopped functioning after only reboot of the firewall.
Sadly, that too has generated little interest (none in fact) and has been shuffled back to page 2 of the bugtracker.

[UlfMerbold]

Sadly pfsense is atm not fully IPv6 compliant imho, the freeBSD underlying parts are, but not the management parts of pfsense.

It's like in any other linux project, u still get only answers if the developers are interested. :/

For the rest of us, we need to invent the wheel every day again and again.

[Tanya]

Just to check some more, in my test setup (3 virtual machines) I have replaced pfSense with one of its competing products, and applied the same minimal configuration.
Unlike pfSense, this setup keeps working after a reboot of the firewall/router.

This once again confirms that what I intend to do should just work, doesn't it?

Finally, I removed the competing product, and once more installed pfSense from scratch, and again applied the minimal config.
Sadly, it again stops working once the firewall has been rebooted.

I really would like to continue using pfSense, but I do need some help to make this work.

[UlfMerbold]

U have to setup the routes statically since pfsense does all over gui wrappers.

What happens after an reboot is, that the IP ordering GUA/ULA changes and, after all, so some of the needed routes get "lost" this way.

imo i tracked down the error to the interfaces.inc, but since netgate remains silent, i do not see to fix that(have similar IPv6 problems)

[Tanya]

@ulfmerbold

You mean: this is a bug/feature and unless someone solves it, I will never get it to work?

[UlfMerbold]

It isnt a feature, but yeah if u cant solve the ordering issue for self u have to wait and someone of the developers has to fix that bug. And its surely a bug when one setup has different results ->before reboot/after reboot.

Btw, what was the competing product if i may ask?

[UlfMerbold]

Ah ok, know that too but i still tried pfsense to get to work in this case. I need pfblocker for example, so it isnt so easy to change for me.

In your case i would choose the one which does job best, at the end all are a fork of something else.

So vote with your foots and dont stay silent if the support is crap for u, not only the paying customers are customers.

[UlfMerbold]

to the interfaces.inc file:
The specific parts of the script just checks for link local and an interface ipv6, but since IPv6 knows more than one type of an interface IP (GUA and ULA handled by a single function and stops if an matching IP is found)

This could be the reason for the behavior i ve seen for my problem and at the end for ur's too.

For me an ifconfig in a console, i ll get all IPv6 IP's of an specific interface...if i do same in the gui i ll just only get two IP's
So u get for example in GUI an LL+GUA or an LL+ULA, but NOT ULA+GUA+LL

Since most configs generate from the pfsense scripts, the underlying "real" IP's are ignored in this case.

At the end u have missing routes, cause the routes are build from only the half of informations needed

But my programming skills are not so deep to evaluate my thinking, im an hardware guy. :/