6to4 support added

Cino

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?

databeestje

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.

epek

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.

databeestje

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.

epek

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.

databeestje

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>

epek

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 :-)

epek

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?!

databeestje

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

epek

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.

databeestje

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.

epek

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.

databeestje

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

epek

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

databeestje

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.

databeestje

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

epek

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.

databeestje

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.

databeestje

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

epek

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!