[Swan] Libreswan 4.8 IPv6 connection problem: "The parameter is incorrect"

Mirsad Goran Todorovac mirsad.todorovac at alu.unizg.hr
Wed Oct 5 17:18:02 EEST 2022


P.S.

Forgot to mention, the VPN client is Windows 10 Professional version 21H2:

Kind regards,

mt

On 5.10.2022. 15:58, Mirsad Goran Todorovac wrote:
> Hi all,
>
> Our VPN worked well until we moved to IPv6, and now it works only with 
> IPv6 disabled,
> which is not practical (change of network settings resets all Putty 
> terminal and all ssh connections
> among others ... ).
>
> The configuration is as follows:
>
> conn MYCONN-ikev2-ipv6-cp
>         # The server's actual IP goes here - not elastic IPs
>         left=2001:b68:2:2600::3
>         leftcert=magrf.grf.hr
> leftid=@magrf.grf.hr
>         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/64
>         # 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
>
> I am using a small script that should allow NPT to the VPN-allocated 
> addr range:
>
> #!/bin/bash
>
> # 2022-10-05 mtodorov
>
> GWY_EXTERNAL=2001:b68:2:2600::3
> EXTERNAL=2001:b68:2:2600::/64
> INTERNAL=fd00:2600:1000:0000::/64
>
> case "$1" in
>         start)
>                 modprobe ip6table_mangle
>                 modprobe ip6t_NPT
>                 ip6tables -t mangle -A PREROUTING \! -d $GWY_EXTERNAL 
> -i enp1s0 -j DNPT --src-pfx $EXTERNAL --dst-pfx $INTERNAL
>                 ip6tables -t mangle -A POSTROUTING -s $INTERNAL -o 
> enp1s0 -j SNPT --src-pfx $INTERNAL --dst-pfx $EXTERNAL
>                 ;;
>         stop)
>                 ip6tables -t mangle -D PREROUTING \! -d $GWY_EXTERNAL 
> -i enp1s0 -j DNPT --src-pfx $EXTERNAL --dst-pfx $INTERNAL
>                 ip6tables -t mangle -D POSTROUTING -s $INTERNAL -o 
> enp1s0 -j SNPT --src-pfx $INTERNAL --dst-pfx $EXTERNAL
>                 sleep 1
>                 modprobe -r ip6t_NPT
>                 modprobe -r ip6table_mangle
>                 ;;
>         *) echo "Usage $0: start | stop"
> esac
>
> The result is:
>
> root at magrf:~# ip6tables-save
> # Generated by ip6tables-save v1.8.7 on Wed Oct  5 15:53:29 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 Wed Oct  5 15:53:29 2022
> # Warning: ip6tables-legacy tables present, use ip6tables-legacy-save 
> to see them
> root at magrf:~#
>
> The session log is here: 
> https://magrf.grf.hr/~mtodorov/tmp/ikev2-ipv6-20221005-01.log
>
> I hope this helps.
> It seems to me that Libreswan attempts to retransmit to the VPN client 
> too early withing the same second?
>
> Could that be a bug or is it a mistake in configuration?
>
> Thank you.
>
> Kind regards,
> mt
>
-- 
Mirsad Todorovac
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
--
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20221005/08b9e1cd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: k2xQoRcOs5shlHT9.png
Type: image/png
Size: 21593 bytes
Desc: not available
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20221005/08b9e1cd/attachment-0001.png>


More information about the Swan mailing list