IPv6 on PPTP (and possibly PPPoE) WAN



  • Question from a pfSense newbie, hope this is the correct place.

    I recently switched my firewall from openwrt to pfsense 2.2-BETA1.
    Almost everything works, except for ipv6 :(

    my ISP (xs4all.nl) provides native IPv6 on their DSL offers using DHCP6 IA-PD.

    After some investigation it looks to me that this was broken in revision 65101877 (on github).
    The supplied ISC dhclient does not support PPP interfaces and it may take some time to get supported.

    From my logfiles it looks like this dhclient is not even started as I have log entries about dhcp6c.
    Starting dhcp6c fails because the .conf file generated is for ISC dhclient and thus has a different format.

    Dec 17 14:21:43 nono dhcp6c[44877]: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
    Dec 17 14:21:43 nono dhcp6c[44877]: client6_init: failed initialize control message authentication
    Dec 17 14:21:43 nono dhcp6c[44877]: client6_init: skip opening control port
    Dec 17 14:21:43 nono dhcp6c[44877]: yyerror0: /var/etc/dhcp6c_wan.conf 1: syntax error
    Dec 17 14:21:43 nono dhcp6c[44877]: yyerror0: /var/etc/dhcp6c_wan.conf 1: fatal parse failure: exiting (1 errors)
    Dec 17 14:21:43 nono dhcp6c[44877]: main: failed to parse configuration file

    What is going on here and how to fix it.

    mod: dhcp6c is using the .conf generated for ISC dhclient



  • bump

    I can confirm it doesn't work with PPPoE too.

    Dec 22 15:41:48 nono dhclient6: PREINIT6
    Dec 22 15:41:48 nono dhclient6: Starting delete_old_states()
    Dec 22 15:41:48 nono dhclient: Bound to *:546
    Dec 22 15:41:48 nono dhclient: Unsupported device type 53 for "pppoe0"

    should this isc dhclient stuff (in rev 65101877) be reverted or what is the way forward?


  • Rebel Alliance Developer Netgate

    databeestje talked about reverting the client changes when he gets some time to do so.

    Basically the problem is the old client is broken in some ways, and this one is broken in others. There does not appear to be a single client that will work for both scenarios, and I don't think there is a way to make them coexist peacefully either.



  • I'm also using XS4ALL.

    I'm still using the old client, currently I'm on the snapshot from Sept 14.
    I made a work around. It's a little bit of a hassle but it will give DHCP-PD support.

    The wan interface is set to DHCP6 client but I also created an IPv6 virtual IP address on it.
    The internal interface (LAN, multiple DMZ's) are setup to follow the external interface.

    When the firewall is booted, the DHCP process on pppoe failes and also to internal interfaces do not receive their IPv6 address.
    Then, after the boot, the WAN interface is re-initialized by applying and saving the config again.
    All internal interfaces will then receive an IPv6 address. The WAN interface will still not receive an IPv6 address from the DHCP server but it has the virtual one which is fully functional.

    the only drawback from this workaround is that after a reboot the external interface has to be re-initialized by hand. But that's a small sacrifice compared to full IPv6 on all interfaces.

    Andre



  • I've contacted databeestje directly and he told me this too.

    I partially undid his patch (mentioned in TS) and also changed rc.newwanipv6 a little.
    Manually starting rc.interfaces_wan_configure works for me, except for radvd starting automatically.
    After starting radvd service manually my ipv6 is up and running.

    Still searching for the right place to post the patches.



  • I've attached my patches.

    The patch to /etc/rc.newwanipv6 makes it more like /etc/rc.newwanip.
    The patch to /etc/inc/interfaces.inc mostly reverts IPv6 changes databeestje did and also changes the dhcp6cscript to use real WAN interfacename instead of wan, again matching it's IPv4 counterpart.

    These patches worked for about a week. Now dhcpv6 packets get dropped on bogon rule. XS4all uses unnumbered (ie link-local) WAN which is dropped on 8000::/1 bogon address :(

    Please feel free to include patches into pfSense.

    rc.newwanipv6-p1.txt
    interfaces-p1.txt



  • Thank you for the patches Eppo, I just reverted my patch with git revert and applied yours to the git tree.

    I'll see if I can setup a PPPoE server that has IPv6. pfSense does not support ipv6 on the pppoe server side yet, which makes testing a bit harder. I might need to fire up the cisco 1811 if I can remember what it was configured like.

    It's not just PPPoE where it can boot without the IPv6 coming up on cold boot. That's been a long standing issues with the other WIDE dhcp6 client. I guess we'll just have to debug why it doesn't work on boot.



  • Good to hear this.

    I don't mind to save the pain of IOS ;) by volunteering my connection for testing.
    Please contact me directly and we'll make it work.



  • If it would help, I could make a virtual pfSense available that is connected to a ipv4 cable connection and a ipv4/ipv6 adsl. Let me know if you can use it.

    I also had the same problem with out Routit line.
    http://forum.pfsense.org/index.php/topic,55307.0.html

    I had not received a message about the new post in my topic but found this topic through the Redmine activity page :P I'll test the changes asap.



  • @joolee: databeestje has replied to your post…

    I've installed Jan  7 12:06:32 EST 2013 and immediately ran into a bug, causing a crash (report send).
    Change 04aac151 introduced this. There is either a { to much on line 89 or a } to little on line 91.

    After deleting the { on line 89 all started working, except for one interface that did not get an IPv6 address assigned.
    Before (wiith my patches) it worked on that interface too.

    I've looked at rc.newwanipv6 a few times, reconfigured this interface, etc. Nothing helps. What is going one here?



  • I'm also still having problems with my setup. Connecting a Windows PC gives stable IPv6 access after connecting with PPPoE but something goes wrong with IPv6 connectivity when pfSense dials the PPPoE connection. IPv4 connectivity works fine.

    This error shows up in the syslog:

    php: : The command 'route change -host -inet6 2001:4860:4860::8844 fe80::6600:f1ff:fee8:8000' returned exit code '1', the output was 'route: writing to routing socket: No such process route: writing to routing socket: Network is unreachable change host 2001:4860:4860::8844: gateway fe80::6600:f1ff:fee8:8000: Network is unreachable'
    

    This seems to be going wrong when adding static routes for Google's IPv6 DNS Servers

    PPP Log:

    Mar 17 16:11:53: ppp: [opt2] ***.***.146.234 -> ***.***.121.133
    Mar 17 16:11:53: ppp: [opt2] IPCP: LayerUp
    Mar 17 16:11:53: ppp: [opt2] IPCP: state change Ack-Sent --> Opened
    Mar 17 16:11:53: ppp: [opt2] SECDNS 213.144.235.2
    Mar 17 16:11:53: ppp: [opt2] PRIDNS 213.144.235.1
    Mar 17 16:11:53: ppp: [opt2] IPADDR ***.***.146.234
    Mar 17 16:11:53: ppp: [opt2] IPCP: rec'd Configure Ack #3 (Ack-Sent)
    Mar 17 16:11:53: ppp: [opt2] SECDNS 213.144.235.2
    Mar 17 16:11:53: ppp: [opt2] PRIDNS 213.144.235.1
    Mar 17 16:11:53: ppp: [opt2] IPADDR ***.***.146.234
    Mar 17 16:11:53: ppp: [opt2] IPCP: SendConfigReq #3
    Mar 17 16:11:53: ppp: [opt2] SECDNS 213.144.235.2
    Mar 17 16:11:53: ppp: [opt2] PRIDNS 213.144.235.1
    Mar 17 16:11:53: ppp: [opt2] ***.***.146.234 is OK
    Mar 17 16:11:53: ppp: [opt2] IPADDR ***.***.146.234
    Mar 17 16:11:53: ppp: [opt2] IPCP: rec'd Configure Nak #2 (Ack-Sent)
    Mar 17 16:11:53: ppp: [opt2] IFACE: Rename interface ng0 to pppoe0
    Mar 17 16:11:53: ppp: [opt2] IFACE: Up event
    Mar 17 16:11:52: ppp: [opt2] 0217:****:fe0d:4afe -> 6600:f1ff:fee8:8000
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: LayerUp
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: state change Ack-Sent --> Opened
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
    Mar 17 16:11:52: ppp: [opt2] SECDNS 0.0.0.0
    Mar 17 16:11:52: ppp: [opt2] PRIDNS 0.0.0.0
    Mar 17 16:11:52: ppp: [opt2] IPADDR 0.0.0.0
    Mar 17 16:11:52: ppp: [opt2] IPCP: SendConfigReq #2
    Mar 17 16:11:52: ppp: [opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
    Mar 17 16:11:52: ppp: [opt2] IPCP: rec'd Configure Reject #1 (Ack-Sent)
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: state change Req-Sent --> Ack-Sent
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: SendConfigAck #1
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: rec'd Configure Request #1 (Req-Sent)
    Mar 17 16:11:52: ppp: [opt2] IPCP: state change Req-Sent --> Ack-Sent
    Mar 17 16:11:52: ppp: [opt2] IPADDR ***.***.121.133
    Mar 17 16:11:52: ppp: [opt2] IPCP: SendConfigAck #1
    Mar 17 16:11:52: ppp: [opt2] ***.***.121.133 is OK
    Mar 17 16:11:52: ppp: [opt2] IPADDR ***.***.121.133
    Mar 17 16:11:52: ppp: [opt2] IPCP: rec'd Configure Request #1 (Req-Sent)
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: SendConfigReq #1
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: state change Starting --> Req-Sent
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: Up event
    Mar 17 16:11:52: ppp: [opt2] SECDNS 0.0.0.0
    Mar 17 16:11:52: ppp: [opt2] PRIDNS 0.0.0.0
    Mar 17 16:11:52: ppp: [opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
    Mar 17 16:11:52: ppp: [opt2] IPADDR 0.0.0.0
    Mar 17 16:11:52: ppp: [opt2] IPCP: SendConfigReq #1
    Mar 17 16:11:52: ppp: [opt2] IPCP: state change Starting --> Req-Sent
    Mar 17 16:11:52: ppp: [opt2] IPCP: Up event
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: LayerStart
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: state change Initial --> Starting
    Mar 17 16:11:52: ppp: [opt2] IPV6CP: Open event
    Mar 17 16:11:52: ppp: [opt2] IPCP: LayerStart
    Mar 17 16:11:52: ppp: [opt2] IPCP: state change Initial --> Starting
    Mar 17 16:11:52: ppp: [opt2] IPCP: Open event
    Mar 17 16:11:52: ppp: [opt2] Bundle: Status update: up 1 link, total bandwidth 64000 bps
    Mar 17 16:11:52: ppp: [opt2_link0] Link: Join bundle "opt2"
    Mar 17 16:11:52: ppp: [opt2_link0] Link: Matched action 'bundle "opt2" ""'
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: authorization successful
    Mar 17 16:11:52: ppp: [opt2_link0] PAP: rec'd ACK #1 len: 5
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: LayerUp
    Mar 17 16:11:52: ppp: [opt2_link0] PAP: sending REQUEST #1 len: 29
    Mar 17 16:11:52: ppp: [opt2_link0] PAP: using authname "*********"
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: auth: peer wants PAP, I want nothing
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: state change Ack-Sent --> Opened
    Mar 17 16:11:52: ppp: [opt2_link0] MAGICNUM 06abd56b
    Mar 17 16:11:52: ppp: [opt2_link0] MRU 1492
    Mar 17 16:11:52: ppp: [opt2_link0] PROTOCOMP
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: rec'd Configure Ack #1 (Ack-Sent)
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: state change Req-Sent --> Ack-Sent
    Mar 17 16:11:52: ppp: [opt2_link0] MAGICNUM 00a9634d
    Mar 17 16:11:52: ppp: [opt2_link0] AUTHPROTO PAP
    Mar 17 16:11:52: ppp: [opt2_link0] MRU 1492
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: SendConfigAck #1
    Mar 17 16:11:52: ppp: [opt2_link0] MAGICNUM 00a9634d
    Mar 17 16:11:52: ppp: [opt2_link0] AUTHPROTO PAP
    Mar 17 16:11:52: ppp: [opt2_link0] MRU 1492
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: rec'd Configure Request #1 (Req-Sent)
    Mar 17 16:11:52: ppp: [opt2_link0] MAGICNUM 06abd56b
    Mar 17 16:11:52: ppp: [opt2_link0] MRU 1492
    Mar 17 16:11:52: ppp: [opt2_link0] PROTOCOMP
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: SendConfigReq #1
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: state change Starting --> Req-Sent
    Mar 17 16:11:52: ppp: [opt2_link0] LCP: Up event
    Mar 17 16:11:52: ppp: [opt2_link0] Link: UP event
    Mar 17 16:11:52: ppp: [opt2_link0] PPPoE: connection successful
    Mar 17 16:11:52: ppp: PPPoE: rec'd ACNAME "bsr01.dcn2"
    Mar 17 16:11:46: ppp: [opt2_link0] PPPoE: Connecting to ''
    Mar 17 16:11:45: ppp: [opt2_link0] LCP: LayerStart
    Mar 17 16:11:45: ppp: [opt2_link0] LCP: state change Initial --> Starting
    Mar 17 16:11:45: ppp: [opt2_link0] LCP: Open event
    Mar 17 16:11:45: ppp: [opt2_link0] Link: OPEN event
    Mar 17 16:11:45: ppp: [opt2] Bundle: Interface ng0 created
    Mar 17 16:11:45: ppp: web: web is not running
    Mar 17 16:11:45: ppp: process 10865 started, version 5.6 (root@snapshots-8_3-i386.builders.pfsense.org 08:31 7-Mar-2013)
    Mar 17 16:11:45: ppp: 
    Mar 17 16:11:45: ppp: Multi-link PPP daemon for FreeBSD
    

    The IPv6 gateway 6600:f1ff:fee8:8000 is the same one that is assigned to a Windows client. The Windows client can ping the address but pfSense cannot.
    Just to be clear, I have updated to the latest 2.1 snapshot just now.



  • Is it even possible in pfSense to have a link-local address as default gateway? When I try to ping my gateway from pfSense, I get the following output:

    PING6(56=40+8+8 bytes) 2a02:****:****:19:217:a4ff:fe0d:4afe --> fe80::6600:f1ff:fee8:8000
    ping6: wrote fe80::6600:f1ff:fee8:8000 16 chars, ret=-1
    ping6: wrote fe80::6600:f1ff:fee8:8000 16 chars, ret=-1
    ping6: wrote fe80::6600:f1ff:fee8:8000 16 chars, ret=-1
    
    --- fe80::6600:f1ff:fee8:8000 ping6 statistics ---
    3 packets transmitted, 0 packets received, 100.0% packet loss
    ```It seems that the system is trying to ping the LL address with the public address of the interface as source instead of the LL address.
    
    I notice when looking at the routing table that there is a ipv6 route that I don't know. It is linked to the parent interface of the pppoe connection.
    The subnet is: fdd3:a5b4:***/64 and the local address (linked to lo) is fdd3:a5b4:*****:1:2e0:****:fe5c:1a4\. I had a Sixxs subnet routed on this installation once but there is not trace of that left in the config file.

  • Rebel Alliance Developer Netgate

    Link-local is valid as a gateway, and preferred in automated configuration cases.

    If you have that in your routing table, it must be coming from somewhere in the config, unless you haven't rebooted since it was removed before.



  • @jimp:

    Link-local is valid as a gateway, and preferred in automated configuration cases.

    If you have that in your routing table, it must be coming from somewhere in the config, unless you haven't rebooted since it was removed before.

    I've put a copy of my config online on http://downloads.joolee.nl/config-firewall.vsl.domain.local-20130328110745.xml

    The only remnant of the Sixxs config is a dhcpdv6 entry on the LAN interface. I can't remove this without adding a static ip to the interface but I don't think it should be a problem. I've also installed numerous updates to pfSense 2.1 Beta since removing all Sixxs config data so it has been rebooted a lot of times.

    I'll try finding another unused PC to install a fresh copy of pfsense.


Locked