This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Serious problem with IPSec S2S VPN tunnel – XGS with 19.0.x

Hello,

this is not the question. This is description of one problem ... Solution is known but hidden. I decided to retell the story by other words because I still remember tries of angry users lynching me ... :-) Maybe it will help somebody

We are using several Sophos XG and GXS firewalls with VPN tunnels.

For some reason (dynamic routing, simple usage, possibility of sniffing etc.) we prefere encrypted GRE (since older version) and xfrm (since it appeared in services).

Our experience was that encrypted GRE sometimes hangs – indicators of tunnel status are both green at both sides, but data are not going through tunnel. It is not possible to even ping through tunnel to peer. Solution was / is disable and enable tunnel. We transfered most of tunnels with this problem to xfrm and it is OK.

I did upgrade to 19.0.1 (skip of 19.0.0) from 18.5.x and at several places appeared problems with tunnels.

As I wrote – these tunnels were based at xfrm and behaviour was similar as with GRE – both indicators at both sides were OK, but nothing came through tunnels. Solution was to disable and enable tunnel. Does not matted which side it was. But these problems appeared at several tunnels from higher amount.

Relationship of this behaviour with upgrade to 19.0.1 was logical.  But why it happened at a few of tunnels from some amount ? (other bad feature was that it appeared several days after upgrade and with different intensity – sometimes one drop in day, sometimes 3, sometimes no drop; and last day before finding workaround it was each nearly 20 minutes; if you try to ask why we did not open support case, answer is simple – we opened it ...).

After some investigations we recognized, that it happens only in case when at at least one side of tunnel XGS is used.

I tried to google, but maybe made bad question. My colleague was happier. He found this discussion :

Version 19.0.0GA Breaking IPSEC VPN's - Discussions - Sophos Firewall - Sophos Community

 

There is workaround with switching off hardware acceleration of IPSec encryption. Here is set of commands (via 4.  Device Console)

system ipsec-acceleration show

system ipsec-acceleration disable

 system ipsec-acceleration enable

Problem should be solved in 19.0.2.

It is 4th day since applying of workaround with no dropout.

Have a nice day,

Petr



This thread was automatically locked due to age.
Parents
  • Hi Petr,
    Do you have GRO and NAT-t on?

    There is a known issue with 19.0.MR1 with that combination when ipsec acceleration is on (it is fixed in 19.0.MR2).

    As a workaround, you can disable GRO (and have things work with ipsec acceleration on as well) as a two step process:
    Disable it on the parent netdev (oct0` on 1US/1UL/2Ua devices and `oct0, oct1` on 2Ub)
    ethtool -K oct0 gro off
    and then disable on the relevant physical port:
    ethtool -K PortXYZ gro off (replace PortXYZ with whatever port is applicable)

    Thanks

Reply
  • Hi Petr,
    Do you have GRO and NAT-t on?

    There is a known issue with 19.0.MR1 with that combination when ipsec acceleration is on (it is fixed in 19.0.MR2).

    As a workaround, you can disable GRO (and have things work with ipsec acceleration on as well) as a two step process:
    Disable it on the parent netdev (oct0` on 1US/1UL/2Ua devices and `oct0, oct1` on 2Ub)
    ethtool -K oct0 gro off
    and then disable on the relevant physical port:
    ethtool -K PortXYZ gro off (replace PortXYZ with whatever port is applicable)

    Thanks

Children
  • Hello,

    thank you for reaction. Unfortunately I do not know what is gro :-( Can you insert of explanation of it (reference for some article ?)

    But disabling of acceleration solved the problem. No problem with this. CPU is OK after that. There is not such heavy load to have to use acceleration.

    I saw usage of oct0 in sniffing. It was strange. I tried to sniff traffic at public interface (tcpdump -i Port2), but I saw only incoming traffic.

    After that I changed sniffing to tcpdump -i any and I saw returning traffic but with source interface oct0 which is fast path.

    Best regards,

    Petr