[strongSwan] Net-to-Net wrong source IP of VPN server.
Arne Schmid
arne.j.schmid at outlook.com
Tue May 3 14:07:43 CEST 2016
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 'client at vpn.EXMPLE.de'
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, CN=client at vpn.EXMPLE.de'
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, CN=client at vpn.EXMPLE.de"
May 3 14:01:20 05[CFG] certificate "C=CN, O=EXMPLE, CN=client at vpn.EXMPLE.de" 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, CN=client at vpn.EXMPLE.de"
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: tobias at strongswan.org; users at lists.strongswan.org
> From: lukas at 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 at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160503/11755751/attachment-0001.html>
More information about the Users
mailing list