IPSec tunnel causes huge packets lost when pinging gateway and other machines

My Ubuntu machine is 10.0.0.15, my Windows machine is 10.0.0.10. My gateway, that routes the Internet traffic to the LAN is 10.0.0.1.

When I ping the gateway from my Windows machine everything is fine - I get every single packet back. Same holds true, when I ping the Ubuntu machine from the Windows machine. However, when I ping the gateway from Ubuntu machine around 80% of packets are lost:

~# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=0.460 ms
64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=0.464 ms
64 bytes from 10.0.0.1: icmp_seq=30 ttl=64 time=0.477 ms
64 bytes from 10.0.0.1: icmp_seq=77 ttl=64 time=0.498 ms
64 bytes from 10.0.0.1: icmp_seq=91 ttl=64 time=0.452 ms
64 bytes from 10.0.0.1: icmp_seq=92 ttl=64 time=0.690 ms
64 bytes from 10.0.0.1: icmp_seq=94 ttl=64 time=0.539 ms
64 bytes from 10.0.0.1: icmp_seq=95 ttl=64 time=0.445 ms
64 bytes from 10.0.0.1: icmp_seq=96 ttl=64 time=0.541 ms
64 bytes from 10.0.0.1: icmp_seq=98 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=99 ttl=64 time=1.40 ms
64 bytes from 10.0.0.1: icmp_seq=103 ttl=64 time=0.577 ms
64 bytes from 10.0.0.1: icmp_seq=106 ttl=64 time=0.535 ms
64 bytes from 10.0.0.1: icmp_seq=107 ttl=64 time=0.490 ms
64 bytes from 10.0.0.1: icmp_seq=109 ttl=64 time=0.477 ms
64 bytes from 10.0.0.1: icmp_seq=110 ttl=64 time=0.627 ms
64 bytes from 10.0.0.1: icmp_seq=111 ttl=64 time=0.563 ms
64 bytes from 10.0.0.1: icmp_seq=114 ttl=64 time=0.467 ms
64 bytes from 10.0.0.1: icmp_seq=115 ttl=64 time=0.535 ms
64 bytes from 10.0.0.1: icmp_seq=137 ttl=64 time=0.479 ms
64 bytes from 10.0.0.1: icmp_seq=138 ttl=64 time=0.455 ms
64 bytes from 10.0.0.1: icmp_seq=142 ttl=64 time=0.548 ms
64 bytes from 10.0.0.1: icmp_seq=143 ttl=64 time=0.448 ms
64 bytes from 10.0.0.1: icmp_seq=144 ttl=64 time=0.470 ms
64 bytes from 10.0.0.1: icmp_seq=147 ttl=64 time=0.545 ms
64 bytes from 10.0.0.1: icmp_seq=149 ttl=64 time=0.557 ms
64 bytes from 10.0.0.1: icmp_seq=152 ttl=64 time=0.547 ms
64 bytes from 10.0.0.1: icmp_seq=153 ttl=64 time=0.476 ms
64 bytes from 10.0.0.1: icmp_seq=179 ttl=64 time=0.472 ms
64 bytes from 10.0.0.1: icmp_seq=180 ttl=64 time=0.854 ms
64 bytes from 10.0.0.1: icmp_seq=188 ttl=64 time=0.494 ms
64 bytes from 10.0.0.1: icmp_seq=190 ttl=64 time=0.556 ms
64 bytes from 10.0.0.1: icmp_seq=192 ttl=64 time=0.499 ms
64 bytes from 10.0.0.1: icmp_seq=193 ttl=64 time=0.482 ms
^C
--- 10.0.0.1 ping statistics ---
194 packets transmitted, 34 received, 82% packet loss, time 197372ms
rtt min/avg/max/mdev = 0.445/0.546/1.404/0.171 ms

Same thing happens when I ping any IP address on the Internet (== through the gateway). However, if I ping any other machine on the LAN, then everything is fine (for example the Windows machine).

This has not always been the case. I lately configured an IPSec tunnel, so it may be the cause. However, even with the IPSec tunnel stopped I experience the same issues.

I checked the routing and it does not behave as I would expect it.

Traceroute to another machine in the LAN looks fine:

~# traceroute 10.0.0.7
traceroute to 10.0.0.7 (10.0.0.7), 64 hops max
  1   10.0.0.7  0.173ms  0.115ms  0.180ms

