OPNsense with Site-to-Site IPsec configured steals other routed IPsec traffic

[kokel]

Hello,

we are running OPNsense (Business Repo) on 2x Sophos SG330 hardware in HA with versions:

Code: [Select]

OPNsense 21.10.1-amd64
FreeBSD 12.1-RELEASE-p21-HBSD
OpenSSL 1.1.1l 24 Aug 2021
On wan side our ISP routes a /26 IPv4 public subnet to our wan carp address.
Theses additional IP addresses are configured as IP aliases on the wan interface, also.

We are running an IPsec Site-to-Site tunnel terminated on the OPNsense configured on one of the public ip which is configured as ip alias on WAN interface (as all others, also), e.g. this IP is 1.1.1.1

Additional for another public ip we do BINAT. All traffic for that ip is natted to a direct connected interface/subnet to a fortinet device, which should establish another Site-to-Site IPsec tunnel, but this doens't work.

We have noticed that the charon process on the opnsense listens on all ip addresses on the opnsense, so the opnsense steals all ipsec traffic, even that traffic for public ips which are not configured on the ipsec service on the opnsense:

Code: [Select]

2022-01-11T09:59:07 charon[10012] 12[NET] <1989> sending packet: from 2.2.2.2[500] to x.x.x.x[500] (36 bytes)
2022-01-11T09:59:07 charon[10012] 12[ENC] <1989> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
2022-01-11T09:59:07 charon[10012] 12[IKE] <1989> no IKE config found for 2.2.2.2...x.x.x.x, sending NO_PROPOSAL_CHOSEN
2022-01-11T09:59:07 charon[10012] 12[ENC] <1989> parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) ]
2022-01-11T09:59:07 charon[10012] 12[NET] <1989> received packet: from x.x.x.x[500] to 2.2.2.2[500] (392 bytes)

Code: [Select]

all udp x.x.x.x:500 10.0.0.2:500 NO_TRAFFIC:SINGLE
2.2.2.2 - Public ip / ip alias on wan interface / binat to internal rfc1918 address / fortinet / not related to ipsec terminated on opnsense
10.0.0.2 - internal rfc1918 ip of fortinet device
x.x.x.x - vpn endpoint ip for fortinet on the internet

How can we achieve that the opnsense ipsec stack doesn't listen for the ip 2.2.2.2 anymore in order to nat and forward this traffic rather than handling it itself?

Any help appreciated. Let me know if more details are needed.

Thanks, kokel

[kokel]

Any suggestions? Problem isn't solved yet.