6to4 support added

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…