strongSwan

I have a tunnel up but the other network are not able to receive any traffic from my instance. I've used flow logs and it appears that the traffic is going out from the private ip rather than the NAT address I am trying to use.

I've disabled source/destination checks and added the destination to my route table. Can anyone see what might be the issue?

Private IP 1.1.1.1
EIP Public IP 2.2.2.2
Source NAT IP 3.3.3.3
Third-party firewall 4.4.4.4
Destination IP 5.5.5.5

ipsec.conf

config setup
    charondebug="all" 
    uniqueids=no

conn %default
    ikelifetime=28800s
    keyexchange=ikev2
    keylife=3600s
    keyingtries=%forever
    mobike=no

conn vpn1
    authby=psk
    auto=start
    dpddelay=10s
    dpdtimeout=30s
    dpdaction=restart
    ike=aes128-sha256-prfsha1-modp2048!
    esp=aes128-sha256-modp2048,aes128-sha1-modp2048!
    left=%defaultroute
    leftid=2.2.2.2
    leftsubnet=0.0.0.0/0
    leftfirewall=yes
    rightsubnet=5.5.5.5/32
    right=4.4.4.4
    rightid=4.4.4.4
    type=tunnel
    mark=100

strongswan up vpn1

initiating IKE_SA vpn1[12] to 4.4.4.4
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 1.1.1.1[500] to 4.4.4.4[500] (464 bytes)
received packet: from 4.4.4.4[500] to 1.1.1.1[500] (619 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) V ]
received Cisco Delete Reason vendor ID
received Cisco Copyright (c) 2009 vendor ID
received FRAGMENTATION vendor ID
selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA1/MODP_2048
local host is behind NAT, sending kvpn1p alives
received 2 cert requests for an unknown ca
authentication of '2.2.2.2' (myself) with pre-shared key
establishing CHILD_SA vpn1{13}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 1.1.1.1[4500] to 4.4.4.4[4500] (288 bytes)
received packet: from 4.4.4.4[4500] to 1.1.1.1[4500] (240 bytes)
parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
authentication of '4.4.4.4' with pre-shared key successful
IKE_SA vpn1[12] established betwvpn1n 1.1.1.1[2.2.2.2]...4.4.4.4[4.4.4.4]
scheduling reauthentication in 28092s
maximum IKE_SA lifetime 28632s
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
CHILD_SA vpn1{13} established with SPIs c9a79496_i db7979c5_o and TS 10.146.140.2/31 === 5.5.5.5/32
connection 'vpn1' established successfully

iptables-save

# Generated by iptables-save v1.8.2 on Tue Oct 27 14:44:52 2020
*nat
:PREROUTING ACCEPT [1276:89895]
:INPUT ACCEPT [443:19923]
:OUTPUT ACCEPT [1088:83094]
:POSTROUTING ACCEPT [1085:82842]
-A POSTROUTING -d 5.5.5.5/32 -j SNAT --to-source 10.146.140.2
COMMIT
# Completed on Tue Oct 27 14:44:52 2020
# Generated by iptables-save v1.8.2 on Tue Oct 27 14:44:52 2020
*filter
:INPUT ACCEPT [133:32812]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [152:28188]
-A FORWARD -s 5.5.5.5/32 -d 10.146.140.2/31 -i eth0 -m policy --dir in --pol ipsec --reqid 9 --proto esp -j ACCEPT
-A FORWARD -s 10.146.140.2/31 -d 5.5.5.5/32 -o eth0 -m policy --dir out --pol ipsec --reqid 9 --proto esp -j ACCEPT
COMMIT
# Completed on Tue Oct 27 14:44:52 2020