Racoon vs. OpenSWAN: Configuring IPSEC VPN HOST-TO-SITE Tunnel with Cisco and L2TP over IPSEC for Windows, iOS and Android
Good deeds, dear Habravchane!
In this article, I would like to captivate you with a story about my adventures in search of reliable and secure IPSec connections, where you will find many amazing discoveries and disappointments, riddles and answers, stories of faithful service and treacherous betrayals. So, my dear reader, get ready, start the story.
To the reader who needs urgent help, and not stories about my misfortunes that led to the writing of this topic, I recommend scrolling to the title “Actually Subject”
')
Somewhere about six months ago I needed to raise a server for payment terminals with connection to the payment system via IPSec. My choice fell on Debian Squeeze and KAME ipsec-tools, in common racoon. Oh, and I do not know why my soul became attached to this application. At first, after superficially studying the IPSec theory, I took up the practice:
Rakun successfully downloaded, installed, pulling along a bunch of packages and happily informed me that he was here.
On the other side, his beloved CISCO was waiting, who, however, consistently supported a couple of dozen secure connections, but was looking forward to our hero knocking her, calling PreShared Key and embracing her in the arms of her reliable IPSec channel.
But before that, it was necessary to go through a difficult test, because the strict but fair father of the CISCO, a sysadmin on the other side, did not give access to his ward without successfully passing the test. The conditions of passage were as follows:
To help lovers, it took about a couple of days to create a more or less working config. Finally, love prevailed. One of the problems was reworking configs from the existing site-to-site, I had to strain my brain a little and remember that one host is the same network, only with a subnet mask of 255.255.255.255, that is, / 32.
But the happiness was not long. There was a task to connect client hosts via L2TP over IPSec, and here Rakun could not cope. First, it took an ipsec-tools reassembly operation so that it could support the wildcard (*) for the preshared key, since the IP addresses of the client machines are unknown. This disgrace looked like this:
Banal dependency resolution during assembly required another week of painstaking mana smoking, because it could not go further ./configure. In the end, I came across an article by BenV, which meaningfully said: And you trust your security to these clowns . Without attaching great importance to these words, because the article decided my problem, I successfully assembled, connected and made Raccoon work now in the Road Warrior configuration.
There were no problems with L2TP:
Installed xl2tp and ppp
Configured according to a variety of how-to:
But with ipsec-tools I had to tinker. I will give the working config of the rakun:
But after a week of successful work, the tunnel was suddenly inactive, and the only tool that helped was restart racoon or reboot.
The project was a pilot, a cloud of other things, and, in general, on crutches and patches stretched a couple of months.
Finally, I got around to sorting out the issue thoroughly, and in the hope of bug-fixes and other elusive things, I collected a fresh version of ipsec-tools 0.8.1. And immediately after the start, racoon informed me about a serious illness - the segmentation fault.
I could not bear such a blow. The night did not sleep: I thought how could it be so ...
Waking up in the morning, I drank tea, ate a sandwich and sat down at the computer. Suddenly the thought flashed in my head: OpenSWAN! Ah yes, let's try!
Aptitude cursed that OpenSWAN is not friendly with racoon, and we’ll have to say goodbye to our former friend. Well, it was not, I thought, and confirmed the installation of OpenSWAN.
After a lot of anguish, setting up racoon setting up OpenSWAN turned out to be easier (or maybe I already had some experience):
L2TP settings did not even have to change: it all worked right away. L2TP settings .
And it took me about half an hour against one and a half weeks of torment with racoon.
Unfortunately, as is often the case, capricious Tsisk often quarreled and severed relations with Rakun, but with OpenSWAN (I wonder what gender this application is? Female, then this explains a lot) for the third week steadily and without conflicts and scandals.
If VPN connections with clients are connected, but the hosts within the network are not accessible to each other, then you are missing:
Here you can get settings for iOS and Windows clients.
I would be grateful for the comments, why racoon dropped out in segfault and lost connection after a week of stable work.
Special thanks to the UFO for the invite.
Update:
After 2 months, it still fell, the infection ...
Found on the Openswan forums that dpdaction = restart_by_peer is strongly recommended. Corrected in configs.
Update 2:
As the admin admitted to me on the side of the tsiska, the fall was caused by communication problems on their side.
But this is not easier for me, because the tunnel had to go up.
Found in another how-that forceencaps = yes can help in such cases. Added to config.
Update 3:
Added by:
# / etc / ppp / options:
defaultroute
see comments
In this article, I would like to captivate you with a story about my adventures in search of reliable and secure IPSec connections, where you will find many amazing discoveries and disappointments, riddles and answers, stories of faithful service and treacherous betrayals. So, my dear reader, get ready, start the story.
To the reader who needs urgent help, and not stories about my misfortunes that led to the writing of this topic, I recommend scrolling to the title “Actually Subject”
')
Somewhere about six months ago I needed to raise a server for payment terminals with connection to the payment system via IPSec. My choice fell on Debian Squeeze and KAME ipsec-tools, in common racoon. Oh, and I do not know why my soul became attached to this application. At first, after superficially studying the IPSec theory, I took up the practice:
apt-get install racoon Rakun successfully downloaded, installed, pulling along a bunch of packages and happily informed me that he was here.
On the other side, his beloved CISCO was waiting, who, however, consistently supported a couple of dozen secure connections, but was looking forward to our hero knocking her, calling PreShared Key and embracing her in the arms of her reliable IPSec channel.
But before that, it was necessary to go through a difficult test, because the strict but fair father of the CISCO, a sysadmin on the other side, did not give access to his ward without successfully passing the test. The conditions of passage were as follows:
IKE 3DES HASH SHA-1 Diffie Hellman Grupo 2 Life Time 86400 seconds Authentication by Preshared Key IPSec 3DES Integrity : ESP/SHA1 Mode: Tunel Perfect Forward Secrecy (Active) Lifetime 3600 seconds xxxx - IP , yyyy - IP Cisco zzzz - IP Cisco To help lovers, it took about a couple of days to create a more or less working config. Finally, love prevailed. One of the problems was reworking configs from the existing site-to-site, I had to strain my brain a little and remember that one host is the same network, only with a subnet mask of 255.255.255.255, that is, / 32.
But the happiness was not long. There was a task to connect client hosts via L2TP over IPSec, and here Rakun could not cope. First, it took an ipsec-tools reassembly operation so that it could support the wildcard (*) for the preshared key, since the IP addresses of the client machines are unknown. This disgrace looked like this:
diff -ur a/ipsec-tools-0.7.1/src/racoon/localconf.cb/ipsec-tools-0.7.1/src/racoon/localconf.c --- a/ipsec-tools-0.7.1/src/racoon/localconf.c 2006-09-09 11:22:09.000000000 -0500 +++ b/ipsec-tools-0.7.1/src/racoon/localconf.c 2010-08-06 16:35:18.000000000 -0500 <at> <at> -211,7 +211,8 <at> <at> if (*p == '\0') continue; /* no 2nd parameter */ p--; - if (strncmp(buf, str, len) == 0 && buf[len] == '\0') { + if (strncmp(buf, "*", 2) == 0 || + (strncmp(buf, str, len) == 0 && buf[len] == '\0')) { p++; keylen = 0; Banal dependency resolution during assembly required another week of painstaking mana smoking, because it could not go further ./configure. In the end, I came across an article by BenV, which meaningfully said: And you trust your security to these clowns . Without attaching great importance to these words, because the article decided my problem, I successfully assembled, connected and made Raccoon work now in the Road Warrior configuration.
L2TP settings
There were no problems with L2TP:
Installed xl2tp and ppp
apt-get install xl2tp ppp Configured according to a variety of how-to:
# /etc/xl2tpd/xl2tpd.conf [global] ipsec saref = yes force userspace = yes [lns default] local ip = 10.1.2.1 ip range = 10.1.2.10-10.1.2.254 # refuse pap = yes require authentication = yes ppp debug = yes length bit = yes pppoptfile = /etc/ppp/options # /etc/ppp/options: ms-dns 10.1.2.1 ms-dns 8.8.8.8 require-mschap-v2 asyncmap 0 auth crtscts lock hide-password modem debug name l2tpd defaultroute proxyarp lcp-echo-interval 10 lcp-echo-failure 100 #/etc/ppp/chap-secrets: # Secrets for authentication using CHAP # client server secret IP addresses username * userpass * # . IP addresses , . alvelig 10.1.2.7 alvelig * alvelig 10.1.2.7 But with ipsec-tools I had to tinker. I will give the working config of the rakun:
# /etc/racoon/racoon.conf: path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; # PreShared Keys (. ) path certificate "/etc/racoon/certs"; # IKE Road Warrior remote anonymous { exchange_mode aggressive,main; passive on; proposal_check obey; support_proxy on; nat_traversal on; ike_frag on; dpd_delay 20; proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1024; } proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1024; } } # IPSEC Road Warrior CISCO sainfo anonymous { pfs_group 2; lifetime time 3600 sec; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } # IKE CISCO remote yyyy { exchange_mode main, aggressive; my_identifier address; lifetime time 86400 sec; nat_traversal on; dpd_delay 20; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } # /etc/racoon/psk.txt: # PSK Cisco 200.68.5.131 CiscoPSK # PSK NAT * RoadWarrior # /etc/ipsec-tools.conf #!/usr/sbin/setkey -f # # Flush SAD and SPD flush; spdflush; # Create policies for racoon spdadd xxxx/32 zzzz/32 any -P out ipsec esp/tunnel/xxxx-yyyy/require; spdadd zzzz/32 xxxx/32 any -P in ipsec esp/tunnel/yyyy-xxxx/require; ########################## ## XL2TP ## ########################## spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in ipsec esp/transport//require; spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec esp/transport//require; But after a week of successful work, the tunnel was suddenly inactive, and the only tool that helped was restart racoon or reboot.
The project was a pilot, a cloud of other things, and, in general, on crutches and patches stretched a couple of months.
Finally, I got around to sorting out the issue thoroughly, and in the hope of bug-fixes and other elusive things, I collected a fresh version of ipsec-tools 0.8.1. And immediately after the start, racoon informed me about a serious illness - the segmentation fault.
I could not bear such a blow. The night did not sleep: I thought how could it be so ...
Waking up in the morning, I drank tea, ate a sandwich and sat down at the computer. Suddenly the thought flashed in my head: OpenSWAN! Ah yes, let's try!
Actually a subject
apt-get install openswan Aptitude cursed that OpenSWAN is not friendly with racoon, and we’ll have to say goodbye to our former friend. Well, it was not, I thought, and confirmed the installation of OpenSWAN.
After a lot of anguish, setting up racoon setting up OpenSWAN turned out to be easier (or maybe I already had some experience):
# /etc/ipsec.conf config setup # nat_traversal=yes # NAT conn cisco # forceencaps=yes dpddelay=30 # Dead peer detection - 30 - keep-alive dpdtimeout=120 # dpd 120 , dpdaction=restart_by_peer # # IKE alg 3DES - HASH sha1 - DH group 2 (1024) ike=3des-sha1-modp1024 # IKE lifetime 86400 seconds (24 hours) ikelifetime=86400s # IKE auth method Pre-Shared Key (PSK secret) authby=secret # IPSEC params # OpenSWAN # phase2=esp # by default # phase2=3des-sha1 # by default the same as IKE # IPSec type tunnel type=tunnel # - # IPSEC (key) lifetime salifetime=3600s # Perfect Forward Secrecy PFS group the same as IKE (1024) pfs=yes # Perfect Forward Secrecy #left side (myside) left=xxxx # OpenSWAN side # , IPSec, netmask xxxx/32 leftsubnet=xxxx/32 #net subnet on left side to assign to right side leftnexthop=yyyy # CISCO side #right security gateway (CISCO side) right=yyyy #CISCO side rightsubnet=zzzz/32 #net on right side rightnexthop=xxxx # OpenSWAN side auto=start # Road Warrior conn L2TP authby=secret pfs=no auto=add keyingtries=3 rekey=no ikelifetime=8h keylife=1h type=transport left=xxxx leftprotoport=17/%any # 1701, iOS . %any , : iPad ! right=%any rightprotoport=17/%any compress=no dpddelay=30 dpdtimeout=120 dpdaction=clear # dpdaction=clear , .. ipsec # , , " peer", # , L2TP settings did not even have to change: it all worked right away. L2TP settings .
ipsec setup start ping zzzz 64 bytes from zzzz: icmp_req=1 ttl=254 time=7.53 ms 64 bytes from zzzz: icmp_req=2 ttl=254 time=6.59 ms 64 bytes from zzzz: icmp_req=3 ttl=254 time=6.41 ms 64 bytes from zzzz: icmp_req=4 ttl=254 time=6.77 ms And it took me about half an hour against one and a half weeks of torment with racoon.
Conclusion
Unfortunately, as is often the case, capricious Tsisk often quarreled and severed relations with Rakun, but with OpenSWAN (I wonder what gender this application is? Female, then this explains a lot) for the third week steadily and without conflicts and scandals.
P.S
If VPN connections with clients are connected, but the hosts within the network are not accessible to each other, then you are missing:
echo 1 > /proc/sys/net/ipv4/ip_forward Or watch your iptablesHere you can get settings for iOS and Windows clients.
I would be grateful for the comments, why racoon dropped out in segfault and lost connection after a week of stable work.
Special thanks to the UFO for the invite.
Update:
After 2 months, it still fell, the infection ...
Found on the Openswan forums that dpdaction = restart_by_peer is strongly recommended. Corrected in configs.
Update 2:
As the admin admitted to me on the side of the tsiska, the fall was caused by communication problems on their side.
But this is not easier for me, because the tunnel had to go up.
Found in another how-that forceencaps = yes can help in such cases. Added to config.
Update 3:
Added by:
# / etc / ppp / options:
defaultroute
see comments
Source: https://habr.com/ru/post/177223/
All Articles