IPv6_IPSEC + IPv4_with_IPv6phase2tunnels_IPSec status and does it work ?

mrzaz

Hello,

I have an IPv4 IPSec tunnel setup to another 2.1 pfSense router working OK.

Both routers also have IPv6 from TUNNELBROKER.NET setup working OK.

Q1: Is it possible to route IPv6 traffic through the IPv4 tunnel or do I need to setup a separate IPv6 phase1 to be able to route the traffic ?

Q2: I have also tested to setup a pure IPv6 IPSec phase1 + 2 but have problem with that as well. What is the status on that ?
(Firewall settings is setup OK)

I get nothing in the IPSec log when I try to activate either IPv6 in IPv4phase1 tunnel OR IPv6 in IPv6phase1 tunnel but the status page shows "error" on both sides.

Builds:
"2.1-BETA1 (i386) built on Wed Jan 16 04:16:11 EST 2013 " on my machine
"2.1-BETA1 (i386) built on Fri Dec 28 20:54:16 EST 2012" on the other (not my machine).

//Dan Lundqvist

UPDATE 2013-01-16:
I got it to work with the ALL_IPv6 tunnel but stumbled on the following reported bug:
http://redmine.pfsense.org/issues/2746

I could see that as long as the session was NOT up it was shown in the Overview but as soon
as the link got up it was gone. However, the entries in the SAD page showed OK and also showed trafic flowing.
Also confirming by testing ping over the tunnel to IPv6 enabled equipment "on the other side" working OK. :-)

UPDATE 2013-01-17:
I need to change my previous statement. It is all over the place in the Overview page with IPv6 entries.
Even if the link is up and working I have seen several symptoms.

Link is up in SAD but no entry at all in Overview.
Link is up in SAD, entry is shown but in state DOWN. And nothing happens when I press "start". Shows as X = Error.

jimp

FYI- As far as I'm aware, you can't mix address families over IPsec. So it would need to be purely IPv4 or purely IPv6.

OpenVPN does not have this limit, you can carry either kind of traffic inside the tunnel no matter which kind of external address the VPN terminates upon.

mrzaz

Hello jimp,

Thanks for the reply…

If this is the case, then why is it possible to select IPv6 in phase2 when phase1 is defined as IPv4 ?
It could be good to include some logic to prevent this before 2.1 final.

In Phase1 you define "Internet Protocol" to either IPv4 or IPv6 and then define IPv4 or IPv6 endpoint IPs.
In Phase2 you define "Tunnel IPv4" or "Tunnel IPv6" (or Transport, but I leave that one out for now).
If it doesn't work to do "Tunnel IPv6" in an Phase1 IPv4 bearer (or vice versa) it should be removed
from the selectable dropdown-list.

Am I wrong or do you agree to my statement or do you have
any other issues to why it could/should not be included ?

Best regards
Dan Lundqvist
Sockholm Sweden.

jimp

We just haven't gotten around to fixing the input validation. It is a beta after all.

Also, I don't think it's been fixed upstream, but there is a new version of ipsec-tools we haven't upgraded to yet because it requires a newer version of OpenSSL. So it would be best to wait until after that happens to remove the options, in case it does work then.

mrzaz

I fully understand that it is beta and work in progress.
That's why I wrote "before 2.1 Final".

Could you at least log it on the to do list?

/Dan

jimp

I could swear there was already a ticket for that, but I don't see it now. If I don't find one later I'll add one.

mrzaz

Hi Jimp,
Checked the latest 2.1-BETA1 (i386) built on Wed Jan 30 04:20:11 EST 2013 release and the problem
with Dashboard and IpSec Overview status of IPv6 tunnels that shows as down
even if they in the SAD is working fine and possible to do traffic over the interface
is still not corrected.

It shows as an X (error) in Overview and in Dashboard it shows as down (tunnel = down)
but as said, the traffic is working.

Any idea to when it will be up for bug-bashing ?

//Dan Lundqvist

eri--

