IPsec tunnel for offsire rrepository

[MikaelG]

Hi,

After trying to increase the security on the tunnel set up to our offsite repository I get "channel time out failure" on the first try merging the copied data to a full restore point. It usually succeeds on the second try. When doing a full sync it fails with "peer did not respond in time". What we did was change encryption on the tunnel to DH20 SHA512 etc. so the most secure versions availiable on the 2 firewalls. And I think that might be the cause of these errors. Trying different settings is cumbersome since the jobs take a long time before they run into problems. Does anyone have tips on a good setting that works for them? As I rather not fall back to the old encryption that was pretty weak. Both peers have 1gbit connections so speed shouldn´t be an issue. And the firewalls work fine with other tunnels using the more complex encryption. Only with the Veeam backup copy jobs there is a problem.

Thanks,

Mikael

[EugeneK]

Hi Mikael,

Do you see any events on the firewall side for the periods, when it happens? The encryption level itself should not have affected the way the jobs operate, I suspect there may be tcp timeouts for IPsec tunnels or a potential resources saturation on the endpoint firewalls, which may lead to the packets drop.

[MikaelG]

Hi, I haven't found anything in the firewall logs that could explain it. But I'll check again next week.

[Mike Resseler]

Mikael,

I think you should indeed search in the direction that Eugene is pointing at. How are the time-outs for TCP / UDP connections? I assume that they need to get increased on your firewall. But the problem is that if you increase them and they stay longer open (unless there is a closure confirmation) it can also cause your memory of your firewall to be used completely or the firewall could stop accepting new connections.

From a previous life as a consultant I would check the current connection time-out settings to maybe double it or so...

[MikaelG]

Hi,

I will look into it, but I don´t think firewall timeouts is the issue since it woked perfectly before the encryption change. We did setup a new linux machine (repository) over the tunnel also. My thought now is that it could be SSH time out that causes it. ´The vendow has changed the time out setting now so we´ll se if it helps.

Thanks,

Mikael

[Andreas Neufert]

The default SSHD current allowed connections are pretty low. Maybe this config from one of my tests help:
/etc/ssh/sshd_config
ClientAliveInterval 30
TCPKeepAlive yes
ClientAliveCountMax 99999
MaxSessions 200 <= we limit at the data transport side (current task count at Repository). Limited SSH connections result in job errors.
MaxStartups 100:30:200

[Andreas Neufert]

you can as well "play" with the number of TCP streams in the network throttling settings.