Problem with connecting IPSec IKEv2 from Ubuntu 18.04 - networking

Question

There is a computer with Ubuntu 18.04 it is located behind the NAT router and receives the address in the subnet 192.168.1.0/24. For example 192.168.1.11
I connect from this computer to the VPN server using the IPSec IKEv2 protocol but neither systemctl start strongswan nor ipsec start do not raise the connection, I'm can connect in only one way:
sudo charon-cmd --cert ca-cert.pem --host vpn_domain_or_IP --identity your_username
After connecting I get the address from the NAT subnet on the VPN server 10.10.10.0/24 for example 10.10.10.11 VPN works and all traffic goes through the tunnel. But the connection to the local network completely disappears, requests from subnet 192.168.1.0/24 to address 192.168.1.11 and from my computer to any of the subnet addresses 192.168.1.0/24 do not pass
Output ip a:
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 18:d6:c7:14:ff:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.11/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 562sec preferred_lft 562sec
15: ipsec0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 10.10.10.11/32 scope global ipsec0
valid_lft forever preferred_lft forever
inet6 fe80::5b2:78:42:d7/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Ping
:~# ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.071 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 192.168.1.11: icmp_seq=3 ttl=64 time=0.069 ms
64 bytes from 192.168.1.11: icmp_seq=4 ttl=64 time=0.072 ms
64 bytes from 192.168.1.11: icmp_seq=5 ttl=64 time=0.067 ms
^C
--- 192.168.1.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4075ms
rtt min/avg/max/mdev = 0.067/0.069/0.072/0.010 ms
:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5105ms
All configurations are identical to this resource.

Answer 1

The referred resource has leftsubnet=0.0.0.0/0 set. That causes the VPN connection to default to route everything through the VPN. So simplest is if You can change that. I also want to do this (so add all public-ranges in that list and omit private ranges, maybe besides a special private range to reach the servers LAN). Otherwise You have to manage Your local routing on connecting client "manually". (If both sides use strongwan it should be possible to narrow it on eighter side without breaking the SA completely, but not certain whether specifying multiple subnets works with IKEv1 between strongswan client and server or whether You would need to define multiple SAs then.)
Regarding "only way to establish connection"... I'm wondering whether that means You really have the example confiuration (ike2-rw in ipsec.conf) and started daemon and it is not working - but the example is working on server. I had problems with the Strongswan on Ubuntu 18.04 server side (the VPN gateway), it was connecting but connection came not up. The client I did not try. But I found the Ubuntu 18.04 package is broken (or was back then, a few monmth ago) and upgraded my Ubuntu. With 19.04 it works like a charm. (What is Your journal for the strongswan service saying and syslog - or better the /var/log/charon.log when You try to bring up the client as per documentation?)