streambinder / vpnc

IPsec (Cisco/Juniper) VPN concentrator client

Systems Engineer at @Meta

Email	Website	Resume	LinkedIn	Twitter	Spotify	Instagram

vpnc's Issues

Transferring ideas and patches from old vpnc email archives

Hi Davide,
would you be willing to poke through the old email archives at https://vpnc-devel.unix-ag.uni-kl.narkive.com/ trying to find viable ideas for improvements, rescuing&reviewing old patches, etc., and transferring them to your github repo? Thank you for your efforts to rescue vpnc.

License file is wrong

The license is GPLv2 not GPLv3.

Support additional DH-Groups

Hi,

would it be possible to support the additional MODP DH groups, [1], [2], 14 and 15, and maybe even the ECC ones 19 and 20?

Apparently, @thillux added those groups to his fork of vpnc, see the commit fe498799. As your version is used e.g. by OpenWRT and Arch, the support of those DH groups would be very useful for compatibility with other systems.

Thank you very much, best regards
Andreas

[1] https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/diffie_hellman_c.html
[2] https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-edit-dh-group.html

Changing MTU

Changing the MTU either by --ifmtu 1180 of by Interface MTU 1180 in the config does not have any effect. The created tun0 interface always has MTU 1500.

Trying that for nested VPN, a nested vpnc fails with the default MTU of 1500. Trying to manually set in the background
ip link set dev tun0 mtu 1180
doesn't seem to solve it.

Ipsec VPN connection fails with message "vpnc: xauth SET message rejected: (ISAKMP_N_INVALID_PAYLOAD_TYPE)(1)"

Hello!

My company uses a watchguard firebox T30 VPN. We use a pre-shared key, so my vpn configuration looks like:

# example vpnc configuration file
# see vpnc --long-help for details

Interface name tun0 
#IKE DH Group dh2
Perfect Forward Secrecy nopfs

# You may replace this script with something better
#Script /etc/vpnc/vpnc-script
# Enable this option for NAT traversal
#UDP Encapsulate

IPSec gateway 11.22.33.44
IPSec ID ipsec_default
IPSec secret shared_secret
Xauth username myusername
Xauth password mypassword

When I try to run vpnc I get the following error:

[username@machine]$ sudo vpnc vpn.conf
[sudo] password for rminkler: 
vpnc: xauth SET message rejected:  (ISAKMP_N_INVALID_PAYLOAD_TYPE)(1)

I use the VPN with this configuration from iOS and OS X without issue.

Any ideas? Is there any other info that would be useful?

Thank you,

rminkler

vpnc 0.5.3.r501 on Arch Linux causes openconnect to not work

I'm not sure if this is the right place to submit this issue, but this repo is referenced here.

I'll just copy what I posted in the Arch Forum:

Hello everyone

