Packets from xfrm interface won't route, but opposite works

I'm working on a site-to-site vpn, where one end us a UDM and the other is Strongswan. The goal is to provide bi-directional routing into a cloud environment. I'm completely baffled why this isn't working.

The good news is Strongswan connects and will pass traffic. But I have some routing issues on the Strongswan side. My Strongswan host has two interfaces, eth0 which has the public internet IP on eth0, and an internal ip of 10.132.169.74 on eth1

• Lan network[s]: 10.87.0.0/24, 10.87.35.0/24, 10.87.235.0/24
• Cloud network: 10.132.0.0/16
• 10.87.0.1 = UDM
• 10.132.169.74 = Strongswan eth1 and connects to the internal cloud network 10.132.0.0/16
• 10.87.0.33 = test host on the LAN network
• 10.132.40.82 = test host on the cloud network

current situation:

• pinging from 10.87.0.33 (Lan test host) -> 10.132.169.74 (Strongswan) works
• pinging from 10.132.169.74 (Strongswan) -> 10.87.0.33 (Lan test host) works
• pinging from 10.132.40.82 (cloud test host) -> 10.87.0.33 (Lan test host) works
• pinging from 10.87.0.33 (Lan test host) -> 10.132.40.82 (cloud test host) Does not work, which is the most important thing outta all of this

Here's the routing table of the Strongswan host 10.132.169.74:

default via x.x.x.x dev eth0 proto static 
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.21 
10.19.49.0/24 dev wg0 proto kernel scope link src 10.19.49.1 
10.87.0.0/16 dev ipsec0 scope link src 10.132.169.74 
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.169.74 
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z

Here's the routing table on the cloud test host (10.132.40.82):

default via x.x.x.x dev eth0 proto static 
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.24 
10.87.0.0/16 via 10.132.169.74 dev eth1 
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.40.82 
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z 

On the Strongswan host, I'm executing this:

sudo ip link add ipsec0 type xfrm dev eth0 if_id 4242
sudo ip link set ipsec0 up
sudo ip route add 10.87.0.0/16 dev ipsec0 src 10.132.169.74

And finally here's my swan config:

sudo tee /etc/strongswan.d/charon-systemd.conf  << "EOF"
charon-systemd {
  load=pem pkcs1 x509 revocation constraints pubkey openssl random random nonce aes sha1 sha2 hmac pem pkcs1 x509 revocation curve25519 gmp curl kernel-netlink socket-default updown vici
  journal {
    default=0
    # enc=1
    # asn=1
  }
}
EOF

sudo tee /etc/swanctl/conf.d/xyz.conf << "EOF"
connections {
  vpn-cloud-udm-lan {
    version=2
    proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
    unique=replace
    encap=yes
    local {
      id=x.x.x.x
      auth=psk
    }
    remote {
      auth=psk
    }
    children {
      net {
        local_ts=10.132.0.0/16
        remote_ts=10.87.0.0/16
        esp_proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
        start_action=trap
        if_id_in=4242
        if_id_out=4242
      }
    }
  }
}
secrets {
  ike-1 {
    id-vpn-cloud=x.x.x.x
    secret="somesecret"
  }
  ike-2 {
    id-udm-lan=y.y.y.y
    secret="somesecret"
  }
}
EOF

and my sysctl on the Strongswan host:

net.ipv4.ip_forward=1
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

sudo swanctl --list-sas shows active tunnels and when I ping I can see the counters go up. Furthermore, a tcpdump listening on the cloud test host shows no traffic arriving, but a tcpdump on the Strongswan host in the particular scenario DOES show the traffic, so it's be dropped there.

Any help is appreciated, thank you!

So after much head banging (not the kind you do to rock music) and gnashing of teeth, I figured it out from this answer: https://www.digitalocean.com/community/questions/site-to-site-vpn-support-any-updates

Digital Ocean was dropping packets on private interfaces. So I added a firewall rule to allow traffic from 10.87.0.0/24 and wahlah! IT WERX!!!