@Lou-Erickson said in Struggling to get basic IPv6 working...:

My copy of "IPv6 Essentials" has arrived

That is an excellent book for IPv6, though it's about the general principles and doesn't get into connecting to an ISP, DHCPv6-PD, etc.. It's also a good idea to use Wireshark, to examine what's actually on the wire.

BTW, I have copies of that book on both my computer and tablet.

@S_Alex

Here's something you can try that might provide some useful info. Disconnect the WAN cable. Run Packet Capture, filtering on DHCPv6 and then reconnect the WAN cable. Download the capture and post it here. I'm assuming they use DHCPv6.

@meluvalli

Do a capture packet on DHCPv6 and one of the client addresses to see what's happening.
Also, check the lease time. The client should not lose the address before the lease expires.

Yes, sorry, I was not very precise regarding the "not to use IPv6 for internal communication for now". I meant more I'm not using it explicitly like e.g. having DNS entries for my local servers (NAS etc.), having firewall rules that allow specific IPv6 traffic (e.g. from or to specific hosts between VLANs) etc..

Generally, I want to push IPv6 as far as possible, but without any compromise or "ugly" setups. IPv6 addresses are running out and in my opinion everyone should do their part moving to IPv6 (and I'm also very interested in it ;) ). And IPv6 definitely has its advantages, e.g. like getting rid of NAT. (Using NPt is fine from my perspective, because it's 1:1 without any state, and it's very helpful e.g. for Multi-WAN setups.)

My setup looks like this:

I have two ISPs that support full DualStack with dynamic /56 prefixes via DHCPv6. But because of https://redmine.pfsense.org/issues/6880 I have disabled IPv6 completely for "WAN2" (actually OPT1 ;) ). (As soon as this issue is solved, I maybe use WAN1 for some VLANs and WAN2 for others. Currently for IPv4 I have a setup where some VLANs use WAN1 with fallback to WAN2 and for some others the other way around.) For most VLANs I have IPv6 enabled using "track interface", but for some I have disabled it. I use "Stateless DHCP", so SLAAC for address configuration. (DHCP e.g. to distribute the name server, but my DNS doesn't include any local DNS entries apart from the one of pfSense that pfSense adds automatically.) I block basically all IPv6 communication between VLANs using a block rule with "xxx net". I need this, because I want to allow Internet traffic where I need an "allow to any". I haven't found any other way to block IPv6 traffic between my VLANs, but allow it for Internet. For IPv4 it's easily done with one "block 192.168.0.0/16" rule, but as discussed above this doesn't work when I get my prefix dynamically via DHCP without a variable or an automatically generated alias that contains the whole prefix or whatever. The downside with the "xxx net" approach is that for n VLANs you need n*n rules (so in my setup 5*5=25) instead of just n, or even 0, because with an alias I could already exclude local traffic from the "allow to any" rule. I "don't care" (at least in the context of this discussion) what happens within my VLANs, because when IPv6 is used there somewhere "automatically", it's just an implementation detail. If I want to control the traffic within a VLAN, I have to go down to layer 2. What does it help when I block IPv6 there and the devices use another never-heard-of protocol on top of layer 2. My switches (Cisco SG300) have some layer 2 filtering capabilities I think, but I haven't used it so far.

Well, I think that's it basically. I will move on further as soon as more pfSense features support dynamic prefixes. For example when 6880 is solved and NPt support dynamic prefixes, I will try to extend my Multi-WAN setup to IPv6. As I will then also have ULAs, I will probably then also set up IPv6 DNS entries for my NAS etc. Haven't thought about how to allow only individual hosts to some destinations then (regarding the temporary address problem), but I think I still have some time to think about that before I get to that point. ;) But probably that's not even an issue, because I think all use cases where I need this is some kind of server-to-server communication (e.g. mail server to NAS for backups) that don't need temporary addresses anyway.

@tpalmer0127

What does your ISP provide? Earlier you said /48.

There are coming back but there are no going out. Even the hosts I‘ve never heared.

Don't feel too bad the DOD is still dicking around with even trying to roll out dual stack support ;) And they have been at its since 2003 ;)

@RobertTheSwede

WOW, that is dumb. I have a /56 and have used prefix ID ff for my VPN without issue. Works fine. Their policy should be everything in that /48 prefix should be forwarded to the customer. Also, it's extremely unlikely there would be any traffic for an unused prefix, as there is nothing to trigger it.

Solved!

My ISP digged deep into this and like I thought it was a routing issue on their side!
I moved to another city last year they didn't changed my public fixed IP addresses. Once they changed my IPv6 /56 it all worked.

