Community discussions

MikroTik App
 
apleschu
just joined
Topic Author
Posts: 13
Joined: Fri Oct 22, 2021 2:46 pm

MT IPSec to Sophos IPSec problems

Fri Nov 26, 2021 3:12 pm

we have a tunnel that does create some big headaches and I am trying to determine what I/we can do

One of our customers has a Sophos UT as their IPSec gateway, we have a MT 4011 (7.1rc6, I NEED the fireguard functionality)

We also have fully working IPSec tunnels to a couple other customers, working just as expected. Only the one I am going to describe creates some peculiar problems. I am still hoping someone has had similar problems and can help.

So here is what happens: IF and only IF the Sophos side is being reset the tunnel comes up (Phase 1 is set for 8 hours, Phase 2 for 1 hour) From that reset on the whole connection, both encryption domains, are working just as one would expect. Now at some point (I assume its after the Phase1 renegotions should start) the Tunnel collapses. Since the log lines are all intermixed and I cannot determines exactly which log lines are for which Tunnel I cannot exactly determine when this happens and what is afterwards.
BUT, what I do now that from the point forward when the tunnels collapses I cannot make it come up any more from my side (I am on the MT side of that tunnel), no matter what I do. I have tried to kill connections, I have tried to turn the tunnel off for more than an hour, I have flushed everything nothing helps.
Yet, if the Sophos side issues the reset (whatever that means on the Sophos side, since I cannot look what they are doing) the tunnel immediately comes back online and stays online for what seems to to be the full 8 hours the phase1 ticket is valid.
Has anybody had a similar experience and what did you do to resolve?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: MT IPSec to Sophos IPSec problems

Fri Nov 26, 2021 6:05 pm

Since it is effectively unusable anyway, what I'd do in your situation would be to use another Mikrotik (even a CHR on a free license if you don't have anything else handy) to debug that without other tunnels writing to the same log. And unless your Mikrotik must be the initiator, I'd set it to passive=yes to see whether the Sophos thing keeps trying to re-establish the tunnel or whether it gives up once it fails.

If your 4011 hosts your company's public IP, it is not a big deal to port-forward incoming traffic towards UDP ports 500 and 4500 to the test Mikrotik if they come from the public subnet of the Sophos. It is even possible to make the test Mikrotik think it is running on the public address and forward ESP from the Sophos to it if necessary.
 
apleschu
just joined
Topic Author
Posts: 13
Joined: Fri Oct 22, 2021 2:46 pm

Re: MT IPSec to Sophos IPSec problems

Sat Nov 27, 2021 9:10 am

Unfortunately, yes our side needs to be the initiator and the problem has already reached a level that if I start to mess with other tunnels at this point they would start asking if I lost my mind.

I was/am hoping that MT in their infinite wisdom has a hidden option somewhere to specifically tag log lines according to connection. I can't be the first one having this problem to have more than one tunnel on one router and then being unable to determine which log line belongs to which connection.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: MT IPSec to Sophos IPSec problems

Sat Nov 27, 2021 12:52 pm

our side needs to be the initiator
Sorry for not structuring my thoughts more clearly:
  • when I mentioned setting passive to yes, I had in mind that you'd see what the Sophos is trying to actively do while in that broken state. But if your side must be the initiator, it just means that instead, you have to watch the reaction of the Sophos to Mikrotik's attempts to re-establish the connection from scratch after the one-hour pause you've mentioned (silence or negative response).
  • the above is orthogonal to the other recommendation, to debug this tunnel using another Mikrotik device, which is of course possible even for an initiator, or even simpler to some extent (less action=dst-nat rules to add).

I was/am hoping that MT in their infinite wisdom has a hidden option somewhere to specifically tag log lines according to connection. I can't be the first one having this problem to have more than one tunnel on one router and then being unable to determine which log line belongs to which connection.
You are definitely not the first one, and the idea of tagging log rows per IPsec connection (or SIP call, or whatever similar) is great from the user perspective, but it would require quite a lot of development effort to spend in order to gain a result which only few users would benefit from. So seeing the pile of feature/bugfix requests pending, I cannot imagine any product manager to give any priority to this.


So all in all, no point to wait for Mikrotik R&D to implement tagging of the log rows with active-peer identity and serial number of connection to/from that peer. I'd recommend to take the path I've suggested, i.e. to use a dedicated Mikrotik device to debug the Sophos connection.

Regarding the issue itself, does it indeed fail after Phase 1 expiration (~8h) or already after Phase 2 expiration (~1h)? If after 1h, it could be caused by incompatibility of PFS settings; if after 8h, it is likely some bug in the Phase 1 renegotiation where small configuration adjustments may not have any effect, but changing from IKE(v1) to IKEv2 or vice versa might cause both peers to use different parts of their IPsec code and thus the issue would not pop up. In the past (more than 2 years ago), I've also seen Phase 2 renegotiation to fail between two Mikrotiks with identical settings for IKEv2 connections, it has been quickly fixed as soon as I've provided enough information.

Yet another possibility, although not very likely at first glance, is that some NAT/firewall between the two peer devices goes crazy (been there, seen that) and keeps delivering Mikrotik->Sophos packets somewhere else for as long as the Sophos keeps retrying to send something to the Mikrotik and thus keeps the pinhole alive. So the restart of the Sophos may actually let that external pinhole disappear rather than clean up something in the state of the Sophos itself.
 
apleschu
just joined
Topic Author
Posts: 13
Joined: Fri Oct 22, 2021 2:46 pm

Re: MT IPSec to Sophos IPSec problems

Sat Nov 27, 2021 5:28 pm

Thank you again for your input, I really appreciate it. Come to find out it might have been a problem in 7.1rc6 in my desperation I installed rc7 today (remotely and after a whole lot of backing up) and with great trepidation, but everything went OK and come to find out at least for now the system came back to life. We'll see after 8 hours after Phase runs out.

At the same time I have/had 2 problematic IPSec tunnels, one was renegotiated every 3 minutes (I don't know what is on the other side, that's a different customer, and this one is also now up for 6 hours, and works as expected. So I HOPE there was a small change in the IPSec code that was not in the release notes that made a difference.

I will know tomorrow morning if that was in fact the case. Then the next update (if that works now not before a production release come around) will be fun. I am dreading upgrade day every time.

Who is online

Users browsing this forum: Bing [Bot], fibracapi, GoogleOther [Bot], Kanzler and 78 guests