6to4 support added



  • 6to4 support for the WAN has been added.

    When selecting that you need to set the LAN interface to "track" the WAN interface.

    That will automatically setup RA on the LAN for your IPv6 prefix based on your IPv4 WAN address.

    This will work the same for DHCP6 and 6rd.



  • great work!! Wish I could test this out but I can only use a tunnel right now.. Quick question, I've noticed you made a ton of changes over the weekend… For most of these changes to work and not deadline my box; I believe a firmware update is needed?



  • just php changes, it's safe.

    6to4 is actually a tunnel, but slightly different from a conventional he.net tunnel in that the supplied IPv6 prefix is calculated from the IPv4 external address.



  • I am unsure how to use 6to4 on pfsense - on debian it was quite simple to do.

    Could it be that pfsense´s 6to4 mechanism will only work for a "static" WAN IP?

    According to your short description it will be sufficient to add the ipv6 type "6to4" on the wan interface in order to connect the tunnel (to the 192.88.99.1 multicast address of the 6to4 mechanism.)

    So we should see the ipv6 address on the wan interface statistic/interfaces info pages. Am I wrong?

    In my case the configuration method for WAN is PPPoE.
    Simply activating 6to4 does not bring up the tunnel in that case.

    I tried workarounds with a gif tunnel, but using the above multicast address or rather it's variant ::192.88.99.1 as an endpoint and tying the gif to a OPT-Interface will not work as expected.



  • I've tried it on a static WAN but it should work on others as well.

    Select IPv6 configuration type "6to4" on the WAN.
    Select IPv6 configuration type "Track interface" on the LAN.
    Select the WAN interface here and a number instead of "none"

    It will then automatically configure the LAN interface and activate RA messages.

    If it doesn't it's a bug and I need to fix it.



  • On the WAN I have selected "IPv4 Connection type" "PPPoE" and "IPv6 configuration type" "6to4".
    On the LAN settings page I do not see a IPv6 configuration type "Track interface".
    (I have more LANs than one because of VLANs - but I did not see it on either config page anyways).
    I only can offer: "None", "Static IPv6", "DCHP6", "6rd" and "6to4".
    I am on 2.1DEVELOPMENT with updates from today yesterday morning (~2:00 CEST).
    The latest update dated after your announcement is currently pending installation.
    A Gif-Tunnel for HE Tunnelbroker is also present, but that should not interfere with your setup, should it?

    Edit: The very latest update, which showed up three hours ago, just finished the recent upgrading process.
    I can now see what you described. Thank you - I will report back, in the case it does not work.

    Update: I have done exactly, what you proposed, but the WAN interface itself only has a link local ipv6 address, no 6to4-address shows up on status/interfaces.

    LAN… I also tried a separate VLAN, which was IPv6-only (Track interface). It neither received an ipv6 address.
    It is still possible that I misconfigured sth. essential, but I have set permissive rules and even toggled the RFC2893 settings.



  • the 6to4 address will not show on the wan interface, only on stf0. So ifconfig stf0 on the command page should show if it's configured.

    The interface configured as track should automatically configure itself with <prefix>::1 and setup RA. And yeah a VLAN would be fine for that. That configured LAN interface should show up in the WebUI though.

    Which reminds, that means it's easy for me to test at home too. Thanks.

    I'm sure there might be a issue why it's not automatically configuring the prefix, i'll do more testing too.</prefix>



  • Hello!

    I continued testing - the system updated to latest version about an hour ago.
    Again: I have WAN on ipv4/PPPoE and ipv6/6to4; The vlan-interface "ipv6helper" is ipv4/none and ipv6/Track interface.

    On the shell:
    ifconfig stf0
    ifconfig: interface stf0 does not exist.

    I can see in Status/Gateways:
    WAN_v6 fe80::[..cut..] Gathering data Gathering data Gathering data Interface WAN Dynamic Gateway

    I then tried to repeat the steps for creating an stf0 on the shell according to http://www.netbsd.org/docs/guide/en/chap-net-practice.html#chap-net-practice-ipv6-6to4-get-running

    To my surprise these steps for ifconfig stf0 inet6 2002:[…]::1 … returned:
    ifconfig: ioctl (SIOCAIFADDR): File exists

    2002:[…]::1 was already configured on the vlan/track interface (configured for WAN).

    I then reconfigured all interfaces to ipv6 and started all over… result:

    stf0 does not get created in the first place, while the "tracking interface" is well set up.

    I hope I could shorten your debugging adventures a litte :-)



  • Another thing:

    After a reboot I see error messages regarding:

    from /tmp/debug.rules

    allow our proto 41 traffic from the 6RD border relay in

    pass in on $WAN proto 41 from 192.88.99.1 to [..myip..] label "Allow 6in4 traffic in for 6rd on WAN"
    pass out on $WAN proto 41 from [..myip..] to 192.88.99.1 label "Allow 6in4 traffic out for 6rd on WAN"

    dunno?!



  • I renamed the 6rd lines to read 6to4 later so that encapsulated traffic is always allowed in and out to the 6to4 anycast relay



  • But the rules from around line 150/154 in my case from /etc/inc/filter.inc do not get loaded, because of a syntax problem.
    Isn't there some "inet" or "ipv4" missing? Should it "pass" or "allow". I'm new to ipfw2. I am not sure on the implications of that rules concerning he.net-Tunnels. Afaik they too use 6in4, not gre, but on another anycast relay - so the rules here may be to restrictive to allow for both methods. Probably I am talking absolute nonsense - i'll have to some more reading again to be sure.

    BtW: Using the 6to4 mechanism on a different interface, which is part of a static ipv4 routed subnet, does work fine.
    It seems, that the 6to4 script in network.subr is invoked before the pppoe interface get's up. It seems logical that by that time it does not have an ipv4 address to be set up upon, while the vlan interface which tracks the pppoe interface by then receives the according ip, but not from stf configuration data, but from an ip6 calculation. Just guessed, from the few things a learned about pfsense and BSD the last few days.



  • yeah, that sounds about right. i did add code to rc.newwanip to reconfigure a dependent track interface. but that should also configure the stf interface really.

    maybe a dhcp client would be faster over pppoe and not show the issue.



  • Hello again!

    Thanks for your improvements - I appreciate your work! I just updated to the latest build.

    Still I notice some issues:

    First - WAN/pppoe/6to4 still does not work after a reboot. (What: The helper vlan is not configured to use the 6to4 address of the wan interface).

    Second - changing from another tracking interface eg 'external' for a routed ipv4 subnet back to wan does not update the interface configuration at runtime. (stf0 information does not get updated)

    Third - 6to4 on a static ipv4 interface works very well.

    Fourth: Filter error messages regarding 6in4 persist with IP any (0.0.0.0):
    "[filter_load]There were error(s) loading the rules: /tmp/rules.debug:156: syntax error/tmp/rules.debug:157: syntax errorpfctl: Syntax error in config file: pf rules not loaded - The line in question reads [156]: pass in on $WAN proto 41 from 192.88.99.1 to  label Allow 6in4 traffic in for 6to4 on WAN.
    On startup pfsense tries to load these rules regardless of the RFC2893 checkbox or the destination address:

    Unchecked: -> pass in on $WAN proto 41 from 192.88.99.1 to  label Allow 6in4 traffic in for 6to4 on WAN
    Checked, 0.0.0.0 -> pass in on $WAN proto 41 from 192.88.99.1 to  label Allow 6in4 traffic in for 6to4 on WAN
    Checked, myIP -> pass in on $WAN proto 41 from 192.88.99.1 to [myIP] label Allow 6in4 traffic in for 6to4 on WAN
    Either way, I receive an error message: "[filter_load]There were error(s) loading the rules:…"

    The He.net-Tunnel on the other hand is up and the endpoint is pingable. Too,

    Fifth: Filter error messages regarding 6in4 persist with IP any (0.0.0.0); I have yet to test, wheter data transmission are possible, but at first sight, it obviously fails, while the he-tunnel works fine for some reason.

    Sixth: Question: Just in case, you have multiple IPv4 addresses on which you would like to use the 6to4 mechanism (there shouldn't be a real need for that in most cases), tracking can be set accordingly, but what about the protocol 41 filter rules for multiple addresses?
    Wouldn't it be better to make protocol 41 available for direct selection within the interface filters involved instead of using System/Advanced/Networking/ for only one IP? This would be more flexible and allow for multiple tunneling methods (6to4, 6in4).
    Furthermore RFC2893 has been obsoleted by RFC4213.

    I apologize for not going into details - I lack the time to do more right now.



  • Fix checked in for the broken firewall rules. And another fix for rc.newwanip that should trigger the configure.



  • Hello again!

    Today I did a reset to factory defaults after upgrading and started all over again to be sure nothing interferes.

    I have wan on pppoe/6to4.
    IPV6WAN is /Track interface(WAN) with prefix 1.

    After a reboot this is the state we are in:

    IPV6WAN is configured on [6to4addr]:1::1/64 (ok).

    Ping6 for six.heise.de:
    ping6: UDP connect: No route to host

    $ ifconfig stf0
    ifconfig: interface stf0 does not exist

    Manually creating and setting up stf0 works well now. (No address conflict on [6to4]::1).
    After manually setting the defaultroute to the anycast ipv6 equivalent, the v6 connection is up.

    I still guess stf get's configured too early. At that time WAN does not have an ipv4 address yet.
    The code block for stf creation is depending on an ipv4 address, so it's left out.

    The address of the helper tracking WAN is calculated later from WAN, not stf.
    We should take over stf0's, not wan's config information IMHO. That way we can be sure, ipv6 is up by the time we configure it.
    On the other hand, the helper will not be semi-statically (tracking) configured - but if you what it to be statically configured, you can always set it up that way manually.

    Regards
    Epek



  • I'll look through the intial configure code path to see if I'm missing something, in general the IPv6 code is processed after the IPv4 configure part.

    But what likely happens is that the PPPoE isn't up when it does a

    interface_6to4_configure("wan");
    

    You can attempt to execute this on the command prompt, that should bring up the stf0 interface.

    I added this command to the /etc/rc.newwanip script, which is executed when the IPv4 address is aquired. This should also have configured the 6to4 interface.

    I'll read the code again if I'm using the right variables, it was late and i was tired.



  • Yeah, so my hunch was right, i fixed the rc.newwanip, it should now succesfully configure the stf whenever the wan ip refreshes.

    https://github.com/bsdperimeter/pfsense/commit/c1a104c7c8cc61d103fe6eba8dd98a071074b4ec



  • 2.1-DEVELOPMENT (amd64)
    built on Thu Apr 5 12:15:36 EDT 2012
    FreeBSD 8.3-RC2

    I can confirm, that interface_6to4_configure("wan"); on php execute does configure the interface correctly at a first glance, but does not set the 6to4 default route.

    I guess your changes are not yet integrated in the build states above (stf0 remains unconfigured after reboot in version installed).

    Thanks for your fast replies and help!

    Regards
    Epek

    Happy Easter, don't forget to integrate some easter eggs in pfsense ;-)

    Update:
    pfctl syntax error:

    pass out route-to ( pppoe0 2002:c058:6301::1 ) inet6 from 2002:[…]:: to !/
    keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to ( em0_vlan4010 2002:c058:6301::1 ) inet6 from 2002:[…]::
    to !/ keep state allow-opts label "let out anything from firewall host itself"

    Other strangeness:
    If you happen to configure 2 6to4 addresses, the second 6to4  interface shows the ipv6 prefix of wan, not it´s own. The corresponding tracking interface does show the correct value.



  • You can't configure more then one 6to4 prefix, the adapter does not support it. So the last configure attempt will stick.

    Aagh, the route-to again, I'll investigate. I thought I fixed that rule for various types already but must have missed something.

    I'll add a ticket to add input validation. You can not configured more then 1 interface for either 6to4 or 6rd, since they both use stf.



  • that fix was already in the tree but it looks like the snapshots server stalled, the last files are from the 5th.



  • Hello again!

    Thanks for checking!

    I'd like to discuss the sense and nonsense of multiple tunnels with you - if you think it is worth the time and efforts:

    First I agree, that multiple tunnels are nonsense im most cases.
    But in cases, where multiple machines get migrated, which previously used their 'own' 6to4 addresses and now shall be protected be pfsense (e.g. in a Hotlan DMZ), it seems to be a reasonable request. As a professional solution pfsense should respect that aspect.
    Reading gif and stf man pages, it seems that only one 6to4 tunnel is to be used /per interface/. So pfsense should only cut down the use of more tunnels per interface. Probably aliases could be used to work around this problem, but I am not yet familiar with that concept.

    Second there are most probably routing problems with the semi-automatic rule generation in pfsense (the one that's broken right now ;-). (Multiple Ipv6 Gateways, which cannot not to be deleted from within the WebGUI). (In my latest test I noticed, that even my ipv4 connection was affected when using two 6to4 setups. The effect vanished on deactivation of the second 6to4 interface.)
    I plea for letting the user decide what he does or does not want to use. I understand, that this will increase problems in the "first-contact situations" and will increase the danger of users turning their back on pfsense. On the other hand, understanding of the mechanisms is vital to configuring an own firewall or IDS system. So rather than using automatisms I regard it to be most important to give the user the tools to do what he needs (or believes he needs) to do.

    As a result of the above, I IMHO would prefer if:

    • Pfsense would provide stf0, stf1, … interface configuration through the WebGUI on a tab similiar to the GIF tunnel setup with a reference to the underlying interface. (That way you can even clean up some things and it would integrate IMO more seamlessly into the existing concepts.)
    • Automatic rule generation on the underlying interface is quite useful, but probably the user should decide on his own, if he wants to use them or probably needs to change it. (I plea for a more complete list of ip protocols on the configuration pages - depending on the protocol version selected above - e.g. I see noc reason for proto 41 to be missing in the list in ipv4, while I regard it to be useless while ipv6 is selected.).

    Furthermore i would prefer to replace the prefix selection dropdown combo on the tracking interface configuration page with a pure text field - the list generation seems to be quite slow sometimes and most important in configuring the first time you can currently select only "none" or "0". (Firefox). (you could use up to four combos from 0-f as well... but that isn't the clue, IMO.

    I am looking forward to reading your comments on this. Thanks for listening.

    Regards
    Epek

    Update: Why am I talking? http://redmine.pfsense.org/issues/2352 Thanks again!



  • You seem to be misunderstanding here, the stf interface in FreeBSD does not support more then 1 scope, I do understand your concern, but it won't be fixed before 2.2. For 2.1, it's a 1 interface limitation.

    It's not that we are not willing to build it, we just can't at this point in time.

    With regards to regular 6in4 tunnels (gif), you can have multiple of those and multiwan with those too.
    http://doc.pfsense.org/index.php/Multi-WAN_for_IPv6

    We support NPt for IPv6 networks, so you could remap some of those connections to secondary connections.
    We don't have any automatic mapping currently, only static mappings. That's something for 2.2 as well.

    Do note, that if you wish to use multiple tunnels on multiple interfaces you need to add static routes for the border relays. And because 6to4 always uses the same well know 192.98.99.1 anycast address it's impossible to do. The proto41 traffic can only go out 1 interface. That's a hard limitation.

    And no, dynamic/automatic interfaces can not be deleted from the UI, ignore them if you don't want to see them. But you need those for things like gateway groups.

    For something like a combination like 6rd and 6to4 on 2 different interfaces, that is theoretically possible. But not supported at this time, see limitations in the FreeBSD stf adapter.

    The automatic rule generation is intentional since this is intended as a complete automatic solution. You are always free to edit rules.

    As soon as you've saved the track interface once you can select the network you want from the dropdown. It does generate all the possibilities. We might be able to add a piece of JS for that in the future.

    And no, i don't want to make that a free text field.



  • Thanks for explaining.

    Ok. I just got fooled because ifconfig stf1 create worked and the manual did not say "per interface" directly, but said:
    "Single (no more than 1) valid 6to4 address needs to be configured to the interface." A read this as "no more than one per interface".
    I have to think it over to fully understand the concept.

    In regard to the prefix selection: the combo lags.

    Regards
    E.



  • The combo lags indeed, I've noticed :-)

    We'll have to make it faster then ;-)

    The reason for the drop down is obvious, not everybody can craft a hex adres or even know what one is. Hence the drop down, and if it is slow we can probably fix this. It's probably calling dechex() what's being slow.

    Something a printf() could fix.



  • Ok, thanks again.

    Regarding gif interfaces. I now figured out how to do 6to4 using gif instead of stf0/stf1.
    I am unsure wheter the /48 prefix instead of /16 will increase the latency. I still have to figure out how to circumvent this.

    I followed http://ipv6int.net/systems/freebsd-ipv6.html and configured pfsense using the webinterface accordingly.

    interfaces/assign/gif/"+".
    wan/gif remote address: 192.88.99.1
    gif tunnel local address: 2002:[myipv4address]::
    gif tunnel remote address: 2002:c058:6301::/128
    save.
    Then I created an opt interface, assigned gif 192.88.99.1 and configured ipv6 only with an address of gif tunnel local address: 2002:[myipv4address]::1/48

    Following the same method for the other interface, while the first is using a default gateway of ::192.88.99.1 and the other just a gateway of ::192.88.99.1 did the trick.

    I am still investigating…


Log in to reply