pfSense

Marcel Mayer wrote:

As you can see here (logfiles attached in threads!)

(English)https://forum.pfsense.org/index.php?topic=119439.0
(German) https://forum.pfsense.org/index.php?topic=119409.0

there seems to be a bug in the implementation of handling IPv6 over PPPoE or in dhcpcd6. The logfile will be flooded and the connection will be reset every few seconds. In generally IPv6 works. Clients are getting the correct prefix and RA also works but the periodically reset makes the line unusable, cause connections get lost.

My provider is DTAG which has a quite basic IPv6 deployment setup.

Ticket will be monitored by me and questions answered as soon as possible.

Is your address/pd allocation changing everytime this happens?

There has been a lot of work done around dhcp6c in later versions, you might want to try updating to 2.33. Also, I have a version of dhcp6c I have compiled myself which gives more log information than the distributed version, I could let you have that and see if it reveals anything, you would need to use 2.4 for that though.

The addresses are not changing. They stay.
What do you preffer or suggest? Updating would be ok for me. Is it possible via Webinterface? Or do I have to flash a new image?

Go to System->Updates->Update Settings, change Branch to "Development Snapshots" and save.
Now it will show an upgrade to 2.3.3

Can I make a suggestion. Before you do any major revision updates save a copy of your config file in case you wish to revert or test other versions, a little painful experience taught me this lesson. Once you have migrated to 2.3.3 see how things are with that version, then if you wish you can then try 2.4, again remember to back up the config before migrating. When you get to 2.4 let me know and I can send you my test version of the dhcp6c suite.

Note... If you go to 2.4 do some research before you do to make sure that any packages you use are compatible with 2.4, pfBlocker for example can cause problems at present as it's not yet been made totally 2.4 compatible.

Does this issue seem similar to bug #6000? If so I can probably help.
Rick

#6000 is about virtual IP's or am I missing something... quite possible at my age. :)

Thank you Rick Strangman for the reply. I don't think, the issus are similar.
The Update will be scheduled for next weekend. So I report in here my results.

Regards^^

Marcel Kallinger

It would be interesting to see what your dhcp6 is doing at the same time, could you post a snippit of both logs. I see the same entries as you, but only once every thirty minutes as dhcp6c renews on timeout; the ISP sets that period. Now, my dhcp6c client gives me the timeout in the logs as shown here, my entries show newest at top:

Dec 5 10:18:43 dhcp6c 91606 update a prefix 2a02:xxx:xxx:xxxx::/56 pltime=3600, vltime=3600
Dec 5 10:18:43 dhcp6c 91606 dhcp6c Received INFO
Dec 5 10:18:43 dhcp6c 91606 send renew to ff02::1:2%re0

and from the general log:

Dec 5 10:18:47 xinetd 24097 Reconfigured: new=0 old=1 dropped=0 (services)
Dec 5 10:18:47 xinetd 24097 readjusting service 6969-udp
Dec 5 10:18:47 xinetd 24097 Swapping defaults
Dec 5 10:18:47 xinetd 24097 Starting reconfiguration
Dec 5 10:18:46 check_reload_status Reloading filter
Dec 5 10:18:46 php-fpm 55520 /rc.newwanipv6: Removing static route for monitor fe80::xxx:xxxx:xxxx:xxxx and adding a new route through fe80::xxx:xxxx:xxxx:xxxx%re0
Dec 5 10:18:46 php-fpm 55520 /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::xxx:xxxx:xxxx:xxxx%re0
Dec 5 10:18:43 php-fpm 55520 /rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::xxx:xxxx:xxxx:xxxx%re0) (interface: wan) (real interface: re0).
Dec 5 10:18:43 php-fpm 55520 /rc.newwanipv6: rc.newwanipv6: Info: starting on re0.

Naturally, although the allocation time is sixty minutes, the renew happens at half that period.

Sorry, seems like bug #6000 has been deleted and i was not refering to feature #6000

I started to do the test today and realised, that IPv6 is working for the moment without the described issue.
Used this how-to in past: https://moerbst.wordpress.com/2016/07/31/ipv6mit-pfsense-an-dsl-der-telekom/
So the ticket can be closed (for the moment).

Are there informations or logfiles you still want to have?

Found the solution for that.
The Leasetable hold two entries (no idea why). After deleting them, everything now works like a charm.

Thank you guys, for the support, merry christmas and a happy new year^^

What do you have selected in DNS Resolver/General - Network Interfaces and Outgoing interfaces?

DNS Resolver/General - Network Interfaces and Outgoing interfaces = both are set to "All"

Removed dhcpd from monitoring by watchdog. Now the log looks better (see attached).

That now looks pretty normal.

