IPv6_IPSEC + IPv4_with_IPv6phase2tunnels_IPSec status and does it work ?
-
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. -
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.
-
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
-
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.
-
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
-
Have you tried under system tunables to change the prefer.old_ipsec_sa set it to 1 from 0.
That might help stability. -
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.
DanneSee 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.xxxShouldn'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
-
@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
-
Show the output of:
setkey -D
setkey -DPAnd /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.
-
Show the output of:
setkey -D
setkey -DPAnd /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
-
You can just send it via PM here on the forum.
-
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.
-
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
-
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)
-
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.
-
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.
-
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.
-
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
NoneAnd also possible the NAT/BINAT entries…
//Danne</optx_interface_named_to_whatever>
-
Yeah the other parts worked just not the interface macros.
Just checked in a fix, should be in snaps late today/tomorrow. -
I will test it and get back with results.
Checked you checkins in the github activity page. :-)
Thanks for the fixing…
//Danne
