IpSec- Cyberoam UTM StrongSwan router (Debian): the pair can not be reached

I have a problem with the creation of the IpSec connection between the Cyberoam UTM router and the Debian server. On the Debian side, I'm using the StrongSwan package to create the connection.

So far, I created the tunnel, the tunnel is active and running, but I can not ping the host from either end.

In Cyberoam there are LAN-VPN and VPN-LAN rules that allow everything to anyone. OF Cource in Cyberoam I have specified local and remote subnets in IpSec connection.

Look in these configurations please:

root @ debian: ~ # cat /etc/ipsec.conf
# Basic configuration
configured configuration
charondebug = "all"
uniqueids = yes
strictcrlpolicy = no

# connection to NMS
conn Shentel-a-NMS
authby = psk
keyexchange = ikev1
left = 91.217.40.510
leftid=shentel@norwegian.pl
leftsubnet = 192.168.5.0 / 24
right = 91.217.40.509
rightsubnet = 192.168.0.0 / 24
rightid=nms@norwegian.pl
ike = aes128-sha2_256-modp1024
esp = aes128-sha2_256-modp1024
keyingtries = 10
ikelifetime = 1h
Life time = 8h
dpddelay = 30
dpdtimeout = 600
dpdaction = restart
auto = start

root @ debian: ~ # tail -f / var / log / syslog
Nov 12 00:06:30 debian charon: 04[IKE] sending DPD request
Nov 12 00:06:30 debian charon: 04[ENC] generating the request INFORMATIONAL_V1 2849988837 [ HASH N(DPD) ]
Nov 12 00:06:30 debian charon: 04[NET] Shipping package: from 91.217.40.510[500] to 91.217.40.509[500] (108 bytes)
Nov 12 00:06:30 debian charon: 10[NET] Package received: from 91.217.40.509[500] to 91.217.40.510[500] (108 bytes)
Nov 12 00:06:30 debian charon: 10[ENC] INFORMATIONAL_V1 request analyzed 260595232 [ HASH N(DPD_ACK) ]

root @ debian: ~ # ipsec statusall
State of the charon IKE daemon (strongSwan 5.5.1, Linux 4.9.0-8-amd64, x86_64):
uptime: 5 minutes, from November 11 23:17:31 2018
malloc: sbrk 2568192, mmap 0, used 426592, free 2141600
working threads: 11 of 16 inactive, work 5/0/0/0, job queue: 0/0/0/0, programmed: 15
plugins loaded: charon aes rc2 sha2 sha1 md5 random nonce x509 revocation restrictions pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink capture socket-default stamp seal stamp attached
Listening IP addresses:
192.168.5.2
91.217.40.510
10.8.0.1
Connections:
Shentel-to-NMS: 91.217.40.510 ... 91.217.40.509 IKEv1, dpddelay = 30s
Shentel-to-NMS: local: [shentel@norwegian.pl] uses pre-shared key authentication
Shentel-to-NMS: remote [nms@norwegian.pl] uses pre-shared key authentication
Shentel-to-NMS: child: 192.168.5.0/24 === 192.168.0.0/24 TUNNEL, dpdaction = restart
Security associations (1 up, 0 connecting):
Shentel-to-NMS[2]: ESTABLISHED 4 minutes ago, 91.217.40.510[shentel@norwegian.pl]... 91.217.40.509[nms@norwegian.pl]
Shentel-to-NMS[2]: IKEv1 SPIs: 601b0505e16e426f_i 08a7e4daedf459f6_r *, pre-shared key re-authentication in 45 minutes
Shentel-to-NMS[2]: IKE Proposal: AES_CBC_128 / HMAC_SHA2_256_128 / PRF_HMAC_SHA2_256 / MODP_1024
Shentel-to-NMS {1}: REKEYED, TUNNEL, reqid 1, expires in 7 hours
Shentel-to-NMS {1}: 192.168.5.0/24 === 192.168.0.0/24
Shentel-to-NMS {2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c0c08062_i 7b17b7fc_o
Shentel-to-NMS {2}: AES_CBC_128 / HMAC_SHA2_256_128 / MODP_1024, 0 bytes_i, 840 bytes_o (10 pkts ago, 254s), rescheduled in 7 hours
Shentel-to-NMS {2}: 192.168.5.0/24 === 192.168.0.0/24

When I want to verify with which gateway my connection to go to my pair, I only get my interface with the default route:

root @ debian: ~ # ip route show to match 192.168.0.1
default dev ppp0 scope of link
root @ debian: ~ # route -n
Core IP routing table
Destination Gateway Genmask Flags Metric Ref. Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

And I can not ping my Cyberoam:

root @ debian: ~ # ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56 (84) bytes of data.
^ C
--- 192.168.0.1 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7166 ms

root @ debian: ~ # host 192.168.0.1
Host 1.0.168.192.in-addr.arpa. not found: 3 (NXDOMAIN)

From Cyberoam I can not ping my Debian either.
What did I miss in that configuration?