I think System Watchdog needs some dusting off. I stopped using it a while ago as it seems to cause more problems than it solves at this point.

The only thing that the watchdog does is setting up a cronjob which in turn checks every minute whether configured services are running. If not, it starts them. Cannot imagine what dusting off could be done there. Having stuff like https://mmonit.com/monit/ available would be much better, if someone wants to package it.

@Kill Bill: Deactivating watchdog solves my issue. It realy seems to make some trouble running it at moment. Especailly with DHCP.

And I think it's important that this seems to be a problem with dhcp6c and NOT dhcp6d.

Don't delete the DUID mid session, its pointless, dhcp6c will generate a new one, which means that your ISP then sees another DUID which can confuse the BNG. Does your ISP supply a router? If so can you do a wireshark packet capture to grab the ipv6 dhcp packets and post them here? Can you also post your v6 configuration settings.

The server was replying with no addresses which is interesting, dhcp6c then just recycles as the timeout is 0. Do you also know exactly what options your ISP requires?

The ISP (Deutsche Telekom) doesn't supply a router, so I can't do any Wireshark capture there. The German Telekom uses PPPoE for IPv4 and DHCP6 for IPv6. The DHCP6 information should be requested through the IPv4 connection. A /64 prefix should be handed out to be used on the WAN interface and another /56 prefix is handed out for the LAN side.

Please note that the Telekom is currently switching customers from their old backbone network to a new one called BNG (yes, very generic, but that's what they call it ...). The IPv6 behaviour should be the same for both backbones and it worked for me without issues while my line was connected to the old backbone. After my line was transferred to the BNG IPv6 showed the behaviour I am reporting.

It seems that there is something strange going on with the BNG's IPv6 implementation as several router manufacturers had to update their firmware for IPv6 to work with the BNG. The most notable example being bintec who had to update a firmware for a business router they build for the German Telekom. From a forum entry at the Telekom's customer forum I could gather that during prefix delegation the router should request a renew instead of requesting a new prefix. This would be something that wouldn't work at the moment. Does this make sense?

The configuration settings of the WAN interface are as follows:

=== General Configuration ===
Enable Interface: checked
Description: WAN
IPv4 Configuration Type: PPPoE
IPv6 Configuration Type: DHCP6
MAC Address: <empty>
MTU: <empty>
MSS: <empty>

=== DHCP6 Client Configuration ===
Options:
Advanced Configuration: unchecked
Configuration Override: unchecked
Use IPv4 connectivity as parent interface: checked
Request only an IPv6 prefix: Unchecked
DHCPv6 Prefix Delegation size: 56
Send IPv6 prefix hint: checked
debug: unchecked

=== PPPoE Configuration ===
Username: <username>
Password: <password>
Service name: <empty>
Dial on demand: unchecked
Idle timeout: <empty>
Periodic reset: Disabled
Advanced and MLPP: No changes made here

=== Reserved Networks ===
Block private networks and loopback addresses: checked
Block bogon networks: checked

In my opinion we are not talking about a bug any more.
The problem seems to be a missconfiguration ...

For DTAG "Request only an IPv6 prefix: Unchecked" needs to be checked.

When I check "Request only an IPv6 prefix" the WAN interface uses the first /64 prefix (prefix ID 0) out of the /56 prefix that is delegated. But the WAN interface should use the /64 prefix that is being given to the router for the transport segment. If you check this "Request only an IPv6 prefix" you can only start at prefix ID 1 for the LAN interfaces (instead of 0).

BTW: The tutorial that you mentioned earlier doesn't state this either.

It does work, though. But I think this is not the way it is supposed to work. As far as I know DTAG hands out a /64 prefix for the transport segment (i.e. to use this on the WAN side) and another /56 prefix that can be used on the LAN side as several /64 prefixes.

On this page a user did some wireshark captures: https://blog.webernetz.net/2015/05/19/telekom-dual-stack-verbindungsaufbau/

Maybe some of the information in there is helpful? In the middle of the post are some pictures of the wireshark output.

The Address given to the WAN interface is more or less irrelevant, cause it's not realy necessary for your firewall rules.
Devices behind the firewall will be adressed directly. So I think, there will be no problem and starting with ID 1 will be ok.

It does work for me now - Marcel's hint to check "Request only an IPv6 prefix" was indeed correct. After two more reboots it finally worked.

The IPv6 address of the WAN interface is handed out via Router Advertisement after the interface identifiers have been exchanged in the PPP IPV6CP stage. After that the /56 prefix is delegated via DHCP6. So to check the "Request only an IPv6 prefix" is correct.

From my point of view this ticket can be closed.

Happy to helped. Last good action for 2016.
Happy new year^^