IPv6_IPSEC + IPv4_with_IPv6phase2tunnels_IPSec status and does it work ?
-
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
-
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
-
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.
-
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 freedI 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
-
Can you send me your ipsec part of config xml including interface config?
Through PM or email whichever you prefer. -
Check the PM i sent.
//Dan
-
I have no PM sure you sent to me?
-
blush I have talked to jimp throughout this thread and forgot to check the sender in the last post.
I sent it to him. sorry for that. I will forward it to you as well. Speak to jimp as well to get som
more details on what we have been talking about. Have sent a few mails outside the thread as PM.You will get the config in a minute…
The IPSec v6 was working fine until I installed the 7 March build. (the from state was a few days earlier)
//Danne
UPDATE: A small typo in the comments for IPSec v6 phase2. Forgot to change from phase1 to phase 2 after copy/paste. (in mail sent a PM)
-
I have checked and it could be even worse than I expected.
I have started to see generic problem with IPv6 in general where I could see incoming IPv6 ICMP echo requests
(that I triggered) but no echo reply even if I have full ICMPv6 enabled from ALL on the Tunnelbroker interface.This IPv6 interface has been working for a long time.
And this has also started in the last few days builds.
I will revert to an old build to see if the problems disapears just to confirm problem in the builds.
I will keep you posted on the result.//Dan
UPDATE: A small hint could be that there is something strange with routing.
I tried to do a ping (from internet) to a machine inside my LAN that is accepted and tried to ping it and get the following: (replace part of my IP with "xxx")Wireshark from the inside machine.
Time Source Destination Dest Port Dest port Protocol Length Info New Column
0.000000000 2a02:348:82:cb69::1 2001:470:28:xxx:f66d:4ff:fe06:3ba8 ICMPv6 94 Echo (ping) request id=0x350b, seq=0 1
0.000177000 2001:470:28:xxx:f66d:4ff:fe06:3ba8 2a02:348:82:cb69::1 ICMPv6 94 Echo (ping) reply id=0x350b, seq=0 2
0.000286000 2001:470:28:xxx::1 2001:470:28:xxx:f66d:4ff:fe06:3ba8 ICMPv6 142 Destination Unreachable (no route to destination) 32001:470:28:xxx::1 = the LAN interface IP-address.
As you could see there is something strange going on.
Connections initiated from the pfSense directly is working OK but all secondary replies is not.
I have checked the Routing table **and it is now missing the "default 2001:470:27:xxx::1" entry. **
I went into the routing and uncheck the "Default Gateway" entry for the IPv6 entry and pressed apply.
And then in again and checked it again. + apply. But still no "default" entry for the IPv6 table… -
For the default gateway missing issue, You should do a gitsync or wait for a newer snapshot, see here: http://forum.pfsense.org/index.php/topic,58731.msg315026.html#msg315026
Hopefully, the next snap is on its way - there are a few people updated to the Feb 9 snaps which have this default gateway issue, and it would be good to stop any more from doing it. Perhaps this is another moment to pull the latest snaps off the server.
