IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN
-
This log is from /var/log/dhcpd.log
Oct 26 23:16:32 pfSense dhcpd: Sending on BPF/bce0/00:10:18:4d:6a:d4/192.168.3.0/28
Oct 26 23:16:32 pfSense dhcpd: Listening on BPF/em0/b4:b5:2f:b9:19:68/192.168.2.0/28
Oct 26 23:16:32 pfSense dhcpd: Sending on BPF/em0/b4:b5:2f:b9:19:68/192.168.2.0/28
Oct 26 23:16:32 pfSense dhcpd: Sending on Socket/fallback/fallback-net
Oct 26 23:16:32 pfSense dhcpd: Server starting service.
Oct 26 23:16:33 pfSense dhcp6c[85204]: Sending Solicit
Oct 26 23:16:36 pfSense dhcpd: Internet Systems Consortium DHCP Server 4.3.6-P1
Oct 26 23:16:36 pfSense dhcpd: Copyright 2004-2018 Internet Systems Consortium.
Oct 26 23:16:36 pfSense dhcpd: All rights reserved.
Oct 26 23:16:36 pfSense dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Oct 26 23:16:36 pfSense dhcpd: Config file: /etc/dhcpd.conf
Oct 26 23:16:36 pfSense dhcpd: Database file: /var/db/dhcpd.leases
Oct 26 23:16:36 pfSense dhcpd: PID file: /var/run/dhcpd.pid
Oct 26 23:16:36 pfSense dhcpd: Internet Systems Consortium DHCP Server 4.3.6-P1
Oct 26 23:16:36 pfSense dhcpd: Copyright 2004-2018 Internet Systems Consortium.
Oct 26 23:16:36 pfSense dhcpd: All rights reserved.
Oct 26 23:16:36 pfSense dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Oct 26 23:16:36 pfSense dhcpd: Wrote 21 leases to leases file.
Oct 26 23:16:36 pfSense dhcpd: Listening on BPF/bce0/00:10:18:4d:6a:d4/192.168.3.0/28
Oct 26 23:16:36 pfSense dhcpd: Sending on BPF/bce0/00:10:18:4d:6a:d4/192.168.3.0/28
Oct 26 23:16:36 pfSense dhcpd: Listening on BPF/em0/b4:b5:2f:b9:19:68/192.168.2.0/28
Oct 26 23:16:36 pfSense dhcpd: Sending on BPF/em0/b4:b5:2f:b9:19:68/192.168.2.0/28
Oct 26 23:16:36 pfSense dhcpd: Sending on Socket/fallback/fallback-net
Oct 26 23:16:36 pfSense dhcpd: Server starting service.
Oct 26 23:16:37 pfSense dhcp6c[85204]: Sending Solicit
Oct 26 23:16:45 pfSense dhcp6c[85204]: Sending Solicit
Oct 26 23:17:02 pfSense dhcp6c[85204]: Sending Solicit
Oct 26 23:17:10 pfSense dhcpd: reuse_lease: lease age 2156 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.2.11
Oct 26 23:17:10 pfSense dhcpd: DHCPREQUEST for 192.168.2.11 from a4:31:35:85:58:0d (P32) via em0
Oct 26 23:17:10 pfSense dhcpd: DHCPACK on 192.168.2.11 to a4:31:35:85:58:0d (P32) via em0
Oct 26 23:18:13 pfSense dhclient: PREINIT
Oct 26 23:18:13 pfSense dhclient[5075]: DHCPREQUEST on re0 to 255.255.255.255 port 67
Oct 26 23:18:13 pfSense dhclient[5075]: DHCPACK from 192.168.0.1
Oct 26 23:18:13 pfSense dhclient: REBOOT
Oct 26 23:18:13 pfSense dhclient: Starting add_new_address()
Oct 26 23:18:13 pfSense dhclient: ifconfig re0 inet 192.168.0.3 netmask 255.255.255.240 broadcast 192.168.0.15
Oct 26 23:18:13 pfSense dhclient: New IP Address (re0): 192.168.0.3
Oct 26 23:18:13 pfSense dhclient: New Subnet Mask (re0): 255.255.255.240
Oct 26 23:18:13 pfSense dhclient: New Broadcast Address (re0): 192.168.0.15
Oct 26 23:18:13 pfSense dhclient: New Routers (re0): 192.168.0.1
Oct 26 23:18:13 pfSense dhclient: Adding new routes to interface: re0
Oct 26 23:18:13 pfSense dhclient: Creating resolv.conf
Oct 26 23:18:13 pfSense dhclient[5075]: bound to 192.168.0.3 -- renewal in 1800 seconds.
Oct 26 23:18:15 pfSense dhcp6c[16460]: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Oct 26 23:18:15 pfSense dhcp6c[16460]: failed initialize control message authentication
Oct 26 23:18:15 pfSense dhcp6c[16460]: skip opening control port
Oct 26 23:18:16 pfSense dhcp6c[17093]: Sending Solicit
Oct 26 23:18:17 pfSense dhcp6c[17093]: Sending Request
Oct 26 23:18:18 pfSense dhcp6c[17093]: dhcp6c Received REQUEST
Oct 26 23:18:18 pfSense dhcp6c[17093]: add an address 2600:8803:7800:e93e:b6b5:2fff:feb9:1968/63 on em0
Oct 26 23:18:18 pfSense dhcp6c[17093]: status code for PD-0: success
Oct 26 23:18:18 pfSense dhcp6c[17093]: add an address 2600:8803:7800:e930:a149:8b16:189d:3b30/128 on re0
Oct 26 23:18:18 pfSense dhcp6c[17093]: status code for NA-0: success
Oct 26 23:18:19 pfSense dhclient: PREINIT
Oct 26 23:18:19 pfSense dhclient[17087]: DHCPREQUEST on bce1 to 255.255.255.255 port 67
Oct 26 23:18:19 pfSense dhclient[17087]: DHCPACK from 192.168.0.1
Oct 26 23:18:19 pfSense dhclient: REBOOT
Oct 26 23:18:19 pfSense dhclient: Starting add_new_address()
Oct 26 23:18:19 pfSense dhclient: ifconfig bce1 inet 192.168.0.2 netmask 255.255.255.240 broadcast 192.168.0.15
Oct 26 23:18:19 pfSense dhclient: New IP Address (bce1): 192.168.0.2
Oct 26 23:18:19 pfSense dhclient: New Subnet Mask (bce1): 255.255.255.240
Oct 26 23:18:19 pfSense dhclient: New Broadcast Address (bce1): 192.168.0.15
Oct 26 23:18:19 pfSense dhclient: New Routers (bce1): 192.168.0.1
Oct 26 23:18:19 pfSense dhclient: Adding new routes to interface: bce1
Oct 26 23:18:19 pfSense dhclient: Creating resolv.conf
Oct 26 23:18:19 pfSense dhclient[17087]: bound to 192.168.0.2 -- renewal in 1800 seconds. -
This is a snapshot of my NDP table:
The interface IPV6NET has no network attached.
-
So I don't think my issue is the same. I made all of the routing changes you stated, and I have a WAN IP again, but still no addresses propagating to my LAN or PUBLIC_LAN. I also still don't have a functional IPv6 gateway (IPv6 is not multi-wan, only one service provides IPv6). I made a LAN route of 192.168.201.0/23 (LAN is x.x.201.x, VPN is x.x.202.x), a PUBLIC route of 192.168.244.0/24, and the two WAN routes plus Manual Outbound Routing.
Screenshots attached.
-
Yes, I knew your issue was very different with MultiWAN. I wanted to show that assigning with the prefix and the settings I used works just to start some troubleshooting.
I see....your Link Local is showing pending. If you have a WAN IP, it should be a /128. I would check the Interfaces of the main page. I had to manually add that WAN IP address in the Routing section. Sometimes it auto-populates.
Are you using 5 networks? I read that you have a /60, but has not been verified yet. That gives you a prefix ID from 0-f, but f is a new network. If COMCAST has not allowed that subnet for use, then that may be why the modems DHCPv6 is not issuing the /128 address to your WAN, however....
I see that you need at least 5 networks, so a /60 means 16 /64 networks. Using a /60 means you are on a new network. Your local WAN may not be able to see that address or entire network, but you can see the Link-Local only (fe80::), of the localhost, but that's a good thing.
I would try /62, which would allow you a total of 7 nets or Net ID's (Prefix ID's) to use (0-7) just to troubleshoot. A /61 would give you 15 Prefix ID's.
You should see both an IP on your WAN and a different IP for your LAN's/Additional Interfaces. Then you can add the LAN/VPN's Interface IPv6 Subnet to the RA. It will be different from the WAN.
-
So I requested a /62, and adjusted the prefixes for the two LANs to "1" and "3". Got the same /128 on the WAN, none of the other interfaces have IPv6 IPs, and the gateway now lists as "down" instead of "pending".
I did see this in my firewall log though. I have a feeling this is part of my problem. DF69 is the newly generated gateway address.
Oct 27 23:28:56 WAN [fe80::$:$:$:ff82]:547 [2603:$:$:$:$:$:$:df69]:13626 UDP Default deny rule IPv6 (1000000105)
-
So you set it to /60 and the gateway was Online (required config)
You set it to /62 and the gateway is showing Offline (troubleshooting)In this case, /60 is working just fine then and your WAN received the /128 address. The Gateway is Online. The Link-Local is present. Your LAN's are not receiving anything.
Areas to check:
- I'll assume that your NAT is set to Automatic? Your setup may be different here.
- I'll assume that you have a default IPv6 rule on all local interfaces allowing IPv6.
- I'll assume that you cannot determine the RA yet for the Local Interfaces until you receive the delegated IP addresses.
- What does your LAN RA look like in the DHCPv6 settings?
- With a /60, you can ping ipv6.google.com, so everything is working.
@jsnl said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
2603:$:$:0:208:y:y:df69 and a link local of fe80::208:y:y:df69 (the Y's match)
:208 Should match on all Interfaces and not necessarily the Y's. Let's say the Gateway has :2080. The LAN will have :2081, The VLAN will have :2084 and so on (different Prefix ID's)Correction. I was up late.....yes you are right. Both the WAN and Link-Local will match, which means that PFsense is working.
This is where I had the headache and again turned my attention to NAT after observing the firewall traffic.
The next step is to get the local interfaces their IP addresses and then verify that they are all /64 for advertisement to the clients. Inspect the firewall for sure.
-
There is no consistency between /60, /61, /62 as to when the gateway is up, down, or pending. It's pretty random, and often a reboot with no configuration change will fix it.
Just so you have a status update... I'm still in manual nat, and I've added local routes and NAT rules and can now see the fe80:: packet pass my firewall rule. I had to add an fe80::/10 pass rule on my WAN, which feels odd... but I made it for only the two UDP ports to narrow it up. However I still don't have a functioning address on any other interface. So I'm guessing that 1) The script that runs to add/update the gateway isn't functioning properly or completing fully, and 2) the communication that happens between the prefix getting assigned and that delegation getting announced to the RA isn't happening - because the RADVD logs complain about "invalid ::0 routes" and other odd things.
I won't be able to deep dive into this for most of the week... but if you have a good troubleshooting method for me to figure out where along the chain the communication is failing (or which part of the WAN update shell scripts is failing) I'm all ears.
I'll get back to you as soon as I get time between projects. Thanks for your help.
-
No worries and glad I could help. That definitely sounds like a script issue there. I'll have to inquire about more or find a similar issue. I'm using version 2.4.4 I know that this issue exists with 2.4.3 where the track interface did not assign or advertise correctly.
https://redmine.pfsense.org/issues/8429
This was one bug that's listed; IPv6 didn't work properly when using a LAN bridge. I had major issues with that version and upgraded.
-
Ok, so I have some more time to poke around. I'm still noticing some of the same things... gateway goes up and down on WAN and LAN configuration randomly, is always fixed by a reboot, and isn't directly affected by any particular setting. I tried setting a MTU of 1500 (as referenced in another thread re: the arpresolve errors), that didn't help. I notice now in the logs that the WAN RA is assigning the gateway correctly (which is the cable modem link local address)... but I'm seeing a lot of errors and still can't get any of the LANs to grab addresses.
For the purposes of these logs... "lagg0.201" is LAN, "lagg0.244" is PUBLIC_LAN.
Nov 1 17:52:06 firewall kernel: cannot forward src fe80:$::$:$:$:b668, dst 2001:4860:4806:4::, nxt 17, rcvif lagg0.201, outif igb1 Nov 1 17:55:02 firewall php-fpm: /rc.newwanipv6: rc.newwanipv6: Info: starting on igb1. Nov 1 17:55:02 firewall php-fpm: /rc.newwanipv6: rc.newwanipv6: on (IP address: 2603:$:$:$:$:$:$:df69) (interface: wan) (real interface: igb1). Nov 1 17:55:04 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:04 firewall dhcpleases: Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. Nov 1 17:55:05 firewall check_reload_status: Syncing firewall Nov 1 17:55:09 firewall kernel: arpresolve: can't allocate llinfo for 50.$.$.58 on igb1 Nov 1 17:55:10 firewall kernel: arpresolve: can't allocate llinfo for 50.$.$.58 on igb1 Nov 1 17:55:10 firewall kernel: arpresolve: can't allocate llinfo for 50.$.$.58 on igb1 Nov 1 17:55:10 firewall kernel: arpresolve: can't allocate llinfo for 50.$.$.58 on igb1 Nov 1 17:55:10 firewall kernel: arpresolve: can't allocate llinfo for 50.$.$.58 on igb1 Nov 1 17:55:10 firewall php-fpm[20847]: /interfaces.php: calling interface_dhcpv6_configure. Nov 1 17:55:10 firewall php-fpm[20847]: /interfaces.php: Accept router advertisements on interface igb1 Nov 1 17:55:10 firewall php-fpm[20847]: /interfaces.php: Starting rtsold process Nov 1 17:55:12 firewall php-fpm[20847]: /interfaces.php: Gateway, switch to: ComcastGW Nov 1 17:55:12 firewall php-fpm[20847]: /interfaces.php: Default gateway setting Comcast Upstream Gateway as default. Nov 1 17:55:12 firewall check_reload_status: Restarting ipsec tunnels Nov 1 17:55:12 firewall rtsold: Received RA specifying route fe80::$:$:$:df69 for interface wan(igb1) Nov 1 17:55:12 firewall rtsold: Starting dhcp6 client for interface wan(igb1) Nov 1 17:55:12 firewall php-fpm: /rc.newwanipv6: Keep current gateway, its already part of the group members. Nov 1 17:55:13 firewall php-fpm: /rc.newwanipv6: Keep current gateway, its already part of the group members. Nov 1 17:55:13 firewall dhcpleases: kqueue error: unkown Nov 1 17:55:13 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:15 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:15 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:15 firewall dhcpleases: kqueue error: unkown Nov 1 17:55:16 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:16 firewall php-fpm: /rc.newwanipv6: Keep current gateway, its already part of the group members. Nov 1 17:55:16 firewall php-fpm: /rc.newwanipv6: Keep current gateway, its already part of the group members. Nov 1 17:55:16 firewall php-fpm: /rc.newwanipv6: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1541109316] unbound[93148:0] error: bind: address already in use [1541109316] unbound[93148:0] fatal error: could not open ports' Nov 1 17:55:16 firewall dhcpleases: kqueue error: unkown Nov 1 17:55:17 firewall check_reload_status: updating dyndns wan Nov 1 17:55:17 firewall kernel: lagg0.201: promiscuous mode disabled Nov 1 17:55:17 firewall kernel: vlan0: changing name to 'lagg0.201' Nov 1 17:55:19 firewall php-fpm: /rc.newwanipv6: Removing static route for monitor 75.75.75.75 and adding a new route through 50.$.$.58 Nov 1 17:55:19 firewall php-fpm: /rc.newwanipv6: Removing static route for monitor 2607:f8b0:4000:812::200e and adding a new route through fe80::$:$:$:df69%igb1 Nov 1 17:55:19 firewall php-fpm: /rc.newwanipv6: Removing static route for monitor 64.233.217.2 and adding a new route through 24.$.$.1 Nov 1 17:55:19 firewall php-fpm: /rc.dyndns.update: Keep current gateway, its already part of the group members. Nov 1 17:55:20 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:20 firewall dhcpleases: Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. Nov 1 17:55:23 firewall rc.gateway_alarm[36097]: >>> Gateway alarm: WAN_DHCP6 (Addr:2607:f8b0:4000:812::200e Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%) Nov 1 17:55:23 firewall php-fpm: /rc.newwanipv6: Keep current gateway, its already part of the group members. Nov 1 17:55:23 firewall check_reload_status: updating dyndns WAN_DHCP6 Nov 1 17:55:23 firewall check_reload_status: Restarting ipsec tunnels Nov 1 17:55:23 firewall check_reload_status: Restarting OpenVPN tunnels/interfaces Nov 1 17:55:23 firewall check_reload_status: Reloading filter Nov 1 17:55:23 firewall check_reload_status: Reloading filter Nov 1 17:55:24 firewall php-fpm: /rc.openvpn: Keep current gateway, its already part of the group members. Nov 1 17:55:24 firewall php-fpm: /rc.dyndns.update: Keep current gateway, its already part of the group members. Nov 1 17:55:24 firewall php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP6. Nov 1 17:55:24 firewall php-fpm: /rc.filter_configure_sync: Keep current gateway, its already part of the group members. Nov 1 17:55:24 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:24 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:24 firewall dhcpleases: kqueue error: unkown Nov 1 17:55:25 firewall php-fpm: /rc.filter_configure_sync: Keep current gateway, its already part of the group members. Nov 1 17:55:25 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:25 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:25 firewall check_reload_status: Restarting ipsec tunnels Nov 1 17:55:27 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:27 firewall dhcpleases: Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. Nov 1 17:55:28 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:29 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:29 firewall dhcpleases: kqueue error: unkown Nov 1 17:55:31 firewall check_reload_status: updating dyndns lan Nov 1 17:55:31 firewall kernel: igb0: promiscuous mode disabled Nov 1 17:55:31 firewall kernel: igb2: promiscuous mode disabled Nov 1 17:55:31 firewall kernel: lagg0: promiscuous mode disabled Nov 1 17:55:31 firewall kernel: lagg0.244: promiscuous mode disabled Nov 1 17:55:31 firewall kernel: vlan1: changing name to 'lagg0.244' Nov 1 17:55:32 firewall php-fpm: /rc.dyndns.update: Keep current gateway, its already part of the group members. Nov 1 17:55:33 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:33 firewall dhcpleases: Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. Nov 1 17:55:34 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:34 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:34 firewall dhcpleases: kqueue error: unkown Nov 1 17:55:35 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:35 firewall check_reload_status: Restarting ipsec tunnels Nov 1 17:55:38 firewall dhcpleases: /etc/hosts changed size from original! Nov 1 17:55:38 firewall dhcpleases: Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. Nov 1 17:55:39 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:40 firewall php-fpm[20847]: /interfaces.php: Keep current gateway, its already part of the group members. Nov 1 17:55:40 firewall dhcpleases: kqueue error: unkown Nov 1 17:55:42 firewall check_reload_status: updating dyndns opt1 Nov 1 17:55:43 firewall php-fpm: /rc.dyndns.update: Keep current gateway, its already part of the group members. Nov 1 17:55:44 firewall php-fpm[20847]: /interfaces.php: Removing static route for monitor 75.75.75.75 and adding a new route through 50.$.$.58 Nov 1 17:55:44 firewall php-fpm[20847]: /interfaces.php: Removing static route for monitor 2607:f8b0:4000:812::200e and adding a new route through fe80::$:$:$:df69%igb1 Nov 1 17:55:44 firewall php-fpm[20847]: /interfaces.php: Removing static route for monitor 64.233.217.2 and adding a new route through 24.$.$.1 Nov 1 17:55:44 firewall check_reload_status: Reloading filter Nov 1 17:55:44 firewall php-fpm[20847]: /interfaces.php: Creating rrd update script Nov 1 17:55:44 firewall firewall.gardencitymi.org nginx: 2018/11/01 17:55:44 [crit] 58340#100233: *5436 SSL_write() failed (SSL:) (13: Permission denied) while processing HTTP/2 connection, client: 192.168.202.2, server: 0.0.0.0:443 Nov 1 17:55:48 firewall php-fpm: /rc.filter_configure_sync: Keep current gateway, its already part of the group members. Nov 1 17:55:48 firewall rc.gateway_alarm[11005]: >>> Gateway alarm: WAN_DHCP6 (Addr:2607:f8b0:4000:812::200e Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%) Nov 1 17:55:48 firewall check_reload_status: updating dyndns WAN_DHCP6 Nov 1 17:55:48 firewall check_reload_status: Restarting ipsec tunnels Nov 1 17:55:48 firewall check_reload_status: Restarting OpenVPN tunnels/interfaces Nov 1 17:55:48 firewall check_reload_status: Reloading filter Nov 1 17:55:49 firewall php-fpm: /rc.openvpn: Keep current gateway, its already part of the group members. Nov 1 17:55:49 firewall php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP6. Nov 1 17:55:49 firewall php-fpm: /rc.dyndns.update: Keep current gateway, its already part of the group members. Nov 1 17:55:49 firewall php-fpm[20847]: /rc.filter_configure_sync: Keep current gateway, its already part of the group members.
Now I also noticed this while doing a radvdump:
# # radvd configuration generated by radvdump 2.17 # based on Router Advertisement from fe80::1:1 # received by interface lagg0.201 # interface lagg0.201 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag on; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 30; AdvHomeAgentFlag off; AdvDefaultPreference medium; AdvLinkMTU 1500; AdvSourceLLAddress on; DNSSL $.org { AdvDNSSLLifetime 10; }; # End of DNSSL definition }; # End of interface definition # # radvd configuration generated by radvdump 2.17 # based on Router Advertisement from fe80::1:1 # received by interface lagg0.244 # interface lagg0.244 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag on; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 30; AdvHomeAgentFlag off; AdvDefaultPreference medium; AdvLinkMTU 1500; AdvSourceLLAddress on; DNSSL $.org { AdvDNSSLLifetime 10; }; # End of DNSSL definition }; # End of interface definition # # radvd configuration generated by radvdump 2.17 # based on Router Advertisement from fe80::$:$:$:df69 # received by interface igb1 # interface igb1 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag off; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 60; AdvHomeAgentFlag off; AdvDefaultPreference high; AdvLinkMTU 1500; AdvSourceLLAddress on; prefix 2603:$:$::/64 { AdvValidLifetime 86400; AdvPreferredLifetime 14400; AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; # End of prefix definition route ::/0 { AdvRoutePreference high; AdvRouteLifetime 60; }; # End of route definition RDNSS 2001:4860:4860::8888 2001:4860:4860::8844 2001:558:feed::1 { AdvRDNSSLifetime 20; }; # End of RDNSS definition DNSSL $.org { AdvDNSSLLifetime 20; }; # End of DNSSL definition }; # End of interface definition
...Is that telling me that I'm only getting a /64 with my /60 request on igb1?? Just as an experiment I changed LAN to prefix 0, but still got no LAN address. I read some other posts about adding static routes to make things work... but since I don't have fixed ipv6 addresses, that seems like a bad idea. I figure if I do that, I might as well do static addressing everywhere - and the first time I lose my leases, everything will go to hell.
Thoughts?
-
@jsnl said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
2607:f8b0
Yes. You should have a 16 /64 networks. The WAN IP should be a /64, which is what I see in both snapshots. It appears that your WAN DHCP6 is a 2607 address? It looks as if it should monitor the 2603 address from Comcast's WAN. That's what I see so far.
-
@smitheo1 said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
It appears that your WAN DHCP6 is a 2607 address?
No, that's just the IP that it pings every 2 seconds to see if the gateway is up or not. That 2607:f8b0:4003:c00::6a address is ipv6.google.com - the address I'm pinging to make sure I actually have ipv6 connectivity to the world and not just locally with Comcast. Once I get everything up and running I might change it to something locally on Comcast's domain, but for now I want to make sure I can see the internet in IPv6.
Is there any log I can see to know if the actual /60 prefix exchange is successful? Can I sniff it on the firewall in any way? Or do I have to wireshark it with an external laptop?
-
Ok. I'm tracking.
Yes. You can see the exchange with Wireshark from the client side. You should also be able to sniff the firewall as well. The firewall has the Packet Capture in the Diagnostics section. That's how I learned that something was not passing through.
-
Try taking a look around in /etc/defaults/rc.conf which is where the addresses are stored to see if something is active.
-
Sorry it's been a long time, but....what I have done was not use Track Interface. The LAN needs a (non routable IPv6) Static address. Make one up..... 2000:1000:AEAE:3000::1/64 for example. Check and verify if the WAN gateway in the Routing section is using a link-local address from the router. If so, add the Global IPv6 address to the Routing on the WAN interface and disable the link-local IPv6 address. The link-local one is not routable.
If you set the WAN to /56 or whatever, then it's fine. Track Interface takes a routable IPv6 address and assigns it to the LAN, which is not how it's supposed to work, because that is a private network.
-
@smitheo1 said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
Sorry it's been a long time, but....what I have done was not use Track Interface. The LAN needs a (non routable IPv6) Static address. Make one up..... 2000:1000:AEAE:3000::1/64 for example. Check and verify if the WAN gateway in the Routing section is using a link-local address from the router. If so, add the Global IPv6 address to the Routing on the WAN interface and disable the link-local IPv6 address. The link-local one is not routable.
If you set the WAN to /56 or whatever, then it's fine. Track Interface takes a routable IPv6 address and assigns it to the LAN, which is not how it's supposed to work, because that is a private network.
There appears to be a lot of nonsense in your post. For example, why would you assign a non routeable address to the LAN? Also, the one you used is routeable. It's just not yours. Global Unique Addresses start with 2 or 3. Also, disabling the link local address will break a lot of things such as neighbour and router discovery & advertisements and more. And link local addresses are often used for routing in IPv6. Also, what the heck do you mean by "Track Interface takes a routable IPv6 address and assigns it to the LAN, which is not how it's supposed to work, because that is a private network."? Also, WAN addresses are often /128. In an earlier post you say it should be a /64 and another, /128. Incidentally, that /128 plays no roll in routing to the network. It is simply an address used to access the firewall/router. -
@JKnott You use the Global Gateway's delegated network. Track Interface uses the Global Gateway's network to assign a delegated IPv6 address to the LAN.....bad idea. That's why a ton of people are having problems. What's being routed is the delegated network via the /64. 2000:: is a Global network, but the gateway modem's Global network should not overlap with the LAN because it's routable to the Internet.
The firewall/router automatically assigns the link local as the WAN gateway.....it's not routeable dude. IT GOES NOWHERE!!!!! Add the correct Global WAN IPv6 Gateway manually when that happens and turn off the link local. The firewall already knows what that is.
Furthermore, the NAT is blocking all IPv6 by default, so I made the proper NAT.
You obviously don't know how to provide a solution, because I am fully operational with IPv6. It's not nonsense to a certified engineer.
-
@smitheo1 said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
You obviously don't know how to provide a solution, because I am fully operational with IPv6. It's not nonsense to a certified engineer.
I have also been operational with IPv6 for over 9 years, initially with a 6in4 tunnel, but the past 3.5 years as provided by my ISP. What sort of engineer? I'm a Cisco CCNA and have been working with networks since before Ethernet and IP, in fact before packets were used. I also did Novell CNA & CNE, many years ago. I also did Electrical Engineering, with telecommunications systems for my elective subjects.
You introduced NAT to this thread. Why do you need NAT to get IPv6 working? I've never had to use it. NAT is a hack to get around the IPv4 address shortage, so there's no need for it with IPv6.
As for my working network, it uses DHCPv6-PD from my ISP. This provides a /128 WAN address for pfSense and a /56 prefix, which I can split into individual /64s. I currently use 3. I use track interface and it works fine. I also have some Unique Local Addresses configured. They work too, but can't reach the internet by using those addresses. Tell me again why you need NAT, manually configured addresses, etc., to get your network to work. Again, if you turn off link local (is that even possible?), you will break things that IPv6 depends on. Link local addresses are mandatory for IPv6. Every device capable of IPv6 has a link local address (FE80:: /16), even if it has no other IPv6 address.
-
@JKnott IPv6 This firewall software is so bugged....and I see people modifying the radvd to make it work. It's actually the Track Interface. What will happen if you use the Track Interface, the LAN will have an IP from the Global Gateway's pool when it actually need a static address in the 2000 or above...omitting the Global IPv6's WAN network. When the lease expires (because it's tracking one of the the 16 delegated /64....with a /56), it will stop working and you will need to reboot the firewall to gain a new lease. That's not how it's supposed to be applied to the private LANs.
NAT is not a hack. It's a translation of private IP address to one public address. You need to use a static IPv6 that is not routable to the Internet, but will translate to the WAN's /128, which brings me to the next situation. It was all being blocked.
"Tell me again why you need NAT, manually configured addresses, etc., to get your network to work. Again, if you turn off link local (is that even possible?), you will break things that IPv6 depends on."
We were doing troubleshooting a long time ago while following Netgate's instructions and it didn't work. I then started observing the firewall logs and they were all blocked...localhosts and all. I created a manual NAT rule (because of the required link-local and local hosts including the LAN translations) that allows everything to be translated over the WAN and it started working.
When the Automatic Outbound NAT is checked, it's as if the product was locked down. IPv4 works just fine. Most of the time, it's the other way around.....the product works with most rules being applied to allow all traffic then can become locked down or blocked by an organization or person.
-
Notice the COX entry. I had to manually add it because the link-local entry was automatically added. I went nowhere in the land of link-local.
-
@smitheo1 said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
This firewall software is so bugged
Then how is it working so well for so many?
NAT is not a hack.
It was created to get around the address shortage, as there are nowhere near enough IPv4 addresses to go around. I am aware that it is also sometimes used to remap networks, to get around collisions caused by trying to merge 2 networks, where both are on the same RFC1918 address blocks. In short, it's again a hack to get around a problem caused by hack to get around the address shortage. If you can't get an IPv6 network operating properly, without NAT, then I would have to question your competence as an "engineer".
I went nowhere in the land of link-local.
Here is my gateway: fe80::217:10ff:fe9a:a199
That sure looks like a link local address to me. -
Note the LAN Interface. 2000:xxxx:xxxx:xxxx::1 x can be whatever you need as long as it's not 2600:xxxx....because it is the Global IPv6 gateway. The firewall will return an error that it's being used and overlaps with 2600:xxxx
I requested a /62, so I use 4 /64 networks on the private interfaces, but it's actually 2 /64's in use.
-
@JKnott No it doesn't work for many. I don't teach certified individuals to call anything a hack and I'm glad that you don't have more than 20 years of experience now. Have a nice day, but you are just being a troll. I was here to help the gentleman at the beginning of this thread.
-
@smitheo1 said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
I was here to help the gentleman at the beginning of this thread.
I don't recall him asking to use NAT. You were the first to mention it. He was having issues and some of what he said indicates he doesn't fully understand how certain things work, such as not realizing that a link local address is entirely valid as a gateway address, as I have to my ISP. On my local network, the gateway is pfSense with an address fe80::1:1. Yep, that's another link local address as provided by pfSense to devices on my LAN. While the OP may have issues, NAT is not the answer.
As for myself, I have been working with networks, going back to 1978 (Air Canada reservation system on a proprietary Rockwell Collins network). I first learned about IPv4 in 1995, incidentally about the same time I first heard of IPv6. In addition to IP & Ethernet, I have also worked with SNA, token ring, DECnet and IPX. I also worked at IBM, providing 3rd level support, including on network issues. I have also completed network courses at a couple of local colleges and IBM, along with a lot of self study.
-
The biggest problem are dynamic prefixes. With that you can't assaign a static LAN interface. You also can't use NPt because pfSense can't handle with dynmic prefixes.
-
@mrsunfire said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
The biggest problem are dynamic prefixes. With that you can't assaign a static LAN interface.
With DUID, the prefix should be essentially static. There's a setting "Do not allow PD/Address release" on the WAN page to prevent the prefix from being released.
-
True, but if the connection is failing for more than 1 hour my ISP give me a new prefix whatever I do.
-
@JKnott said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
Here is my gateway: fe80::217:10ff:fe9a:a199
That sure looks like a link local address to me.That routes to nowhere. Quit kidding yourself.
-
@smitheo1 said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
@JKnott said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
Here is my gateway: fe80::217:10ff:fe9a:a199
That sure looks like a link local address to me.That routes to nowhere. Quit kidding yourself.
Here's what my computer, running Linux, shows:
ip -6 route show
2607:fea8:4c81:673::/64 dev eth0 proto kernel metric 256 expires 86389sec pref medium
fd48:1a37:2160::/64 dev eth0 proto kernel metric 256 expires 86389sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1:1 dev eth0 proto ra metric 1024 expires 49sec hoplimit 64 pref mediumNotice that default route at the bottom? That's a link local address pointing to pfSense.
Now, on my pfSense box for the default route to my ISP:
/root: route -6 show default
route to: default
destination: default
mask: default
gateway: fe80::217:10ff:fe9a:a199%re0
fib: 0
interface: re0
flags: <UP,GATEWAY,DONE>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0Take a look at the gateway. That's also a link local address, pointing to my ISP.
On IPv6, link local addresses are often used for routing, as shown in both examples above. With routing, all routing, all you need to know is how to get to the next hop. This could be a routeable address, link local address (IPv6 only) or in the case of a point to point link, the interface that connects to the next hop.
My pfSense box also has a routeable address, assigned by my ISP. However, it's a /128, which means it can't be used to communicate with anything, without being routed by pfSense.
Please stop proving you're clueless about IPv6.
-
Let me get this right.. Your suggesting the OP use whatever they want - ie just pull some address block out of the air and use it locally.. And then nat that to the IPv6 wan address he gets..
That is your solution?
Sorry dude but that is not a solution, that is a HACK... And not what the OP was asking for at all, that is not teaching anyone anything..
Why did this thread get brought back from the dead in the first place - this is from oct 2018??
If someone is having a problem with ipv6 working on pfsense, then it should be correctly troubleshot to figure out why.. Not setup some nonsense ipv6 nat..
-
@johnpoz said in IPv6 WAN Track Interface not assigning addresses to LAN/Public LAN:
ie just pull some address block out of the air and use it locally.. And then nat that to the IPv6 wan address he gets..
I guess this "engineer" hasn't heard of Unique Local Addresses, which is what would be used for that sort of thing.
-
^ exactly! suggesting they use part of the global space 2000/3 is just not right... 2000 has not been allocated yet.. Doesn't mean you can just freaking use whatever space you want in it.
Concur if you were going to do such a hack, which I wouldn't suggest at all. Then yes ULA space would be the way to go, prob look into central assigned... have to lookup the rfc - its to prevent overlap how you can run into with rf1918 space..
If what you want is to use ula internal - then sure go for it, and do your Npt with that.. If he is having issues with his isp and getting prefix to work, etc. I would bet some serious money its the isp doing something wrong! ;)
The correct solution would be to figure out what is wrong, so maybe the isp can be informed, pfsense can be setup to allow for whatever is causing the issue, etc. etc.
But no some nat to whatever his isp gives him via some /64 on his wan and natting that is not the path.. Might be something you could do if hey need this up NOW... But this isn't production, the OP has zero actual "need" for ipv6.. Since really nobody actually does.. Unless there was some black site p0rn site he needed to get to that only is on ipv6 ;)
So figure out what the actual problem is and fix correctly..
-
So much bad information in this thread. I'm locking it. Start another one with whatever the current problem is. Thanks.