[Swan] libreswan/racoon interoperability problem with NAT-T
Xinwei Hong
xhong at skytap.com
Fri Apr 7 20:07:20 UTC 2017
Thank you Paul. I tried ikepad=no, it does not work.
Meanwhile, I tried to setup natt between two mathine running libreswan. It
also failed, but probably for different reason.
The log files are here:
https://www.dropbox.com/s/2381ktqrmshp57s/natt1.log?dl=0
https://www.dropbox.com/s/0uzx62mgwq2krgw/natt2.log?dl=0
configs:
one side is nat'ed. 199.204.218.98 nat to 10.0.3.3
config setup
protostack=netkey
plutodebug=all
listen=10.0.3.3
conn conn_natt
authby=secret
left=10.0.3.3
right=199.204.217.159
ike=3des-md5;modp1024
phase2alg=3des-md5;modp1024
ikelifetime=28800s
salifetime=3600s
leftsubnet=10.0.0.0/24
rightsubnet=10.0.1.0/24
type=tunnel
auto=start
on the peer:
config setup
protostack=netkey
plutodebug=all
listen=199.204.217.159
conn conn_vpn-5483483-tunnel
authby=secret
left=199.204.217.159
right=199.204.218.98
ike=3des-md5;modp1024
phase2alg=3des-md5;modp1024
ikelifetime=28800s
salifetime=3600s
conn conn_vpn-5483483-tunnel-VPNRemoteRoutedSubnet-tunnel-10.0.0.0/24
also=conn_vpn-5483483-tunnel
leftsubnet=10.0.1.0/24
rightsubnet=10.0.0.0/24
type=tunnel
auto=start
Some errors I saw are:
reapchild failed with errno=10 No child processes
Apr 7 12:14:07 xenial33 pluto[5964]: | NAT-Traversal: Trying new style
NAT-T
Apr 7 12:14:07 xenial33 pluto[5964]: | NAT-Traversal: ESPINUDP(2) setup
failed for new style NAT-T family IPv4 (errno=95)
Apr 7 12:14:07 xenial33 pluto[5964]: | SPI size: 0 (0x0)
Apr 7 12:14:07 xenial33 pluto[5964]: | Notify Message Type:
INVALID_ID_INFORMATION (0x12)
...
Thanks
Xinwei
On Sun, Apr 2, 2017 at 3:12 PM, Paul Wouters <paul at nohats.ca> wrote:
> On Fri, 31 Mar 2017, Xinwei Hong wrote:
>
> You can try ikepad=no
>
> Other then that, I don't understand what's wrong with racoon.
>
> Paul
>
> Date: Fri, 31 Mar 2017 18:59:18
>> From: Xinwei Hong <xhong at skytap.com>
>> Cc: swan at lists.libreswan.org
>> To: Paul Wouters <paul at nohats.ca>
>> Subject: Re: [Swan] libreswan/racoon interoperability problem with NAT-T
>>
>>
>> Thank you Paul.
>> I added "compress=yes", seems not help. Compression_algorithm is only
>> used in phase 2, right? The
>> failure here is phase 1. Firewall does not like the issue either because
>> packet on UDP 4500 can be seen
>> on both end.
>>
>> I have attached racoon log file. I see:
>>
>> invalid length of payload
>>
>> ERROR: phase1 negotiation failed due to time up.
>> 8c6688cabaaf90ca:a8d8758b59948609
>>
>> ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP
>> 10.2.128.240[0]->10.0.0.1[0]
>>
>>
>> Thanks,
>> Xinwei
>>
>>
>> On Fri, Mar 31, 2017 at 1:53 PM, Paul Wouters <paul at nohats.ca> wrote:
>> On Thu, 30 Mar 2017, Xinwei Hong wrote:
>>
>> [moderator note: please next time post a pointer to a "pastebin" of
>> the
>> log instead of included large log files]
>>
>> I have a VPN setup between libreswan (pluto+netkey) and a
>> racoon
>> (racoon+netkey), the racoon is behind a NAT device. The
>> negotiation somehow
>> failed saying that "NAT-D payload #0 doesn't
>> match"
>>
>>
>> There is not a NAT payload error. Your device has more then one IP
>> address, and it is trying to calculate the payload for both your
>> IP addresses. It notes that 10.0.0.1 does not match. But it also
>> notes that 10.2.128.240 works fine.
>>
>> Your actual problem is:
>>
>> Mar 30 19:47:02 vvr-10 pluto[24271]: vvr-0:
>> "conn_vvr-0-ipsectunnel-0-remote-0" #1246: max number of
>> retransmissions
>> (8) reached STATE_MAIN_I3. Possible authentication
>> failure: no
>> acceptable response to our first encrypted message
>>
>> Your racoon logs will likely have more information in it then your
>> libreswan log, as racoon is the party rejecting the packet.
>>
>> conn conn_vvr-0-ipsectunnel-0
>> authby=secret
>> left=10.2.128.240
>> right=10.2.128.241
>> ike=3des-sha1;modp1024
>> phase2alg=3des-sha1;modp1024
>> leftsubnet=10.100.0.0/24
>> rightsubnet=10.100.1.0/24
>>
>>
>> on racoon, we have racoon.conf
>> # Phase 1 (Main Mode) Configuration
>> remote 10.2.128.240 {
>> exchange_mode main;
>> proposal_check obey;
>> lifetime time 28800 seconds;
>> nat_traversal on;
>> #script "phase1-up.sh" phase1_up;
>> #script "phase1-down.sh" phase1_down;
>> dpd_delay 15; dpd_retry 5; dpd_maxfail 5;
>> proposal {
>> encryption_algorithm 3des;
>> hash_algorithm sha1;
>> dh_group modp1024;
>> authentication_method pre_shared_key;
>> }
>> }
>>
>> # Phase 2 (Quick Mode) Configuration/Proposal (for IPsec SA).
>> sainfo anonymous {
>> encryption_algorithm 3des;
>> authentication_algorithm hmac_sha1;
>> pfs_group modp1024;
>> lifetime time 3600 seconds;
>> compression_algorithm deflate;
>> }
>>
>>
>> The only mismatch I see is for compression. You can try and
>> removing the
>> compression line from racoon, or adding compress=yes to libreswan.
>>
>> Mar 30 19:47:52 testhost-601-1 racoon: ERROR: phase1
>> negotiation failed due to
>> time up. 80b77211a2f1ddba:141872152ca7772f
>>
>>
>> This is odd. Another possibility is that you have firewalled UDP
>> 4500
>> and so the NAT switching from UDP 500 to UDP 4500 is failing?
>>
>> Paul
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170407/f2c8c132/attachment.html>
More information about the Swan
mailing list