<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>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] <winCert|1> selected peer config 'winCert'
May  3 14:01:19 12[IKE] <winCert|1> initiating EAP-Identity request
May  3 14:01:19 12[IKE] <winCert|1> processing INTERNAL_IP4_ADDRESS attribute
May  3 14:01:19 12[IKE] <winCert|1> processing INTERNAL_IP4_DNS attribute
May  3 14:01:19 12[IKE] <winCert|1> processing INTERNAL_IP4_NBNS attribute
May  3 14:01:19 12[IKE] <winCert|1> processing INTERNAL_IP4_SERVER attribute
May  3 14:01:19 12[IKE] <winCert|1> processing INTERNAL_IP6_ADDRESS attribute
May  3 14:01:19 12[IKE] <winCert|1> processing INTERNAL_IP6_DNS attribute
May  3 14:01:19 12[IKE] <winCert|1> processing INTERNAL_IP6_SERVER attribute
May  3 14:01:19 12[IKE] <winCert|1> peer supports MOBIKE
May  3 14:01:19 12[IKE] <winCert|1> authentication of 'C=CN, O=EXMPLE, CN=vpn.EXMPLE.de' (myself) with RSA signature successful
May  3 14:01:19 12[IKE] <winCert|1> sending end entity cert "C=CN, O=EXMPLE, CN=vpn.EXMPLE.de"
May  3 14:01:20 13[IKE] <winCert|1> received EAP identity 'client@vpn.EXMPLE.de'
May  3 14:01:20 13[TLS] <winCert|1> 33 supported TLS cipher suites:
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_AES_128_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_AES_256_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_3DES_EDE_CBC_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_NULL_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_NULL_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_NULL_SHA
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_NULL_SHA256
May  3 14:01:20 13[TLS] <winCert|1>   TLS_RSA_WITH_NULL_MD5
May  3 14:01:20 13[TLS] <winCert|1> sending EAP_TLS start packet (6 bytes)
May  3 14:01:20 13[IKE] <winCert|1> initiating EAP_TLS method (id 0x07)
May  3 14:01:20 14[TLS] <winCert|1> processing TLS Handshake record (169 bytes)
May  3 14:01:20 14[TLS] <winCert|1> received TLS ClientHello handshake (165 bytes)
May  3 14:01:20 14[TLS] <winCert|1> received TLS 'status request' extension
May  3 14:01:20 14[TLS] <winCert|1> received TLS 'elliptic curves' extension
May  3 14:01:20 14[TLS] <winCert|1> received TLS 'ec point formats' extension
May  3 14:01:20 14[TLS] <winCert|1> received TLS 'signature algorithms' extension
May  3 14:01:20 14[TLS] <winCert|1> received TLS '(35)' extension
May  3 14:01:20 14[TLS] <winCert|1> received TLS '(23)' extension
May  3 14:01:20 14[TLS] <winCert|1> received TLS 'renegotiation info' extension
May  3 14:01:20 14[TLS] <winCert|1> received 30 TLS cipher suites:
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_AES_256_GCM_SHA384
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_AES_128_GCM_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_AES_256_CBC_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_AES_128_CBC_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_AES_256_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_3DES_EDE_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_RC4_128_SHA
May  3 14:01:20 14[TLS] <winCert|1>   TLS_RSA_WITH_RC4_128_MD5
May  3 14:01:20 14[TLS] <winCert|1> negotiated TLS version TLS 1.2 with suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
May  3 14:01:20 14[TLS] <winCert|1> sending TLS ServerHello handshake (38 bytes)
May  3 14:01:20 14[TLS] <winCert|1> sending TLS server certificate 'C=CN, O=EXMPLE, CN=vpn.EXMPLE.de'
May  3 14:01:20 14[TLS] <winCert|1> sending TLS Certificate handshake (853 bytes)
May  3 14:01:20 14[TLS] <winCert|1> selected ECDH group SECP256R1
May  3 14:01:20 14[TLS] <winCert|1> created signature with SHA256/RSA
May  3 14:01:20 14[TLS] <winCert|1> sending TLS ServerKeyExchange handshake (329 bytes)
May  3 14:01:20 14[TLS] <winCert|1> sending TLS cert request for 'C=CN, O=EXMPLE, CN=EXMPLE ca'
May  3 14:01:20 14[TLS] <winCert|1> sending TLS CertificateRequest handshake (87 bytes)
May  3 14:01:20 14[TLS] <winCert|1> sending TLS ServerHelloDone handshake (0 bytes)
May  3 14:01:20 14[TLS] <winCert|1> sending TLS Handshake record (1327 bytes)
May  3 14:01:20 14[TLS] <winCert|1> sending EAP_TLS first fragment (512 bytes)
May  3 14:01:20 15[TLS] <winCert|1> received EAP_TLS acknowledgement packet
May  3 14:01:20 15[TLS] <winCert|1> sending EAP_TLS further fragment (512 bytes)
May  3 14:01:20 16[TLS] <winCert|1> received EAP_TLS acknowledgement packet
May  3 14:01:20 16[TLS] <winCert|1> sending EAP_TLS final fragment (330 bytes)
May  3 14:01:20 05[TLS] <winCert|1> processing TLS Handshake record (1206 bytes)
May  3 14:01:20 05[TLS] <winCert|1> received TLS Certificate handshake (868 bytes)
May  3 14:01:20 05[TLS] <winCert|1> received TLS peer certificate 'C=CN, O=EXMPLE, CN=client@vpn.EXMPLE.de'
May  3 14:01:20 05[TLS] <winCert|1> received TLS ClientKeyExchange handshake (66 bytes)
May  3 14:01:20 05[TLS] <winCert|1> received TLS CertificateVerify handshake (260 bytes)
May  3 14:01:20 05[CFG] <winCert|1>   using certificate "C=CN, O=EXMPLE, CN=client@vpn.EXMPLE.de"
May  3 14:01:20 05[CFG] <winCert|1>   certificate "C=CN, O=EXMPLE, CN=client@vpn.EXMPLE.de" key: 2048 bit RSA
May  3 14:01:20 05[CFG] <winCert|1>   using trusted ca certificate "C=CN, O=EXMPLE, CN=EXMPLE ca"
May  3 14:01:20 05[CFG] <winCert|1> checking certificate status of "C=CN, O=EXMPLE, CN=client@vpn.EXMPLE.de"
May  3 14:01:20 05[CFG] <winCert|1> ocsp check skipped, no ocsp found
May  3 14:01:20 05[CFG] <winCert|1> certificate status is not available
May  3 14:01:20 05[CFG] <winCert|1>   certificate "C=CN, O=EXMPLE, CN=EXMPLE ca" key: 2048 bit RSA
May  3 14:01:20 05[CFG] <winCert|1>   reached self-signed root ca with a path length of 0
May  3 14:01:20 05[TLS] <winCert|1> verified signature with SHA1/RSA
May  3 14:01:20 05[TLS] <winCert|1> processing TLS ChangeCipherSpec record (1 bytes)
May  3 14:01:20 05[TLS] <winCert|1> processing TLS Handshake record (64 bytes)
May  3 14:01:20 05[TLS] <winCert|1> TLS record too short to verify MAC
May  3 14:01:20 05[TLS] <winCert|1> sending fatal TLS alert 'bad record mac'
May  3 14:01:20 05[TLS] <winCert|1> sending TLS Alert record (2 bytes)
May  3 14:01:20 05[TLS] <winCert|1> sending EAP_TLS packet (17 bytes)
May  3 14:01:20 10[TLS] <winCert|1> received EAP_TLS acknowledgement packet
May  3 14:01:20 10[IKE] <winCert|1> EAP method EAP_TLS failed for peer 10.145.250.86
May  3 14:01:20 10[IKE] <winCert|1> IKE_SA winCert[1] state change: CONNECTING => DESTROYING

Thanks,
Arne

> To: tobias@strongswan.org; users@lists.strongswan.org
> From: lukas@hejmal.eu
> 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
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
                                          </div></body>
</html>