On 6/29/2020 10:00 AM, TomK wrote:
On 6/29/2020 3:31 AM, Tobias Brunner wrote:
Hi Tom,
Is the xfrm_user.ko module used for both traffic going out and coming
back in via StrongSwan / IPSEC ?
It's not used for handling traffic at all. It provides the interface to
configure the IPsec stack (SAs and policies) from userland. It does
rely on general Netlink infrastructure, but no idea what symbol could be
missing. Maybe the kernel version doesn't match exactly?
Regards,
Tobias
That's a bit odd then. Traffic arriving at the on-prem VPN GW from the
Azure VPN Gateway, makes it through just fine. This appears to confirm
routing and general connectivity works.
It's the traffic going from the on-prem VPN GW to the Azure GW where the
issue is.
What I meant to say, is that would confirm all proper kernel modules
were already in place to allow the communication would it not? Anything
else I could try to, in the least, confirm if the packet was
successfully forwarded to the Azure VPN Gateway end?
I know the packet arrives at the IPSec ipsec0 interface however,
checking just now, I don't see any traffic change on the WAN interface
of the on-prem StrongSwan VPN GW.
Will be reading why that is the case to get some more details but this
certainly points to on-prem for the moment.
Looking at xfrm_user.ko, I notice the dependencies it has are:
./net/ipv4/xfrm4_policy.c
./net/ipv4/xfrm4_state.c
Or basically:
xfrm4_policy.ko
xfrm4_state.ko
Neither of these are listed in the dependency list however realized
these were missing while inserting the other .ko modules. Trying to get
a copy of them so I can try this out and see if it makes a difference.
Maybe add these to the dependency list on the wiki?
--
Thx,
TK.
