6to4 support added

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!

databeestje

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.

epek

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.

databeestje

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.

epek

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…