Ipv6 issues on WAN (FTTB); AVM Fritz!Box works



  • Hi,

    I'm sitting on a m-net FTTB connection. The normal ipv4 dial is done by pppoe and works just fine. If I enable DHCP6 on WAN nothing happens. I already tried unchecking the bogon networks and I did enable ipv6 support within the general settings. My provider provides a 56bit ipv6 Network, so I selected this for the DHCP6 delegation size.

    If I replace the pfsense box with a stock AVM Fritz!Box 7270v3 and configure it for Dual-Stack dial it works perfectly.

    Do you have any idea if there's some misconfiguration on my end? Or is my setup not yet supported by pfsense?

    I have attached two logs.

    Thanks for helping out,

    Dark-Sider

    This is the ppp log from the box:

    
    Jul 23 17:05:15	ppp: [wan_link0] PPPoE: Connecting to ''
    Jul 23 17:05:21	ppp: PPPoE: rec'd ACNAME "ac5.muc2"
    Jul 23 17:05:21	ppp: [wan_link0] PPPoE: connection successful
    Jul 23 17:05:21	ppp: [wan_link0] Link: UP event
    Jul 23 17:05:21	ppp: [wan_link0] LCP: Up event
    Jul 23 17:05:21	ppp: [wan_link0] LCP: state change Starting --> Req-Sent
    Jul 23 17:05:21	ppp: [wan_link0] LCP: SendConfigReq #4
    Jul 23 17:05:21	ppp: [wan_link0] PROTOCOMP
    Jul 23 17:05:21	ppp: [wan_link0] MRU 1492
    Jul 23 17:05:21	ppp: [wan_link0] MAGICNUM 19d5fd12
    Jul 23 17:05:21	ppp: [wan_link0] LCP: rec'd Configure Request #1 (Req-Sent)
    Jul 23 17:05:21	ppp: [wan_link0] MRU 1492
    Jul 23 17:05:21	ppp: [wan_link0] AUTHPROTO CHAP MD5
    Jul 23 17:05:21	ppp: [wan_link0] MAGICNUM 5fc33403
    Jul 23 17:05:21	ppp: [wan_link0] LCP: SendConfigAck #1
    Jul 23 17:05:21	ppp: [wan_link0] MRU 1492
    Jul 23 17:05:21	ppp: [wan_link0] AUTHPROTO CHAP MD5
    Jul 23 17:05:21	ppp: [wan_link0] MAGICNUM 5fc33403
    Jul 23 17:05:21	ppp: [wan_link0] LCP: state change Req-Sent --> Ack-Sent
    Jul 23 17:05:21	ppp: [wan_link0] LCP: rec'd Configure Ack #4 (Ack-Sent)
    Jul 23 17:05:21	ppp: [wan_link0] PROTOCOMP
    Jul 23 17:05:21	ppp: [wan_link0] MRU 1492
    Jul 23 17:05:21	ppp: [wan_link0] MAGICNUM 19d5fd12
    Jul 23 17:05:21	ppp: [wan_link0] LCP: state change Ack-Sent --> Opened
    Jul 23 17:05:21	ppp: [wan_link0] LCP: auth: peer wants CHAP, I want nothing
    Jul 23 17:05:21	ppp: [wan_link0] LCP: LayerUp
    Jul 23 17:05:21	ppp: [wan_link0] CHAP: rec'd CHALLENGE #1 len: 29
    Jul 23 17:05:21	ppp: [wan_link0] Name: "ac5.muc2"
    Jul 23 17:05:21	ppp: [wan_link0] CHAP: Using authname "XXXXXXX@v6.mnet-online.de"
    Jul 23 17:05:21	ppp: [wan_link0] CHAP: sending RESPONSE #1 len: 49
    Jul 23 17:05:22	ppp: [wan_link0] CHAP: rec'd SUCCESS #1 len: 4
    Jul 23 17:05:22	ppp: [wan_link0] LCP: authorization successful
    Jul 23 17:05:22	ppp: [wan_link0] Link: Matched action 'bundle "wan" ""'
    Jul 23 17:05:22	ppp: [wan_link0] Link: Join bundle "wan"
    Jul 23 17:05:22	ppp: [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps
    Jul 23 17:05:22	ppp: [wan] IPCP: Open event
    Jul 23 17:05:22	ppp: [wan] IPCP: state change Initial --> Starting
    Jul 23 17:05:22	ppp: [wan] IPCP: LayerStart
    Jul 23 17:05:22	ppp: [wan] IPV6CP: Open event
    Jul 23 17:05:22	ppp: [wan] IPV6CP: state change Initial --> Starting
    Jul 23 17:05:22	ppp: [wan] IPV6CP: LayerStart
    Jul 23 17:05:22	ppp: [wan] IPCP: Up event
    Jul 23 17:05:22	ppp: [wan] IPCP: state change Starting --> Req-Sent
    Jul 23 17:05:22	ppp: [wan] IPCP: SendConfigReq #5
    Jul 23 17:05:22	ppp: [wan] IPADDR 0.0.0.0
    Jul 23 17:05:22	ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
    Jul 23 17:05:22	ppp: [wan] PRIDNS 0.0.0.0
    Jul 23 17:05:22	ppp: [wan] SECDNS 0.0.0.0
    Jul 23 17:05:22	ppp: [wan] IPV6CP: Up event
    Jul 23 17:05:22	ppp: [wan] IPV6CP: state change Starting --> Req-Sent
    Jul 23 17:05:22	ppp: [wan] IPV6CP: SendConfigReq #3
    Jul 23 17:05:22	ppp: [wan] IPCP: rec'd Configure Request #1 (Req-Sent)
    Jul 23 17:05:22	ppp: [wan] IPADDR x.x.16.28
    Jul 23 17:05:22	ppp: [wan] x.x.16.28 is OK
    Jul 23 17:05:22	ppp: [wan] IPCP: SendConfigAck #1
    Jul 23 17:05:22	ppp: [wan] IPADDR x.x.16.28
    Jul 23 17:05:22	ppp: [wan] IPCP: state change Req-Sent --> Ack-Sent
    Jul 23 17:05:22	ppp: [wan] IPCP: rec'd Configure Reject #5 (Ack-Sent)
    Jul 23 17:05:22	ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
    Jul 23 17:05:22	ppp: [wan] IPCP: SendConfigReq #6
    Jul 23 17:05:22	ppp: [wan] IPADDR 0.0.0.0
    Jul 23 17:05:22	ppp: [wan] PRIDNS 0.0.0.0
    Jul 23 17:05:22	ppp: [wan] SECDNS 0.0.0.0
    Jul 23 17:05:22	ppp: [wan] IPV6CP: rec'd Configure Request #1 (Req-Sent)
    Jul 23 17:05:22	ppp: [wan] IPV6CP: SendConfigAck #1
    Jul 23 17:05:22	ppp: [wan] IPV6CP: state change Req-Sent --> Ack-Sent
    Jul 23 17:05:22	ppp: [wan] IPV6CP: rec'd Configure Ack #3 (Ack-Sent)
    Jul 23 17:05:22	ppp: [wan] IPV6CP: state change Ack-Sent --> Opened
    Jul 23 17:05:22	ppp: [wan] IPV6CP: LayerUp
    Jul 23 17:05:22	ppp: [wan] 16fe:b5ff:feab:70f3 -> 12f3:11ff:fea3:2100
    Jul 23 17:05:23	ppp: [wan] IFACE: Up event
    Jul 23 17:05:23	ppp: [wan] IFACE: Rename interface ng0 to pppoe0
    Jul 23 17:05:23	ppp: [wan] IPCP: rec'd Configure Nak #6 (Ack-Sent)
    Jul 23 17:05:23	ppp: [wan] IPADDR x.x.188.97
    Jul 23 17:05:23	ppp: [wan] x.x.188.97 is OK
    Jul 23 17:05:23	ppp: [wan] PRIDNS 212.18.0.5
    Jul 23 17:05:23	ppp: [wan] SECDNS 212.18.3.5
    Jul 23 17:05:23	ppp: [wan] IPCP: SendConfigReq #7
    Jul 23 17:05:23	ppp: [wan] IPADDR x.x.188.97
    Jul 23 17:05:23	ppp: [wan] PRIDNS 212.18.0.5
    Jul 23 17:05:23	ppp: [wan] SECDNS 212.18.3.5
    Jul 23 17:05:23	ppp: [wan] IPCP: rec'd Configure Ack #7 (Ack-Sent)
    Jul 23 17:05:23	ppp: [wan] IPADDR x.x.188.97
    Jul 23 17:05:23	ppp: [wan] PRIDNS 212.18.0.5
    Jul 23 17:05:23	ppp: [wan] SECDNS 212.18.3.5
    Jul 23 17:05:23	ppp: [wan] IPCP: state change Ack-Sent --> Opened
    Jul 23 17:05:23	ppp: [wan] IPCP: LayerUp
    Jul 23 17:05:23	ppp: [wan] x.x.188.97 -> x.x.16.28
    
    

    System Log

    
    Jul 23 17:05:25	php: rc.newwanip: ROUTING: setting default route to x.16.28
    Jul 23 17:05:25	php: rc.newwanip: ROUTING: setting IPv6 default route to fe80::12f3:11ff:fea3:2100%em1
    Jul 23 17:05:26	php: rc.newwanip: ROUTING: setting default route to x.16.28
    Jul 23 17:05:26	php: rc.newwanip: ROUTING: setting IPv6 default route to fe80::12f3:11ff:fea3:2100%em1
    
    


  • Probably the same issue:  http://forum.pfsense.org/index.php/topic,64483.0.html
    Try the new snapshot. Things should be solved.



  • Thanks for pointing this out - I missed that topic.

    I also noticed that the radvd service is missing from my services tab. When should the radvd service start and is it needed for my configuration? Track WAN on LAN and DHCP6 on WAN?

    Is there a way to start it manually via ssh? I upgraded from 2.0.1 and kept my config (fyi)

    bye + thx,
    Darky



  • radvd won't start (or show up in the services list, even) until you actually have an IPv6 address on your LAN interface.



  • Hi,

    I'm getting closer to solve my problem but I'm not yet there. The added option "request prefix throuch IPV4 pppoe" did help a little.

    My LAN interface now gets a public ipv6 address and it also gets distributed via radvd to my lan clients. I also can ping6 the pfsense box from lan and vice versa.

    Now the strange part is, that the pppoe interface does not get a public ip. According to the support forum of my ISP they're only issunge public prefixes but not public addresses for the dial-in interfaces. So an ifconfig looks like this:

    em0 is LAN
    em1 is WAN
    pppoe is pppoe ;-)

    
    [2.1-RC0][root@pfsense.localdomain]/root(36): ifconfig
    em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:0c:29:06:29:24
            inet 10.10.254.254 netmask 0xffff0000 broadcast 10.10.255.255
            inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x1
            inet6 2001:a60:147a:9b00:20c:29ff:fe06:2924 prefixlen 64
            nd6 options=1 <performnud>media: Ethernet autoselect (1000baseT <full-duplex>)
            status: active
    em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:0c:29:e5:e6:df
            inet6 fe80::20c:29ff:fee5:e6df%em1 prefixlen 64 scopeid 0x2
            nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
            status: active
    pppoe0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1492
            inet6 fe80::20c:29ff:fe06:2924%pppoe0 prefixlen 64 scopeid 0x9
            inet 93.104.110.106 --> 82.135.16.28 netmask 0xffffffff
            nd6 options=3 <performnud,accept_rtadv></performnud,accept_rtadv></up,pointopoint,running,noarp,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast> 
    

    The default 6 route on my box is:

    
    Destination        Gateway            Flags      Netif Expire
    default            fe80::12f3:11ff:fe UGS      pppoe0
    
    

    The default route on my LAN-Clients is:

    
    If Metrik Netzwerkziel             Gateway
    17    266 ::/0                     fe80::1:1
    
    

    When I SSH into my pfsense box I can ping6 public v6 hosts w/o issue:

    
    traceroute6 to google.com (2a00:1450:4016:803::1007) from 2001:a60:147a:9b00:20c:29ff:fe06:2924, 64 hops max, 12 byte packets
     1  2001:a60::89:703:1  11.734 ms  14.806 ms  14.353 ms
     2  rt-inxs.m-online.net  81.254 ms  12.744 ms  11.999 ms
     3  2001:7f8:2c:1000:0:a501:5169:1  18.980 ms  42.625 ms  20.499 ms
     4  2001:4860::1:0:336d  20.110 ms  19.504 ms  19.866 ms
     5  2001:4860:0:1::17b  20.365 ms  20.404 ms  19.873 ms
     6  2a00:1450:8000:29::c  19.735 ms  21.699 ms  19.958 ms
    
    

    My lan clients can't reach any external v6 hosts, though they can ping fe80::1:1.

    
    C:\Users\Dark-Sider>tracert -6 google.de
    Routenverfolgung zu google.de [2a00:1450:4016:802::1017] über maximal 30 Abschnitte:
      1     *        *        *     Zeitüberschreitung der Anforderung.
      2     *        *        *     Zeitüberschreitung der Anforderung.
    
    C:\Users\Dark-Sider>ping -6 fe80::1:1
    Ping wird ausgeführt für fe80::1:1 mit 32 Bytes Daten:
    Antwort von fe80::1:1: Zeit<1ms
    Antwort von fe80::1:1: Zeit<1ms
    Antwort von fe80::1:1: Zeit<1ms
    Antwort von fe80::1:1: Zeit<1ms
    
    

    I enabled the general ipv6 support and I added a firewall rule on LAN to permit all ipv6 traffic. I also unchecked the block bogon networks on the WAN and LAN configuration pages, since the pppoe-if ip is link-local.

    Any further ideas what I might be missing?

    thx+ bye
    Darky



  • I wanted to add, that within the system log the following message keeps repeating each second or so:

    
    Jul 25 18:26:04	dhcp6c[58107]: update_ia: status code for NA-0: no addresses
    Jul 25 18:26:04	php: rc.newwanipv6: rc.newwanipv6: Failed to update wan IPv6, restarting...
    Jul 25 18:26:06	dhcp6c[58107]: update_ia: status code for NA-0: no addresses
    Jul 25 18:26:06	php: rc.newwanipv6: rc.newwanipv6: Failed to update wan IPv6, restarting...
    Jul 25 18:26:08	dhcp6c[58107]: update_ia: status code for NA-0: no addresses
    Jul 25 18:26:08	php: rc.newwanipv6: rc.newwanipv6: Failed to update wan IPv6, restarting...
    Jul 25 18:26:09	dhcp6c[58107]: update_ia: status code for NA-0: no addresses
    Jul 25 18:26:10	php: rc.newwanipv6: rc.newwanipv6: Failed to update wan IPv6, restarting...
    
    


  • Your provider probably only does prefix delegation. You won't get an IPv6 address for your external interface.
    You should also check the box labeled ' Only request a IPv6 prefix, do not request a IPv6 address'

    If you want an IPv6 address on your external interface too, you can create an IPv6 alias address.
    routing towards your provider still goes through the link-local address but you can connect to the outside interface too.

    Using an IPv6 alias combined with HAproxy you can even make your ipv4 servers reachable on an IPv6 address.



  • Hi,

    yes checking the "only request ipv6 prefix" made the repeating error go away however did not solve my other problem.

    I did some packet sniffing while trying to ping6 google.com from my LAN and at the same time pinging it from the pfsense box.

    All packets actually leave the WAN interface but there is only a reply for the pfsense packets…. The firewall does not record any drops.
    This made me look twice at the src ip-address of my LAN-Host. Since the v6 suffix does not change and my the prefix only bearly changes I didn't notice until now that my LAN-host tried to ping with an OLD ipv6 address which still showed within ipconfig... Due to several config changes pfsense redialed like 5 times and my windows box had a total of 5 different ipv6 addresses. With ping -6 -S you can specify the source address which resulted in immediate success. After rebooting the machine only the correct ipv6 address showed up again. So this probably is not a pfsense related problem but if windows does not loose those old prefixes other applications that do not allow to specify the source address (like browsers) are completely screwed.

    Any ideas on this issue?

    But I'm very happy that finally ipv6 works at our site!

    bye,
    Darky



  • I did some researching. Apperently pfsense announces the ipv6 addresses with 4 hours of preferred validity.

    When the WAN interface gets resetted, there should be an announcement that the address is no longer valid, otherwise the problem from my last post occurs when your public prefix changes. However there is a catch. Windows has a "bug" that doesnt allow invalidated prefixes to become back active (as long as you don't reboot or reactivate your network card).

    The questions are
    -Does pfsense remember the old prefixes and does it send an invalid announce after the WAN connection has gone down?
    -Does this happen when the checkboxes for request ipv6 thru ipv4 pppoe and request only prefix are checked?
    -Does this only happen when the connection dies because of external influence or this also happen when the connection is reset because e.g. the WAN-if is reconfigured.
    Why is the validity so extraordinary long. 4 hours seems a lot. 1 or 10 minutes seem more reasonable to me if you figure in that the timer gets reset to 4 hours every ten seconds…. Is this value configurable?

    bye + thx,
    Darky