Cannot ssh to remote system after enabling IPSec

Question

I have created two VMs on top of base OS and have enabled IPSec between the two VMs. Now the problem is as soon as IPsec starts and SA is established between the two VMs, I am not able to ping or ssh to the VM thorugh the base OS but the VMs can ping each other. As far as I know, IPsec creats a tunnel between the specified IPs only, i.e. packets intended for IP B from IP A gets encrypted and all other packets from IP A can pass through without encryption. Am I missing something here? The config file used is :

conn example  
        left=192.168.54.220  
        leftcert=CA_Server  
        leftsubnet=192.168.54.1/24  
        leftsendcert=always  
        leftrsasigkey=%cert  
        right=192.168.54.221  
        rightca=%same  
        rightrsasigkey=%cert  
        rightsubnet=192.168.54.1/24  
        rightcert=CA_Client  
        authby=rsasig  
        ikev2=permit  
        auto=start  

Answer 1

IPsec creates a tunnel between the specified IPs only, i.e. packets intended for IP B from IP A gets encrypted and all other packets from IP A can pass through without encryption. Am I missing something here?

Yes. IPSec creates a tunnel between two specified endpoints, left and right. But the traffic that uses that tunnel, ie the traffic that is encrypted, is between two specified networks, leftsubnet and rightsubnet. In your case, the two routed subnets are the same as each other, which isn't going to work.

If what you want is to have traffic from A to B encrypted at A and decrypted at B, and vice-versa, you tell S/WAN by setting leftsubnet to be left's address, in your case 192.168.54.220/32 (the mask is important), and by setting rightsubnet to be right's address, in your case 192.168.54.221/32.

Answer 2

As far as I know, IPsec creats a tunnel between the specified IPs only, i.e. packets intended for IP B from IP A gets encrypted and all other packets from IP A can pass through without encryption. Am I missing something here?

Nope! That's the gist of it for your current use case.

I see the subnet keys, but they're the same subnet. I haven't looked at the source code, so I can't definitively say that's the issue ...but I think that's the issue. If not routing or using nat, you'll want transport mode. Here is a point-to-point config I used a couple weeks ago:

conn transportModeFirewallToPhoneServer
        authby="psk"
        auto="start"
        compress="no"
        ecn="no"
        esp="aes128-md5"
        ike="aes256-md5-modp1536"
        ikelifetime="7800"
        keyexchange="ike"
        keylife="3600"
        left="hq.myDynDNSDomainToMyOffice.com"
        leftid="hq.myDynDNSDomainToMyOffice.com"
        leftupdown="/usr/libexec/ipsec/updown classic"
        pfs="yes"
        pfsgroup="modp1536"
        pmtu_discovery="no"
        rekeymargin="540"
        right="XXX.XXX.XXX.XXX"
        rightid="XXX.XXX.XXX.XXX"
        type="transport"

The import bits are the left*, right*, and type. Your config looks fine aside from those keys. Plus, you said it establishes the VPN already, so clearly you have ike & auth correct.