Hi all,
I've tried to select IPv6 only in "VPN->Change adapter options"
parameters for the IKEv2 IPv6 connection.
/etc/ipsec.d/ikev2-ivp6.conf is:
conn MYCONN-ikev2-ipv6-cp
# The server's actual IP goes here - not elastic IPs
left=2001:b68:2:2600::3
leftcert=magrf-ipv6.grf.hr
[email protected]
leftsendcert=always
leftsubnet=0::/0
leftrsasigkey=%cert
# Clients
right=%any
# your addresspool to use - you might need NAT rules if
providing full internet to clients
rightaddresspool=fd00:2600:1000:0000::/96
# optional rightid with restrictions
# rightid="O=GRF-UNIZG,CN=win7client.grf.hr"
rightca=%same
rightrsasigkey=%cert
#
# connection configuration
# DNS servers for clients to use
modecfgdns=2001:b68:2:2600::3,2606:4700:4700::1001
narrowing=yes
# recommended dpd/liveness to cleanup vanished clients
dpddelay=30
# dpdtimeout=120
dpdaction=clear
auto=add
ikev2=insist
rekey=no
# Set ikelifetime and keylife to same defaults windows has
# ikelifetime=8h
# keylife=2h
# ms-dh-downgrade=yes
esp=aes_gcm256,aes_gcm128,aes256-sha2_512,aes128-sha2_512,aes256-sha1,aes128-sha1
#
esp=aes_gcm256-null,aes_gcm128-null,aes256-sha2_512,aes128-sha2_512,aes256-sha1,aes128-sha1,aes_gcm256-null;modp1024
# ikev2 fragmentation support requires libreswan 3.14 or newer
fragmentation=yes
# optional PAM username verification (eg to implement bandwidth
quota
# pam-authorize=yes
authby=rsa-sha1
hostaddrfamily=ipv6
clientaddrfamily=ipv6
If interested in seeing what is going on, the session log is here:
https://magrf.grf.hr/~mtodorov/tmp/ikev2-ipv6-20221101-12.log
I thought that `ipsec barf` output might be interesting:
https://magrf.grf.hr/~mtodorov/tmp/ikey2-ipv6.barf
I am not very skilled at debugging, but it seems that something happens
here:
Nov 1 07:45:09.818966: | next payload chain: setting previous 'ISAKMP
Message'.'next payload type' to current IKEv2 Encryption Payload
(46:ISAKMP_NEXT_v2SK)
Nov 1 07:45:09.819018: | next payload chain: saving location 'IKEv2
Encryption Payload'.'next payload type' in 'information exchange reply
packet'
Nov 1 07:45:09.819047: | emitting 16 zero bytes of IV into IKEv2
Encryption Payload
Nov 1 07:45:09.819084: | adding 16 bytes of padding (including 1 byte
padding-length)
Nov 1 07:45:09.819109: | emitting 0 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819137: | emitting 1 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819162: | emitting 2 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819188: | emitting 3 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819214: | emitting 4 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819238: | emitting 5 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819260: | emitting 6 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819286: | emitting 7 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819311: | emitting 8 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819333: | emitting 9 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819358: | emitting 10 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819383: | emitting 11 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819409: | emitting 12 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819433: | emitting 13 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819457: | emitting 14 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819483: | emitting 15 as 1 bytes of padding and length
into IKEv2 Encryption Payload
Nov 1 07:45:09.819509: | emitting 16 zero bytes of length of truncated
HMAC/KEY into IKEv2 Encryption Payload
Nov 1 07:45:09.819535: | emitting length of IKEv2 Encryption Payload: 52
Nov 1 07:45:09.819556: | emitting length of ISAKMP Message: 80
Nov 1 07:45:09.819646: | result: newref clone-key@0x564de46775c0
(32-bytes, SHA256_HMAC)(init_symkey() +99
/lib/libswan/ike_alg_prf_mac_nss_ops.c)
Nov 1 07:45:09.819696: | integ: delref clone-key@0x564de46775c0
Nov 1 07:45:09.819738: | recording outgoing fragment failed
Nov 1 07:45:09.819768: | #1 complete_v2_state_transition()
ESTABLISHED_IKE_SA->ESTABLISHED_IKE_SA with status
STF_V2_RESPONDER_DELETE_IKE_FAMILY
Nov 1 07:45:09.819815: | Message ID: IKE #1 finishing old exchange
(STF_V2_RESPONDER_DELETE_IKE_FAMILY) (initiator: .sent=-1 .recv=-1
.recv_frags=0 .wip=-1 .last_sent=423503.900793 .last_recv=423503.900793
responder: .sent=1 .recv=1 .recv_frags=3 .wip=2 .last_sent=423504.263085
.last_recv=423504.262933)
Nov 1 07:45:09.819853: | Message ID: IKE #1 updating responder received
message request 2 (initiator: responder: .recv=1->2 .recv_frags=3->0
.wip=2->-1 .last_recv=423504.262933->423504.308133)
Nov 1 07:45:09.819887: | Message ID: IKE #1 updating responder sent
message response 2 (initiator: responder: .sent=1->2
.last_sent=423504.263085->423504.308169)
Nov 1 07:45:09.819951: | sending 84 bytes for DELETE_IKE_FAMILY through
enp1s0 from [2001:b68:2:2600::3]:4500 to [2a05:4f46:31a:7500::1]:4500
using UDP (for #1)
Nov 1 07:45:09.819981: | 00 00 00 00 06 08 70 06 26 53 de 35 fa d2
2c 59 ......p.&S.5..,Y
Nov 1 07:45:09.820006: | 37 38 4e e7 2e 20 25 20 00 00 00 02 00 00
00 50 78N.. % .......P
Nov 1 07:45:09.820032: | 00 00 00 34 66 29 2e 94 42 25 a1 72 2d b9
66 7e ...4f)..B%.r-.f~
Nov 1 07:45:09.820057: | 35 36 e7 6a b7 89 e5 36 91 2d 45 48 71 19
6e 47 56.j...6.-EHq.nG
Nov 1 07:45:09.820083: | bc a9 7d 3c 10 36 05 69 8c 3a 98 95 27 72
95 96 ..}<.6.i.:..'r..
Nov 1 07:45:09.820109: | 11 56 f1
ad .V..
Nov 1 07:45:09.820262: | sent 1 messages
Nov 1 07:45:09.820297: | delete_ike_family() called
... here pluto decides to call delete_ike_family() and tear down already
established up-lcinet-v6, prepare-client-v6 and route-client-v6 ...
However, even after almost a year, I still cannot see through this
complexity, mainly because the Windows system is a black box.
The error from Windows 10 Ent event log is "840".
"CoId={55E826AB-ED51-0003-7313-E95551EDD801}: The user
LAPTOP-MTODOROV\Mirsad dialed a connection named IKEv2 IPv6 magrf which
has failed. The error code returned on failure is 840."
CoId={55E826AB-ED51-0003-7313-E95551EDD801}: The user
LAPTOP-MTODOROV\Mirsad has started dialing a VPN connection using a
per-user connection profile named IKEv2 IPv6 magrf. The connection
settings are:
Dial-in User =
VpnStrategy = IKEv2
DataEncryption = Requested
PrerequisiteEntry =
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = Machine Certificate
Ipv4DefaultGateway = Yes
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = Yes
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags =
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Mobility enabled for IKEv2 = Yes.
Somehow he doesn't want to realise that I have excluded IPv4 link from
connection here:
I have turned on NPT:
root@magrf:~/libreswan_build# ip6tables-save
# Generated by ip6tables-save v1.8.7 on Tue Nov 1 08:23:09 2022
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING ! -d 2001:b68:2:2600::3/128 -i enp1s0 -j DNPT --src-pfx
2001:b68:2:2600::/64 --dst-pfx fd00:2600:1000::/64
-A POSTROUTING -s fd00:2600:1000::/64 -o enp1s0 -j SNPT --src-pfx
fd00:2600:1000::/64 --dst-pfx 2001:b68:2:2600::/64
COMMIT
# Completed on Tue Nov 1 08:23:09 2022
Any idea would be welcome.
While there is danger of COVID I can always justify the need for working
from home and on VPNs.
Thank you very much in forward.
I know that developers have a lot on their stack, so thank you for your
time and attention.
Kind regards,
Mirsad
--
Mirsad Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