Have you tried under system tunables to change the prefer.old_ipsec_sa set it to 1 from 0.
That might help stability.

mrzaz

As said, it is only IPv6 that has this problem and I could also see a bug in
the URL for trying to to jumpstart that remote is IPv6 address but source
is IPv4 so it feels there is some underlying bug here.

Anyone else doing IPv6 tunnels that could confirm
this problem. I will include screenshots soon.
Danne

See screenshots and also if I point the mouse at the jumpstart button it gives the following URL:
http://192.168.xxx.xxx/diag_ipsec.php?act=connect&remoteid=2001:470:28:xxx::&source=192.168.xxx.xxx

Shouldn't this be something like:
http://192.168.xxx.xxx/diag_ipsec.php?act=connect&remoteid=2001:470:28:xxx::&source=2001:470:28:yyy::

//Danne

a3.jpg_thumb

a2.jpg_thumb

a1.jpg_thumb

a4.jpg_thumb

mrzaz

@ermal:

Have you tried under system tunables to change the prefer.old_ipsec_sa set it to 1 from 0.
That might help stability.

No, but I have the "System: Advanced: Miscellaneous"
"IP Security -> Security Associations"
Prefer older IPsec SAs = TRUE (ticked)

//Dan

jimp

Show the output of:

setkey -D
setkey -DP

And /var/etc/racoon.conf

I think someone else recently saw this and it turned out to be from the way that we wrote out or compressed/decompressed the IPv6 IP when comparing them. They didn't match exactly because of how it was written on one side or the other.

mrzaz

@jimp:

Show the output of:

setkey -D
setkey -DP

And /var/etc/racoon.conf

I think someone else recently saw this and it turned out to be from the way that we wrote out or compressed/decompressed the IPv6 IP when comparing them. They didn't match exactly because of how it was written on one side or the other.

jimp: Could you mail me off-list where to send the printouts as I don't want to publish that data in the forum.

//Dan Lundqvist

jimp

You can just send it via PM here on the forum.

jimp

I sent a PM asking for more info.

The indicator works for me on current snapshots in the widget and the status page, when I send some traffic the tunnel goes up and I see it turn green on the widget and the status page.

The connect button is definitely broken, I opened a ticket for that.

mrzaz

As you could see in the screenshots it's not just the overview page that shows down/error.
Also the Widget shows the IPSec on the opt1 interface as red=down.

So it seems like something is broken and as you said, it could be rare cases with special
structure in IPv6 address that is causing it. However, the IP assigned to me is real and
official so it is nothing wrong with the addresses. They are assigned by Tunnelbroker.net.

The mystery thickens… :-)

I have sent you a reply via PM.

//Danne

jimp

A commit just went in to fix the connect button for IPv6, so that should work on snaps from later today/tomorrow on.

Still not sure why your tunnel doesn't show as 'up' though. And you say it is actually passing traffic? (You can ping back and forth inside the tunnel)

mrzaz

Jepp, tunnel is working ok and i could see that the bytes is increasing on the SAD screen.

Have tried to ping devices on both ends through the ipsec through the tunnel.

mrzaz

@jimp:

A commit just went in to fix the connect button for IPv6, so that should work on snaps from later today/tomorrow on.

Still not sure why your tunnel doesn't show as 'up' though. And you say it is actually passing traffic? (You can ping back and forth inside the tunnel)

jimp: Please check my latest PM with the test I did.

jimp

I figured it out, it's the local phase 2 being set to "lan" that does it. The status code made an incorrect assumption about what data it had access to, fix will come later today when I get time.

mrzaz

@jimp:

I figured it out, it's the local phase 2 being set to "lan" that does it. The status code made an incorrect assumption about what data it had access to, fix will come later today when I get time.

Good.

It should be able to handle this as:
Address
Network
WAN subnet
LAN subnet
<optx_interface_named_to_whatever>subnet
None

And also possible the NAT/BINAT entries…

//Danne</optx_interface_named_to_whatever>