Hi,

I'm trying to setup a transport mode IPsec encrypted GRE tunnel, from one Mikrotik device to a Linux box running strongswan. If I use tunnel mode (all other configs the same) then it's fine, but transport mode has a strange behaviour that causes the linux->mikrotik GRE packets to leave without being encapsulated.

The most obvious difference from the strongswan logs is the following:

In transport mode:

CHILD_SA new{1} established with SPIs cfae744f_i 00838192_o and TS <linux>/32[gre/500] === <mikrotik>/32[gre/500]

In tunnel mode:

CHILD_SA new{1} established with SPIs c85a842d_i 022925d5_o and TS <linux>/32[gre] === <mikrotik>/32[gre]

My guess at this point is that the "port 500" selector that seems to be added in transport mode is confusing the policy on the linux box and therefore any outgoing traffic is not encapsulated (since it's not port 500!)

It does look like it's being proposed by the mikrotik side:

Aug 16 18:00:57 uk5 charon: 15[CFG] looking for a child config for <linux>/32[gre/500] === <mikrotik>/32[gre/500]

I've tried adding [gre/%any] onto the subnet config in strongswan, but I'm assuming it will honour the proposed policy. I'm going to do some more digging, but I wondered if anyone else had seen this.

Thanks,

Lee.

Further digging shows that the policies on linux are installed with the port 500 bit...

src <mikrotik>/32 dst <linux>/32 proto gre sport 500 dport 500
dir in priority 2816 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src <linux>/32 dst <mikrotik>/32 proto gre sport 500 dport 500
dir out priority 2816 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport

Yet if you try to add this kind of policy manually, it specifically tells you that sport and dport are not allowed with the gre proto.

So my assumption at this point is that the Mikrotik IPsec stack is proposing a specific port (500) in a situation where it should be %any. And just for clarify, my policy on the Mikrotik device does indeed say "any" for both ports (and works fine in tunnel mode.)

Thanks,

Lee.