How to fix client-domain TCP over IPSec?

Question

Computer networks

Greetings.
I decided to switch from OpenVPN to IKEv2, at the same time bringing my devices from the fruit company there.
Certificates from OpenVPN came up great, the connection (with some problems, but still) was established. Now to the problems.
The configuration is as follows: on the server (it's also a router to the home network) there is a br-local interface (192.168.x.1/24), with DHCP configured. Strongswan is configured to use the same, clients get an IP on the same subnet, and all is well. Now I'm knocking from a client (laptop) ... yes, many places, to a home computer, to virtual machines on the same server, etc. - everything is fine. Ping 192.168.x.1 gets through. DIG reports that DNS uses the same - 192.168.x.1 (replies received, including about local resources).
Now a question. What Cthulhu in this idyll does not work TCP to 192.168.x.1? No SSH, no HTTP(S)... nothing.
In wireshark I see packets that go to the address. In tcpdump I see that they are accepted. I see requests in the server logs. But where the traffic goes "back" - I just don't understand. Maybe in /dev/null, maybe in lo, but certainly not to the client.

/etc/ipsec.conf

config setup
  # strictcrlpolicy=yes
  # uniqueids = no

conn %default
  dpdaction=clear
  dpddelay=35s
  dpdtimeout=300s

  fragmentation=yes
  rekey=no
  compress=yes
  mobike=yes

  keyexchange=ikev2
  ike=...
  esp=...

conn phoenix
  left=%any
  leftauth=pubkey
  leftsubnet=0.0.0.0/0
  leftsourceip=%config
  leftcert=vpn-server.crt
  [email protected]
  leftsendcert=always
  leftfirewall=yes

  right=%any
  rightsourceip=%dhcp
  rightca=REDACTED
  rightdns=192.168.x.1,8.8.8.8,8.8.4.4

conn phoenix-pubkey
  also=phoenix
  auto=add

conn phoenix-pubkey-noxauth
  also=phoenix
  rightauth2=xauth-noauth
  auto=add

conn phoenix-eap
  also=phoenix
  eap_identity=%identity
  rightauth=eap
  auto=add

conn phoenix-eap-tls
  also=phoenix
  eap_identity=%identity
  rightauth=eap-tls
  auto=add

/etc/iptables/rules.v4

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1:136]
-A INPUT -i br-local -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wan -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -i wan -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -i wan -p esp -j ACCEPT
-A INPUT -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.x.0/24 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -j MASQUERADE
COMMIT

*mangle
:PREROUTING ACCEPT [375:162632]
:INPUT ACCEPT [57:8507]
:FORWARD ACCEPT [318:154125]
:OUTPUT ACCEPT [43:6847]
:POSTROUTING ACCEPT [361:160972]
-A FORWARD -p tcp -m policy --pol ipsec --dir in --syn -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
-A FORWARD -p tcp -m policy --pol ipsec --dir out --syn -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT

Answer 1

Here is a complete diagram of how packets pass through iptables, including the places where packets are encrypted / decrypted (this point is usually omitted). IMPORTANT! Policy checking and decryption is done by the kernel based solely on SAD and SPD, without using anything else.
What can be done.
From the Linux side, look at the statistics of XFRM - packet converter during encryption-decryption:
If the counter of any error grows - this is no accident. For example, I had a situation when Mikrotik did not match with Strongswan because of the SHA256 hash - Mikrotik has some kind of its own, special implementation - two Mikrotik fit together without problems, but Mikrotik and strongswan categorically refused. At the same time, the XfrmInStateProtoError counter constantly grew - the packet was accepted, but an error occurred during decryption and it was simply discarded as damaged.
There is also a useful swanctl -l command that shows the status of the connection.