Once again about IPSec, racoon and stereotypical thinking
The reason for writing this post was an article I read today sharptop Habrayuzer . Just started writing a comment, but it turned out to be very long, so: the tale of how we exposed the raccoon.
When we opened a retail network, the stores were tied to the head in exactly the same way: FreeBSD 7.0 + IPSec + some kind of router-support-ipachek . Initially, the choice fell on 804 D-Link, but it didn’t go with it, the test sample showed at least 400ms of ping via an encrypted channel, which was, for obvious reasons, absolutely unacceptable (it was possible that the device was defective, now we don’t find out then lost). As a result, they began to acquire 3COM OfficeConnect, they gave a normal ping. Only one thing was depressing: the tunnels were filled up with enviable regularity, and what we did not do, they did not want to reconnect automatically. Being firmly convinced that BSD is infallible and the power of open source, 3COM was blamed, of course, and the transfer to LinkSys devices confirmed this: the dumps on linksys were much less, unfortunately, finding them was problematic, because by that time they had already sold to tsiska, and the release of those models were discontinued - wool in warehouses across the country.
When the number of connection points increased to 20, it was no longer tolerable, the techie spent all morning only raising the tunnels manually, and in many cases the reconnect button did not help, the end devices hung in the negotiating state, and only the device reboot was rescued. Smoking of rakun logs did not shed any light on the essence of the problem. As a result, suspicions began to arise that the problem was still in the central office. We took a cheap D-Link device from the DFL-260 (I know, I can’t stand it myself, but for the test) to use it as an entry point to the office. What was a surprise when the dumps of the channels stopped a little more than completely. During the month of work (the test period) in the working mode, something was recorded about 3 or 4 blades of the channels (which it was necessary to interfere with). The retail is happy, the techie took upthe cable crimping and the installation of windows with other interesting and intelligent tasks, everyone is happy. As it turned out, “it wasn’t the case of the reel” (end devices), but precisely in ipsec-tools aka racoon (well, either we prepared it wrong, but that’s really bad, I’m not a special specialist in raccoon cooking). Needless to say, we bought the DFL-260 and launched it in combat mode, since it cost 12t.r. everything and, by the way, DI-804HV work fine with him. Now there are 28 connection points, there are no problems either - no more than two or three tunnel hangs per month. By the way, the hint: for the DFL-260, on the Internet you can find the bourgeois firmware, which includes the unlawful 3DES cryptoalgorithms of the type not allowed in the Russian Federation.
')
What did I want to say to all of them ?! Sometimes blind faith (in this case in BSD and its ports) can spoil your life in order. If there is a problem - you need to check from both ends, so that if someone came across such a rake, try shifting the traffic encryption and routing function in the central office to a specially trained device, perhaps this will add stability to your system.
When we opened a retail network, the stores were tied to the head in exactly the same way: FreeBSD 7.0 + IPSec + some kind of router-support-ipachek . Initially, the choice fell on 804 D-Link, but it didn’t go with it, the test sample showed at least 400ms of ping via an encrypted channel, which was, for obvious reasons, absolutely unacceptable (it was possible that the device was defective, now we don’t find out then lost). As a result, they began to acquire 3COM OfficeConnect, they gave a normal ping. Only one thing was depressing: the tunnels were filled up with enviable regularity, and what we did not do, they did not want to reconnect automatically. Being firmly convinced that BSD is infallible and the power of open source, 3COM was blamed, of course, and the transfer to LinkSys devices confirmed this: the dumps on linksys were much less, unfortunately, finding them was problematic, because by that time they had already sold to tsiska, and the release of those models were discontinued - wool in warehouses across the country.
When the number of connection points increased to 20, it was no longer tolerable, the techie spent all morning only raising the tunnels manually, and in many cases the reconnect button did not help, the end devices hung in the negotiating state, and only the device reboot was rescued. Smoking of rakun logs did not shed any light on the essence of the problem. As a result, suspicions began to arise that the problem was still in the central office. We took a cheap D-Link device from the DFL-260 (I know, I can’t stand it myself, but for the test) to use it as an entry point to the office. What was a surprise when the dumps of the channels stopped a little more than completely. During the month of work (the test period) in the working mode, something was recorded about 3 or 4 blades of the channels (which it was necessary to interfere with). The retail is happy, the techie took up
')
What did I want to say to all of them ?! Sometimes blind faith (in this case in BSD and its ports) can spoil your life in order. If there is a problem - you need to check from both ends, so that if someone came across such a rake, try shifting the traffic encryption and routing function in the central office to a specially trained device, perhaps this will add stability to your system.
Source: https://habr.com/ru/post/137735/
All Articles