TL:DR IPv6 routing issue on ISP side.

Tks for your support

@wishyou

Good. When I started with pfSense, that option wasn't available, so my prefix changed on occasion.

@IsaacFL said in Multiple IPv6 capable connections:

/etc/inc/interfaces.inc

It looks as if fe80::1:1 gets statically enforced. So changing the 2nd box might work to see whether there are other problems. The OPNsense code is different here, but I haven't read all relevant interface files so far.

@netblues

Sorry for the heavy handed smudging, wanted to be sure I was t posting unnecessary details re MAC or private addresses, I've tried to be more selective in this response.

Heres the diagnostics that led me to think its something to do with the Ipv6 tunnel to AirVPN.

From my local subnet my local PC gets a IPv4 and IPv6 address

With the egress gateway set to default I can a IP test site ping over both IPv4 and IPv6

% ping -c 3 ifconfig.co PING ifconfig.co (104.28.18.94): 56 data bytes 64 bytes from 104.28.18.94: icmp_seq=0 ttl=54 time=508.991 ms 64 bytes from 104.28.18.94: icmp_seq=1 ttl=54 time=47.812 ms 64 bytes from 104.28.18.94: icmp_seq=2 ttl=54 time=77.452 ms % ping6 -c 3 ifconfig.co PING6(56=40+8+8 bytes) 2605:e000:xxxx:xxxx:9051:ad0b:d360:b654 --> 2606:4700:3032::681c:125e 16 bytes from 2606:4700:3032::681c:125e, icmp_seq=0 hlim=56 time=88.167 ms 16 bytes from 2606:4700:3032::681c:125e, icmp_seq=1 hlim=56 time=92.328 ms 16 bytes from 2606:4700:3032::681c:125e, icmp_seq=2 hlim=56 time=127.620 ms

I can also get an IP address back from curl'ing the site over both IPv4 and IPv6 so I think can correctly conclude my basic DNS, routing and transport is working correctly over the default non VPN gateway.

% curl ifconfig.co 199.249.223.130 % curl -6 ifconfig.co 2605:e000:xxxx:xxxx:9051:ad0b:d360:b654

If I change my gateway to VPN_WAN_V6 for ICMP and TCP/UDP both pings and curl stop functioning. They just hang.

ping6 ifconfig.co PING6(56=40+8+8 bytes) 2605:e000:xxx:xxx:9051:ad0b:d360:b654 --> 2606:4700:3034::681c:135e ^C % curl -6 ifconfig.co ^C

I'm not sure this is useful, but heres the ifconfig of the openvpn interface

ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::ae1f:6bff:fe73:87e0%ovpnc1 prefixlen 64 scopeid 0x1c inet6 fde6:7a:7d20:5a2::1001 prefixlen 64 inet 10.9.162.3 --> 10.9.162.1 netmask 0xffffff00 groups: tun openvpn nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 84260

I'm sure this is a newbie IPv6 user error, theres something I'm not understanding clearly like a possible need to do some address translation for IPv6 traffic egressing over a IPv6 link established in a IPv4 tunnel?

thanks for reading and any suggestions.

@JKnott Yes we have build an instance of pfSense in AWS and firewall been working well with IPv4. Recently we have a project where the equipment we need to remotely manage are IPv6 only. Have turned IPv6 and all seem in place but I can see Firewall blocking the traffic from these devices. WAN and LAN have IPv6 assigned and I can see them in pfSense. Even LAN traffic deosn't seem to be working on IPv6, for example I can ping IPv4 address but not IPv6

I think the solution is true: need more than a /64

Reading about NDP on Wikipedia made some sense and I managed to find a document on RIPE.NET that explained about the importance of being a /64 or more..

I consider my question answered :(

@anthonys

Glad to hear it. Yeah, ISPs sometimes cause their own problems, as the staff doesn't fully understand the differences between IPv4 and IPv6. When I had that problem last year, I had to educate both tier 2 support and the senior tech about what was actually happening. They knew the basics of IPv6, but not some of the finer points. At least you got relatively quick response from your ISP on this. It took me 3 months and a lot of work to get the people who should have fixed the problem to do anything. Since I had my own router, they refused to do anything, even though both the tier 2 guy and senior tech told them it was an ISP problem. What finally did the trick is the senior tech brought his own modem to my home and saw the problem. He then went to the head end and tried with 4 different CMTS. The failure only occurred with the one I was connected to. This was weeks after I provided the error (see above) to them.

BTW, I have decades of experience with telecommunications, computers and networks and so had the ability to work through this problem. A regular customer wouldn't have a hope of getting it resolved.