Traceroute to the gateway does not look fine (had to CTRL+C - it was stuck for too long):

~# traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 64 hops max
^C

Routing table looks good:

~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    100    0        0 enp5s0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp5s0
10.0.0.1        0.0.0.0         255.255.255.255 UH    100    0        0 enp5s0

EDIT: I already know the issue is caused by the tunnel. When I disable the service (sudo systemctl disable strongswan) and reboot the computer pinging works properly. If I then manually start the tunnel (ipsec start) pinging does not work (works in a way described above). If I then stop the tunnel (ipsec stop) it still won't change anything. I need to reboot the computer to fix it.

My IPSec config is:

# ipsec.conf - strongSwan IPsec configuration file

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn my-tunnel
        type=tunnel
        keyexchange=ikev1
        authby=secret
        left=%defaultroute
        leftid=Y.Y.Y.Y
        leftsubnet=10.0.0.0/24
        right=X.X.X.X
        rightsubnet=192.168.0.0/24
        ike=aes256-sha1-modp2048!
        esp=aes256-sha1-modp2048!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        auto=start

Do you have any suggestions where I could have a look and possibly fix the issue?

EDIT2: (as requested by Kevin K. in the comments)

Keep in mind that X.X.X.X is a remote public IP address, that I replaced myself.

~# ip xfrm state
src 10.0.0.15 dst X.X.X.X
        proto esp spi 0xc44dd838 reqid 1 mode tunnel
        replay-window 0 flag af-unspec
        mark 0x64/0xffffffff
        auth-trunc hmac(sha1) 0x951ac2ff6fadcd180b86e91ddf850c96f9e09ec2 96
        enc cbc(aes) 0x0b17feeeafb55e1693c1e1c3f8d59b3a1d2c5470e4fc7580b0887e0a8beb504d
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src X.X.X.X dst 10.0.0.15
        proto esp spi 0xc364db19 reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0x00b17673c57fac4957123718d046578689edb07a 96
        enc cbc(aes) 0xedd573110a33a7ac100372fa605514703b0f9954b33a3780dd97ee8e8ac32fe5
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

~# ip xfrm policy
src 10.0.0.0/24 dst 192.168.0.0/24
        dir out priority 376959
        mark 0x64/0xffffffff
        tmpl src 10.0.0.15 dst X.X.X.X
                proto esp spi 0xc44dd838 reqid 1 mode tunnel
src 192.168.0.0/21 dst 10.0.0.0/24
        dir fwd priority 376959
        mark 0x64/0xffffffff
        tmpl src X.X.X.X dst 10.0.0.15
                proto esp reqid 1 mode tunnel
src 192.168.0.0/21 dst 10.0.0.0/24
        dir in priority 376959
        mark 0x64/0xffffffff
        tmpl src X.X.X.X dst 10.0.0.15
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0

I decided to let ping go for some time. It looks like I receive response for a second or so and then it stops again. In the below example I am sending 10 packets per second (-i 0.1). You can distinguish the consecutive packets by looking at icmp_seq parameter.