Yesterday, i had VPN to university (Cisco AnyConnect) working on both my computer and laptop with openconnect. Then I updated my computer. The output of openconnect 8.20 looks different. And there was appareantly no connection. I could not ping any server in the university network (except my own ip address. After a minute or so, openconnect would say

DTLS Dead Peer Detection detected dead peer!
CSTP Dead Peer Detection detected dead peer!

At the same time it was still working on my Laptop.

Then I thought this looks like it is an issue with openconnect. But downgrading openconnect to 8.10 would not solve the issue. The output of openconnect would return to what I was used to, but I still can not connect.

Any idea what I could check or which component/package could cause the issue or what I can check?

full openconnect ouput (privatized):

$ pass foo/bar | sudo openconnect --cafile="/path/to/cert.pem" --authgroup=extern --user="foo" --passwd-on-stdin --verbose https://vpn.foo
connection with profile extern
POST https://vpn.FOO
Attempting to connect to server [IP6FOO]:443
Connected to [2001:FOO]:443
SSL negotiation with vpn.FOO
Connected to HTTPS on vpn.FOO with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Sun, 13 Mar 2022 06:55:51 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self'
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
Please enter your username and password.
POST https://vpn.FOO
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Sun, 13 Mar 2022 06:55:52 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self'
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
Please enter your username and password.
POST https://vpn.FOO
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Sun, 13 Mar 2022 06:55:52 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self'
X-Aggregate-Auth: 1
HTTP body chunked (-2)
TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1420, pmtu 1492
Got CONNECT response: HTTP/1.1 200 OK
X-CSTP-Version: 1
X-CSTP-Protocol: Copyright (c) 2004 Cisco Systems, Inc.
X-CSTP-Address: IP4FOO
X-CSTP-Netmask: 255.255.255.0
X-CSTP-Address-IP6: IP6FOO
X-CSTP-Hostname: DOMAINFOO
X-CSTP-DNS: IP4FOO
X-CSTP-DNS: IP4FOO
X-CSTP-DNS-IP6: IP6FOO
X-CSTP-DNS-IP6: IP6FOO
X-CSTP-Lease-Duration: 1209600
X-CSTP-Session-Timeout: none
X-CSTP-Session-Timeout-Alert-Interval: 60
X-CSTP-Session-Timeout-Remaining: none
X-CSTP-Idle-Timeout: 3600
X-CSTP-Disconnected-Timeout: 3600
X-CSTP-Default-Domain: FOO
X-CSTP-Split-Include: IP4FOO/255.255.0.0
X-CSTP-Split-Include-IP6: IP6FOO/40
X-CSTP-Keep: true
X-CSTP-Tunnel-All-DNS: false
X-CSTP-DPD: 30
X-CSTP-Keepalive: 20
X-CSTP-MSIE-Proxy-Lockdown: true
X-CSTP-Smartcard-Removal-Disconnect: true
X-DTLS-Session-ID: FOO
X-DTLS-Port: 443
X-DTLS-Keepalive: 20
X-DTLS-DPD: 30
X-CSTP-MTU: 1287
X-DTLS-MTU: 1356
X-DTLS12-CipherSuite: ECDHE-RSA-AES256-GCM-SHA384
X-CSTP-Routing-Filtering-Ignore: false
X-CSTP-Quarantine: false
X-CSTP-Disable-Always-On-VPN: false
X-CSTP-Client-Bypass-Protocol: false
X-CSTP-TCP-Keepalive: true
X-CSTP-Post-Auth-XML: <elided>
CSTP connected. DPD 30, Keepalive 20
DTLS option X-DTLS-Session-ID : FOO
DTLS option X-DTLS-Port : 443
DTLS option X-DTLS-Keepalive : 20
DTLS option X-DTLS-DPD : 30
DTLS option X-DTLS-MTU : 1356
DTLS option X-DTLS12-CipherSuite : ECDHE-RSA-AES256-GCM-SHA384
DTLS initialised. DPD 30, Keepalive 20
Connected as IP4FOO + IP6FOO, using SSL, with DTLS in progress
Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(ECDHE-RSA)-(AES-256-GCM).
Initiating MTU detection (min=576, max=1356)
No change in MTU after detection (was 1356)
Send CSTP Keepalive
Send DTLS DPD
Send CSTP DPD
Send DTLS DPD
Send CSTP DPD
Send DTLS DPD
Send CSTP DPD
DTLS Dead Peer Detection detected dead peer!
CSTP Dead Peer Detection detected dead peer!

Then I found out, that with vpnc-0.5.3.r496 it works. Is this a vpnc bug?

Assertion fails when connecting to VPN server

Hi

When I try to connect to my VPN server using this package on Arch Linux (via networkmanager-vpnc), the connection fails after a couple of seconds of starting the VPN.

The logs are as follows:

systemd-coredump[96293]: Process 96279 (vpnc) of user 0 dumped core.
                                        
Stack trace of thread 96279:
#0  0x00007fa808514ce5 raise (libc.so.6 + 0x3bce5)
#1  0x00007fa8084fe857 abort (libc.so.6 + 0x25857)
#2  0x00007fa8084fe727 __assert_fail_base.cold (libc.so.6 + 0x25727)
#3  0x00007fa80850d426 __assert_fail (libc.so.6 + 0x34426)
#4  0x000055875b8adf57 n/a (vpnc + 0x10f57)
#5  0x000055875b8b2f34 n/a (vpnc + 0x15f34)
#6  0x000055875b8a38b4 n/a (vpnc + 0x68b4)
#7  0x00007fa808500023 __libc_start_main (libc.so.6 + 0x27023)
#8  0x000055875b8a40ce n/a (vpnc + 0x70ce)

This appears to be the same issue as is described on the Arch Wiki.

I see the code has changed since then and now checks if the server is not a Fortigate VPN. I think that my VPN server may be such a Fortigate device, but I'm not sure. Perhaps the string is slightly different and this isn't executed. Disabling the assertion here fixes the problem, as it did before.

I could try logging the name somewhere and building from source, but am not familiar with the codebase. If desirable, I can follow directions to help debug it.

Thanks in advance.

Error decrypting signature: unexpected decrypted size 512 (expected 256)

Hi Davide,
would you please have a look into the testing suite and see why it fails?

make -j1   test
./test-crypto test/sig_data.bin test/dec_data.bin test/ca_list.pem \
	test/cert3.pem test/cert2.pem test/cert1.pem 
Error decrypting signature: unexpected decrypted size 512 (expected 256)
Makefile:117: recipe for target 'test' failed
make: *** [test] Error 1
 * ERROR: net-misc/vpnc-0.5.3_p550::gentoo failed (test phase):
 *   Make test failed. See above for details.

https://vpnc-devel.unix-ag.uni-kl.narkive.com/qR70FPOS/test-failure-error-decrypting-signature-unexpected-decrypted-size-512-expected-256
https://bugs.gentoo.org/show_bug.cgi?id=541982

Change bug report address to this upstream

Hey,

While updating vpnc for Sailfish OS I've noticed that vpnc --help still mentions the old upstream as contact address to report bugs.

Is this correct?

ship/merge openconnect's vpnc-script?

The main issue for me with the currently shipped vpnc-script is that it doesn't route IPv6.

• From man openconnect:

  Note that although IPv6 has been tested on all platforms on which openconnect is known to run, it depends on a suitable vpnc-script to configure the network. The standard vpnc-script shipped with vpnc 0.5.3 is not capable of setting up IPv6 routes; the one from git://git.infradead.org/users/dwmw2/vpnc-scripts.git will be required.

• From openconnect's documentation:

  Even if you already have a copy from vpnc, you may wish to install this updated version which has support for IPv6, and for running on Solaris and on newer Linux kernels amongst other bug fixes.

@dwmw2, author of openconnect, maintains a vpnc-script at http://git.infradead.org/users/dwmw2/vpnc-scripts.git. This vpnc-script is already shipped by default on Arch. See also the discussions to make it the default (1, 2).

Would there be any downside to ship or merge the vpnc-script maintained by openconnect?

Flooding logs

Starting with 9cb925c vpnc is flooding the log with:

Accepting expected ESP packet with seq 366

I think expected packages do not need to be logged, no? Can we please stop flooding?

Mutualize maintenance efforts?

Distributions independently maintain patches for vpnc. Examples:

• https://salsa.debian.org/debian/vpnc
• https://apps.fedoraproject.org/packages/vpnc/changelog
• https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/vpnc
• https://gitweb.gentoo.org/repo/gentoo.git/tree/net-vpn/vpnc/files

While Arch uses this repo as the upstream, the others seem to base their patches on the unmaintained original SVN.

As everyone seems to mostly do the same things (e.g., add a systemd service file), it might make sense to ping the maintainers and mutualize maintenance efforts here.

target network bug/usage

I am using vpnc to connect to my company vpn, vpnc connect to the network but only the connections to the addresses behind the vpn are working. I have tried to use the option IPSEC target network X.X.X.X/24 to route only traffic to these addresses and leave the others outside the vpn but when I start vpnc I have this output:

vpnc version 0.5.3
IKE SA selected psk+xauth-aes256-sha1
NAT status: this end behind NAT? YES -- remote end behind NAT? no
NAT-T mode: 2
got address X.X.X.X

and after seconds:

vpnc: no response from target
Error: argument "via" is wrong: use nexthop syntax to specify multiple via

I am using systemd-networkd with systemd-resolved and when vpnc is trying to establish the connection I have this output from resolvectl status:

Global
           Protocols: +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
    resolv.conf mode: stub
  Current DNS Server: 2001:4860:4860::8888#dns.google
         DNS Servers: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.10#dns.quad9.net 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::10#dns.quad9.net

Link 3 (wlan0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
Current DNS Server: 192.168.1.254
       DNS Servers: 192.168.1.254 2001:b07:aa7:c399::1

Link 4 (docker0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported

Link 6 (tun0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 8.8.4.

What is wrong? How can I route only the connections to these addresses with vpnc?

Incorrect FSF address in GPLv2 headers

Hey,

I noticed that the GPLv2 headers are out of date they use the old FSF address, it should be this header:

one line to give the program's name and an idea of what it does.
Copyright (C) yyyy  name of author

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

Another way would be convert to SPDX metadata instead.
https://spdx.dev/resources/use/

ESP replay

I think you need this:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/4abcc5b8f43aa6e71942bd63bfe2155dc8d77895

Remove Jolla Ltd. as a copyright holder.

Apparently Jolla Ltd. did not provide any code changes while commit 46b8335 introduced a line like 'SPDX-FileCopyrightText: 2023 Jolla Ltd.' to almost every file under src/.

I am happy to provide a PR later on. Unfortunately I cannot provide one now without including #47 into it.