IPv6_IPSEC + IPv4_with_IPv6phase2tunnels_IPSec status and does it work ?

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>

jimp

Yeah the other parts worked just not the interface macros.
Just checked in a fix, should be in snaps late today/tomorrow.

mrzaz

I will test it and get back with results.

Checked you checkins in the github activity page. :-)

Thanks for the fixing…

//Danne

mrzaz

@jimp:

Yeah the other parts worked just not the interface macros.
Just checked in a fix, should be in snaps late today/tomorrow.

Have tested the "Thu Feb 7 07:21:31 EST 2013" release but can't see the "Connect button" fix (still shows src=192.168…)
and also I have even more problems with the IPv6 tunnels. Now they are not even coming up. :-/

And saw the following in the RACOON Debug log. (have have altered some IPv6 address to protect me. (xxx= remote yyy=local)

Feb 7 20:32:24 racoon: DEBUG: IV freed
Feb 7 20:32:24 racoon: [XXXXX KUNGSGATAN VPN IPv6]: [2001:470:27:xxx::2] ERROR: failed to pre-process ph2 packet [Check Phase 2 settings, networks] (side: 1, status: 1).
Feb 7 20:32:24 racoon: ERROR: failed to get sainfo.
Feb 7 20:32:24 racoon: ERROR: failed to get sainfo.
Feb 7 20:32:24 racoon: DEBUG: check and compare ids : id type mismatch IPv4_subnet != IPv6_subnet
Feb 7 20:32:24 racoon: DEBUG: evaluating sainfo: loc='192.168.120.0/24', rmt='2001:470:28:xxx::/64', peer='ANY', id=2
Feb 7 20:32:24 racoon: DEBUG: remoteid mismatch: 3 != 2
Feb 7 20:32:24 racoon: DEBUG: evaluating sainfo: loc='192.168.120.0/24', rmt='192.168.192.0/24', peer='ANY', id=3
Feb 7 20:32:24 racoon: DEBUG: remoteid mismatch: 1 != 2
Feb 7 20:32:24 racoon: DEBUG: evaluating sainfo: loc='192.168.120.0/24', rmt='192.168.100.0/24', peer='ANY', id=1
Feb 7 20:32:24 racoon: DEBUG: getsainfo params: loc='2001:470:28:yyy::/64' rmt='2001:470:28:xxx::/64' peer='2001:470:27:xxx::2' client='2001:470:27:xxx::2' id=2

//Danne

jimp

Edit your phase 2's and make sure the ipv4 and ipv6 ones have the correct tunnel mode selected (tunnel or tunnel6).

Ermal checked in a fix for a typo I made so it's also possible that caused the issue as well, but I don't recall if the code there was used in that particular path or not.

mrzaz

I just checked an unmodified setting of the IPv6 tunnel and both phase1 proto = IPv6 and phase2 = TunnelIPv6 and Local = LAN Subnet, Remote = Network + IPv6 address /64
but still got the problem shown above in previous mail.

//Dan

Jimp:

UPDATE: Have now tested "built on Fri Feb 8 05:38:00 EST 2013" but the Connect button is still
"http://192.168.120.20/diag_ipsec.php?act=connect&remoteid=2001:470:28:xxx::&source=192.168.120.20"

And also I am now still not able to get the IPSec v6 again. It is broken. It broke in any of the latest builds.

Still seeing these kinds of problems:
Feb 8 21:06:27 pfsense racoon: DEBUG: getsainfo params: loc='2001:470:28:dd5::/64' rmt='2001:470:28:54c::/64' peer='2001:470:27:54c::2' client='2001:470:27:54c::2' id=2
Feb 8 21:06:27 pfsense racoon: DEBUG: evaluating sainfo: loc='192.168.120.0/24', rmt='2001:470:28:54c::/64', peer='ANY', id=2
Feb 8 21:06:27 pfsense racoon: DEBUG: check and compare ids : id type mismatch IPv4_subnet != IPv6_subnet
Feb 8 21:06:27 pfsense racoon: ERROR: failed to get sainfo.
Feb 8 21:06:27 pfsense racoon: ERROR: failed to get sainfo.
Feb 8 21:06:27 pfsense racoon: [2001:470:27:54c::2] ERROR: failed to pre-process ph2 packet (side: 1, status: 1).
Feb 8 21:06:27 pfsense racoon: DEBUG: IV freed

I have tested to toggle the value in the setting to get it to work but same result.

I have also tried to wipe the whole IPSec_v6 tunnel incl. phase1 and 2 and completly rebuilt from scratch but same result.

//Dan

eri--

Can you send me your ipsec part of config xml including interface config?
Through PM or email whichever you prefer.

mrzaz

Check the PM i sent.

//Dan

eri--

I have no PM sure you sent to me?