After some r-configuring I'm receiving now "TLS record too short to verify MAC" Which record is to short? Am I using a wrong ike or esp setting?
conn %default keyexchange=ikev2 dpdaction=clear ike=aes256-sha1-modp1024! esp=aes256-sha1! dpddelay=300s rekey=no conn winCert left=%defaultroute leftcert=vpn.server.cert.pem leftauth=pubkey leftsubnet=0.0.0.0/24 right=%any rightauth=eap-tls eap_identity=%identity rightsendcert=never rightsourceip=172.20.1.1/24 keyexchange=ikev2 auto=add May 3 14:01:19 12[CFG] selected peer config 'winCert' May 3 14:01:19 12[IKE] initiating EAP-Identity request May 3 14:01:19 12[IKE] processing INTERNAL_IP4_ADDRESS attribute May 3 14:01:19 12[IKE] processing INTERNAL_IP4_DNS attribute May 3 14:01:19 12[IKE] processing INTERNAL_IP4_NBNS attribute May 3 14:01:19 12[IKE] processing INTERNAL_IP4_SERVER attribute May 3 14:01:19 12[IKE] processing INTERNAL_IP6_ADDRESS attribute May 3 14:01:19 12[IKE] processing INTERNAL_IP6_DNS attribute May 3 14:01:19 12[IKE] processing INTERNAL_IP6_SERVER attribute May 3 14:01:19 12[IKE] peer supports MOBIKE May 3 14:01:19 12[IKE] authentication of 'C=CN, O=EXMPLE, CN=vpn.EXMPLE.de' (myself) with RSA signature successful May 3 14:01:19 12[IKE] sending end entity cert "C=CN, O=EXMPLE, CN=vpn.EXMPLE.de" May 3 14:01:20 13[IKE] received EAP identity '[email protected]' May 3 14:01:20 13[TLS] 33 supported TLS cipher suites: May 3 14:01:20 13[TLS] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA May 3 14:01:20 13[TLS] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA May 3 14:01:20 13[TLS] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 May 3 14:01:20 13[TLS] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA May 3 14:01:20 13[TLS] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA May 3 14:01:20 13[TLS] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_AES_128_CBC_SHA May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_AES_256_CBC_SHA May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_AES_128_CBC_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_AES_128_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_RSA_WITH_AES_256_CBC_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_AES_256_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_RSA_WITH_CAMELLIA_128_CBC_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_RSA_WITH_CAMELLIA_256_CBC_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 May 3 14:01:20 13[TLS] TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA May 3 14:01:20 13[TLS] TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_3DES_EDE_CBC_SHA May 3 14:01:20 13[TLS] TLS_ECDHE_ECDSA_WITH_NULL_SHA May 3 14:01:20 13[TLS] TLS_ECDHE_RSA_WITH_NULL_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_NULL_SHA May 3 14:01:20 13[TLS] TLS_RSA_WITH_NULL_SHA256 May 3 14:01:20 13[TLS] TLS_RSA_WITH_NULL_MD5 May 3 14:01:20 13[TLS] sending EAP_TLS start packet (6 bytes) May 3 14:01:20 13[IKE] initiating EAP_TLS method (id 0x07) May 3 14:01:20 14[TLS] processing TLS Handshake record (169 bytes) May 3 14:01:20 14[TLS] received TLS ClientHello handshake (165 bytes) May 3 14:01:20 14[TLS] received TLS 'status request' extension May 3 14:01:20 14[TLS] received TLS 'elliptic curves' extension May 3 14:01:20 14[TLS] received TLS 'ec point formats' extension May 3 14:01:20 14[TLS] received TLS 'signature algorithms' extension May 3 14:01:20 14[TLS] received TLS '(35)' extension May 3 14:01:20 14[TLS] received TLS '(23)' extension May 3 14:01:20 14[TLS] received TLS 'renegotiation info' extension May 3 14:01:20 14[TLS] received 30 TLS cipher suites: May 3 14:01:20 14[TLS] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 May 3 14:01:20 14[TLS] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 May 3 14:01:20 14[TLS] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 May 3 14:01:20 14[TLS] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 May 3 14:01:20 14[TLS] TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 May 3 14:01:20 14[TLS] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 May 3 14:01:20 14[TLS] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 May 3 14:01:20 14[TLS] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 May 3 14:01:20 14[TLS] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 May 3 14:01:20 14[TLS] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 May 3 14:01:20 14[TLS] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA May 3 14:01:20 14[TLS] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA May 3 14:01:20 14[TLS] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA May 3 14:01:20 14[TLS] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA May 3 14:01:20 14[TLS] TLS_DHE_RSA_WITH_AES_256_CBC_SHA May 3 14:01:20 14[TLS] TLS_DHE_RSA_WITH_AES_128_CBC_SHA May 3 14:01:20 14[TLS] TLS_RSA_WITH_AES_256_GCM_SHA384 May 3 14:01:20 14[TLS] TLS_RSA_WITH_AES_128_GCM_SHA256 May 3 14:01:20 14[TLS] TLS_RSA_WITH_AES_256_CBC_SHA256 May 3 14:01:20 14[TLS] TLS_RSA_WITH_AES_128_CBC_SHA256 May 3 14:01:20 14[TLS] TLS_RSA_WITH_AES_256_CBC_SHA May 3 14:01:20 14[TLS] TLS_RSA_WITH_AES_128_CBC_SHA May 3 14:01:20 14[TLS] TLS_RSA_WITH_3DES_EDE_CBC_SHA May 3 14:01:20 14[TLS] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 May 3 14:01:20 14[TLS] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 May 3 14:01:20 14[TLS] TLS_DHE_DSS_WITH_AES_256_CBC_SHA May 3 14:01:20 14[TLS] TLS_DHE_DSS_WITH_AES_128_CBC_SHA May 3 14:01:20 14[TLS] TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA May 3 14:01:20 14[TLS] TLS_RSA_WITH_RC4_128_SHA May 3 14:01:20 14[TLS] TLS_RSA_WITH_RC4_128_MD5 May 3 14:01:20 14[TLS] negotiated TLS version TLS 1.2 with suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA May 3 14:01:20 14[TLS] sending TLS ServerHello handshake (38 bytes) May 3 14:01:20 14[TLS] sending TLS server certificate 'C=CN, O=EXMPLE, CN=vpn.EXMPLE.de' May 3 14:01:20 14[TLS] sending TLS Certificate handshake (853 bytes) May 3 14:01:20 14[TLS] selected ECDH group SECP256R1 May 3 14:01:20 14[TLS] created signature with SHA256/RSA May 3 14:01:20 14[TLS] sending TLS ServerKeyExchange handshake (329 bytes) May 3 14:01:20 14[TLS] sending TLS cert request for 'C=CN, O=EXMPLE, CN=EXMPLE ca' May 3 14:01:20 14[TLS] sending TLS CertificateRequest handshake (87 bytes) May 3 14:01:20 14[TLS] sending TLS ServerHelloDone handshake (0 bytes) May 3 14:01:20 14[TLS] sending TLS Handshake record (1327 bytes) May 3 14:01:20 14[TLS] sending EAP_TLS first fragment (512 bytes) May 3 14:01:20 15[TLS] received EAP_TLS acknowledgement packet May 3 14:01:20 15[TLS] sending EAP_TLS further fragment (512 bytes) May 3 14:01:20 16[TLS] received EAP_TLS acknowledgement packet May 3 14:01:20 16[TLS] sending EAP_TLS final fragment (330 bytes) May 3 14:01:20 05[TLS] processing TLS Handshake record (1206 bytes) May 3 14:01:20 05[TLS] received TLS Certificate handshake (868 bytes) May 3 14:01:20 05[TLS] received TLS peer certificate 'C=CN, O=EXMPLE, [email protected]' May 3 14:01:20 05[TLS] received TLS ClientKeyExchange handshake (66 bytes) May 3 14:01:20 05[TLS] received TLS CertificateVerify handshake (260 bytes) May 3 14:01:20 05[CFG] using certificate "C=CN, O=EXMPLE, [email protected]" May 3 14:01:20 05[CFG] certificate "C=CN, O=EXMPLE, [email protected]" key: 2048 bit RSA May 3 14:01:20 05[CFG] using trusted ca certificate "C=CN, O=EXMPLE, CN=EXMPLE ca" May 3 14:01:20 05[CFG] checking certificate status of "C=CN, O=EXMPLE, [email protected]" May 3 14:01:20 05[CFG] ocsp check skipped, no ocsp found May 3 14:01:20 05[CFG] certificate status is not available May 3 14:01:20 05[CFG] certificate "C=CN, O=EXMPLE, CN=EXMPLE ca" key: 2048 bit RSA May 3 14:01:20 05[CFG] reached self-signed root ca with a path length of 0 May 3 14:01:20 05[TLS] verified signature with SHA1/RSA May 3 14:01:20 05[TLS] processing TLS ChangeCipherSpec record (1 bytes) May 3 14:01:20 05[TLS] processing TLS Handshake record (64 bytes) May 3 14:01:20 05[TLS] TLS record too short to verify MAC May 3 14:01:20 05[TLS] sending fatal TLS alert 'bad record mac' May 3 14:01:20 05[TLS] sending TLS Alert record (2 bytes) May 3 14:01:20 05[TLS] sending EAP_TLS packet (17 bytes) May 3 14:01:20 10[TLS] received EAP_TLS acknowledgement packet May 3 14:01:20 10[IKE] EAP method EAP_TLS failed for peer 10.145.250.86 May 3 14:01:20 10[IKE] IKE_SA winCert[1] state change: CONNECTING => DESTROYING Thanks, Arne > To: [email protected]; [email protected] > From: [email protected] > Date: Mon, 2 May 2016 13:01:38 +0200 > Subject: Re: [strongSwan] Net-to-Net wrong source IP of VPN server. > > Hello Tobias, > > I'm very sorry for previous wrong output. It was caused by fact I had > wrong config loaded(where I was trying various things in order to fix my > problem). Now I restarted ipsec on both VPN boxes and I have: > > # ip route list table 220 > 192.168.1.0/24 via 1.2.3.1 dev eth0.2 proto static src 192.168.2.1 > > But when I do ping to host that is obviously running and has firewall > with any/any allow: > # ping 192.168.1.54 > PING 192.168.1.54 (192.168.1.54): 56 data bytes > ^C > --- 192.168.1.54 ping statistics --- > 7 packets transmitted, 0 packets received, 100% packet loss > # > > when I run tcpdump on same system I can see: > > # tcpdump -i any -n icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 > bytes > 12:47:09.671920 IP 1.2.3.4> 192.168.1.54: ICMP echo request, id 8565, > seq 0, length 64 > 12:47:10.672438 IP 1.2.3.4> 192.168.1.54: ICMP echo request, id 8565, > seq 1, length 64 > 12:47:11.672876 IP 1.2.3.4> 192.168.1.54: ICMP echo request, id 8565, > seq 2, length 64 > 12:47:12.673316 IP 1.2.3.4> 192.168.1.54: ICMP echo request, id 8565, > seq 3, length 64 > 12:47:13.673749 IP 1.2.3.4> 192.168.1.54: ICMP echo request, id 8565, > seq 4, length 64 > 12:47:14.674188 IP 1.2.3.4> 192.168.1.54: ICMP echo request, id 8565, > seq 5, length 64 > 12:47:15.674639 IP 1.2.3.4> 192.168.1.54: ICMP echo request, id 8565, > seq 6, length 64 > ^C > 7 packets captured > 7 packets received by filter > 0 packets dropped by kernel > # > > If I understand it correct, I should see there "192.168.2.1> > 192.168.1.54" instead of "1.2.3.4> 192.168.1.54" . > > Also if I run tcpdump on other VPN server, I get no ping at all. > > Here is log with knl set to 2. This is what I got when connection was > established: > > 13[KNL] got SPI c9cc5971 > 13[KNL] adding SAD entry with SPI c9cc5971 and reqid {1} (mark > 0/0x00000000) > 13[KNL] using encryption algorithm AES_CBC with key size 128 > 13[KNL] using integrity algorithm HMAC_SHA1_96 with key size 160 > 13[KNL] using replay window of 32 packets > 13[KNL] adding SAD entry with SPI cec8aa6b and reqid {1} (mark > 0/0x00000000) > 13[KNL] using encryption algorithm AES_CBC with key size 128 > 13[KNL] using integrity algorithm HMAC_SHA1_96 with key size 160 > 13[KNL] using replay window of 32 packets > 13[KNL] adding policy 192.168.2.0/24 === 192.168.1.0/24 out (mark > 0/0x00000000) > 13[KNL] adding policy 192.168.1.0/24 === 192.168.2.0/24 in (mark > 0/0x00000000) > 13[KNL] adding policy 192.168.1.0/24 === 192.168.2.0/24 fwd (mark > 0/0x00000000) > 13[KNL] getting a local address in traffic selector 192.168.2.0/24 > 13[KNL] using host 192.168.2.1 > 13[KNL] using 1.2.3.1 as nexthop to reach 4.3.2.1/32 > 13[KNL] 1.2.3.4 is on interface eth0.2 > 13[KNL] installing route: 192.168.1.0/24 via 1.2.3.1 src 192.168.2.1 dev > eth0.2 > 13[KNL] getting iface index for eth0.2 > 13[KNL] policy 192.168.2.0/24 === 192.168.1.0/24 out (mark > 0/0x00000000) already exists, increasing refcount > 13[KNL] updating policy 192.168.2.0/24 === 192.168.1.0/24 out (mark > 0/0x00000000) > 13[KNL] policy 192.168.1.0/24 === 192.168.2.0/24 in (mark 0/0x00000000) > already exists, increasing refcount > 13[KNL] updating policy 192.168.1.0/24 === 192.168.2.0/24 in (mark > 0/0x00000000) > 13[KNL] policy 192.168.1.0/24 === 192.168.2.0/24 fwd (mark > 0/0x00000000) already exists, increasing refcount > 13[KNL] updating policy 192.168.1.0/24 === 192.168.2.0/24 fwd (mark > 0/0x00000000) > 13[KNL] getting a local address in traffic selector 192.168.2.0/24 > 13[KNL] using host 192.168.2.1 > 13[KNL] using 1.2.3.1 as nexthop to reach 4.3.2.1/32 > 13[KNL] 1.2.3.4 is on interface eth0.2 > 13[IKE] CHILD_SA tva-to-vino{1} established with SPIs c9cc5971_i > cec8aa6b_o and TS 192.168.2.0/24 === 192.168.1.0/24 > 13[KNL] 1.2.3.4 is on interface eth0.2 > 13[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH SA TSi TSr > N(AUTH_LFT) ] > > > On 5/2/2016 11:20, Tobias Brunner wrote: >> Hi Lukas, >> >>> # ip route list table 220 >>> 192.168.1.0/24 via 1.2.3.1 dev eth0.2 proto static src 1.2.3.4 >>> # >>> >>> where 1.2.3.4 is locally attached, publicly reachable IP address and >>> 1.2.3.1 is default gw for this public IP address. >> Looks strange. The source address should be part of the local traffic >> selector (192.168.2.0/24), which 1.2.3.4 is probably not. Please >> increase the log level for the knl subsystem to see what's going on >> during the route/policy installation [1]. >> >> Regards, >> Tobias >> >> [1] https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration >> >> > > _______________________________________________ > Users mailing list > [email protected] > https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
