[strongSwan] XFRM kernel policies for "L4 protocols" that use ports symmetrically

[Ansis Atteka]

I have following setup (charon in transport mode):
(STRONGSWAN1)10.0.0.2/24------->10.0.0.1/24(ROUTER)1.1.1.1/16---------->1.1.1.100/16(STRONGSWAN2)
Traffic from STRONGSWAN1 to STRONGSWAN2 is natted from 10.0.0.2 to
1.1.1.1. So NAT traversal kicks in when STRONGSWAN1 initiates IPSEC
tunnel to STRONGSWAN2. I do not know in advance to which external IP
address STRONGSWAN1 will be natted by the ROUTER (if it will be natted
at all).

Also, I have to install IPSEC policies manually, because of the nature
of the protocol that I am encapsulating (it is like UDP, but it is not
UDP):
1. If STRONGSWAN1 sends packet to STRONGSWAN2, then it uses UDP source
port 9999 and destination port 10000;
2. If STRONGSWAN2 sends packet to STRONGSWAN1, then it uses UDP source
port 9999 and destination port 10000 (not in the reverse way as one
would have expected!)
I know that I could establish 2 separate IPSEC tunnels to get this
traffic encapsulated, but then the tunnel policy would be a little bit
too wide and have 4 SAs instead of just 2 SAs.

But, if I am using "installpolicy=no" to get a matching size for the
tunnel, then it seems that STRONGSWAN2 does not do following things
for me any more.
1. "ip route add 10.0.0.2/32 via 1.1.1.1 table 220"; and
2. "ip xfrm policy update src 1.1.1.100/32 dst 10.0.0.2/32 proto udp
sport 9999 dport 10000 dir out priority 1794 tmpl src 0.0.0.0 dst
1.1.1.1 proto esp reqid 1 mode tunnel"
Note that with "installpolicy=yes", strongswan sets those two things
automatically for me, but then I would end up with a wider tunnel than
I need.

What would be the best way to tackle this problem? One solution that
comes into my mind is to use leftupdown script and then use
$PLUTO_PEER (or ROUTER's IP address) to update existing outgoing IPSEC
policy and install that missing route. But is there something more
elegant?

If only way to get this done is by using updown script, then I would
be willing to contribute a patch that would allow to encapsulate such
"unusual" L4 protocols. Two solutions that come into my mind are:
1. extend [left|right]protoport so that it would have two ports
instead of just one. If second port was present, then use it for
kernel IPSEC policy.
2. add new configuration variable (something like
tunneltype=[symmetric|asymmetric]), that would indicate that ports in
leftprotoport and rightprotoport need to be reversed when strongswan
installs kernel policy.
Any thoughts?

On STRONGSWAN2 I have ipsec.conf that looks something like like (still
needs improvements):
conn %default
        keyingtries=%forever
        type=transport
        installpolicy=no
        keyexchange=ikev2
        auto=start
conn remote
        reqid=1
        left=%any
        leftcert=/cert.pem
        rightsourceip=10.0.0.2
        rightcert=/cert-10.0.0.2.pem
        right=%any

And on STRONGSWAN1:
conn %default
        keyingtries=%forever
        type=transport
        installpolicy=yes
        keyexchange=ikev2
        auto=start
conn remote-1.1.1.100
        reqid=1
        left=%any
        leftcert=/cert.pem
        right=1.1.1.100
        rightcert=/cert-1.1.1.100.pem
        leftsourceip=%config



Best regards,
Ansis Atteka