My company has a main office and two branch offices. All three are running XG firewalls with SFOS 18.5.1 MR-1-Build326. The main office connects to the two branch offices via two IPsec site-to-site VPNs. The VPNs are configured using the DefaultHeadOffice and DefaultBranchOffice policies, with RSA keys.
Normally the VPN connections are rock solid -- staying up for weeks or even months at a time. But occasionally we have a power outage at the main office that lasts longer than the batteries in the UPS, and the XG unit shuts down. When the power comes back on, that's when the fun begins.
Upon restoration of power, the cable modem comes back up, the XG boots up, the Internet service comes back on line, and everything works again -- EXCEPT for the VPN connections. Sometimes they come back up too, but sometimes they don't. If they don't, it might be hours later before they finally reconnect. In at least one case, it took longer than a day.
Most of these outages happened when I was unavailable to troubleshoot, and resolved themselves before I had a chance to take a close look at the situation. This week, I finally caught one as it was occurring.
Looking at the branch office system logs first, I saw entries like these:
2021-11-12 01:58:36 IPSec Expire peer did not respond to initial message 177
2021-11-12 01:58:36 IPSec Failed IKE message (EC001F20) retransmission to xx.xx.xx.xx timed out
Those two messages repeated every 2 or 3 minutes. So the branch offices were trying to connect, but not getting a response for some reason.
Next, I looked at the head office system log, and I found messages like this:
2021-11-11 14:24:12 IPSec Failed parsing IKE header from 91.179.112.172[49984] failed
There were hundreds or thousands of these messages, as they were occurring a dozen or more times a minute, going back hours. The really interesting part is that the IP address listed in the message (which I have not obfuscated) is NOT the IP address of either of my branch offices. Someone else was trying to connect to my main office VPN.
Looking back further through the logs, I discovered that the connection attempts were coming from at least a dozen different IP addresses, none of which I recognized. However, the attack only came from one IP at a time. That is, all the error messages would reference a single IP address for several hours, then it would suddenly change to a new IP address. My best guess is that these "rogue" IP addresses were keeping my head office XG unit so busy that the branch offices couldn't get though to it.
I had recently read another post on the Sophos Community, "Best Practice for Site-to-Site Policy-Based IPsec VPN", so I decided to implement some of those changes. I cloned the DefaultHeadOffice and DefaultBranchOffice policies and switched the clones to IKEv2 and made a few other configuration changes. I then modified the VPN connections to use the new IKEv2 policies, and made the same series of changes at all three offices. When I reactivated the updated VPN connections, they immediately connected, and I've had no further problems for about 12 hours now.
So here are my questions: (1) Is this a well-known type of attack? I had never heard of it before. (2) I assume the "rogue" IP addresses are still trying to connect to the head office, but I'm no longer seeing the attempts in the system log (maybe because the main office XG is no longer looking for new connections?). What other configuration changes could or should I make to the XG firewalls to thwart this kind of attack? I'm still pretty new to the XG, so I'm not yet as familiar with all its features as I'd like to be. Any suggestions?
-- Bruce Giles, Sophos XG310 (SFOS 18.5.1 MR-1-Build326)
This thread was automatically locked due to age.