root@phenom:~# ping 10.0.0.1 -i 0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=656 ttl=64 time=0.572 ms
64 bytes from 10.0.0.1: icmp_seq=657 ttl=64 time=0.501 ms
64 bytes from 10.0.0.1: icmp_seq=658 ttl=64 time=0.518 ms
64 bytes from 10.0.0.1: icmp_seq=659 ttl=64 time=0.464 ms
64 bytes from 10.0.0.1: icmp_seq=660 ttl=64 time=0.491 ms
64 bytes from 10.0.0.1: icmp_seq=661 ttl=64 time=0.561 ms
64 bytes from 10.0.0.1: icmp_seq=662 ttl=64 time=0.571 ms
64 bytes from 10.0.0.1: icmp_seq=663 ttl=64 time=0.545 ms
64 bytes from 10.0.0.1: icmp_seq=664 ttl=64 time=0.584 ms
64 bytes from 10.0.0.1: icmp_seq=665 ttl=64 time=0.549 ms
64 bytes from 10.0.0.1: icmp_seq=666 ttl=64 time=0.564 ms
64 bytes from 10.0.0.1: icmp_seq=667 ttl=64 time=0.539 ms
64 bytes from 10.0.0.1: icmp_seq=668 ttl=64 time=0.587 ms
64 bytes from 10.0.0.1: icmp_seq=669 ttl=64 time=0.531 ms
64 bytes from 10.0.0.1: icmp_seq=670 ttl=64 time=0.832 ms
64 bytes from 10.0.0.1: icmp_seq=671 ttl=64 time=0.903 ms
64 bytes from 10.0.0.1: icmp_seq=747 ttl=64 time=0.511 ms
64 bytes from 10.0.0.1: icmp_seq=748 ttl=64 time=0.483 ms
64 bytes from 10.0.0.1: icmp_seq=749 ttl=64 time=0.472 ms
64 bytes from 10.0.0.1: icmp_seq=914 ttl=64 time=0.553 ms
64 bytes from 10.0.0.1: icmp_seq=915 ttl=64 time=0.568 ms
64 bytes from 10.0.0.1: icmp_seq=916 ttl=64 time=0.553 ms
64 bytes from 10.0.0.1: icmp_seq=917 ttl=64 time=0.589 ms
64 bytes from 10.0.0.1: icmp_seq=918 ttl=64 time=0.556 ms
64 bytes from 10.0.0.1: icmp_seq=919 ttl=64 time=0.573 ms
64 bytes from 10.0.0.1: icmp_seq=920 ttl=64 time=0.574 ms
64 bytes from 10.0.0.1: icmp_seq=921 ttl=64 time=0.556 ms
64 bytes from 10.0.0.1: icmp_seq=922 ttl=64 time=0.551 ms
64 bytes from 10.0.0.1: icmp_seq=923 ttl=64 time=0.607 ms
64 bytes from 10.0.0.1: icmp_seq=934 ttl=64 time=0.848 ms
64 bytes from 10.0.0.1: icmp_seq=935 ttl=64 time=0.555 ms
64 bytes from 10.0.0.1: icmp_seq=936 ttl=64 time=1.00 ms
64 bytes from 10.0.0.1: icmp_seq=937 ttl=64 time=0.586 ms
64 bytes from 10.0.0.1: icmp_seq=938 ttl=64 time=0.566 ms
64 bytes from 10.0.0.1: icmp_seq=939 ttl=64 time=0.495 ms
64 bytes from 10.0.0.1: icmp_seq=940 ttl=64 time=0.551 ms
64 bytes from 10.0.0.1: icmp_seq=941 ttl=64 time=0.456 ms
64 bytes from 10.0.0.1: icmp_seq=953 ttl=64 time=0.453 ms
64 bytes from 10.0.0.1: icmp_seq=954 ttl=64 time=0.478 ms
64 bytes from 10.0.0.1: icmp_seq=955 ttl=64 time=0.567 ms
64 bytes from 10.0.0.1: icmp_seq=956 ttl=64 time=0.585 ms
64 bytes from 10.0.0.1: icmp_seq=957 ttl=64 time=0.488 ms
64 bytes from 10.0.0.1: icmp_seq=958 ttl=64 time=0.586 ms
64 bytes from 10.0.0.1: icmp_seq=959 ttl=64 time=0.486 ms
64 bytes from 10.0.0.1: icmp_seq=960 ttl=64 time=0.543 ms
64 bytes from 10.0.0.1: icmp_seq=961 ttl=64 time=0.442 ms
64 bytes from 10.0.0.1: icmp_seq=962 ttl=64 time=0.443 ms
64 bytes from 10.0.0.1: icmp_seq=963 ttl=64 time=0.528 ms
64 bytes from 10.0.0.1: icmp_seq=964 ttl=64 time=0.475 ms
64 bytes from 10.0.0.1: icmp_seq=965 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=966 ttl=64 time=0.839 ms
64 bytes from 10.0.0.1: icmp_seq=967 ttl=64 time=0.461 ms
64 bytes from 10.0.0.1: icmp_seq=968 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=969 ttl=64 time=0.474 ms
64 bytes from 10.0.0.1: icmp_seq=970 ttl=64 time=0.547 ms
64 bytes from 10.0.0.1: icmp_seq=971 ttl=64 time=0.837 ms
64 bytes from 10.0.0.1: icmp_seq=972 ttl=64 time=18.6 ms
^C
--- 10.0.0.1 ping statistics ---
1174 packets transmitted, 57 received, 95% packet loss, time 121969ms
rtt min/avg/max/mdev = 0.442/0.883/18.628/2.374 ms