[strongSwan] StrongSwan w/ multiple local subnets.

[TomK]

On 6/24/2020 9:19 AM, Tobias Brunner wrote:
> Hi Tom,
> 
>> May I ask which exact line above told you I'm missing sfrm_user?  The
>> ones that start with CUSTOM?
> 
> Yes, the first one is logged after the kernel-netlink plugin failed to
> open a Netlink/XFRM socket, plus it is obviously missing in the module
> lists you posted after that.

Kool

> 
>> This is DD-WRT so it's a minimized router kernel. I was surprised as the
>> next guy learning that module isn't available.
> 
> Yeah, makes not much sense to enable the other IPsec-related modules
> without a means to actually use them.  But why did you use the 2.6.23
> kernel sources to build the missing module if your router uses a 4.4.190
> kernel?

Was questions my sanity around that as well but initially only found the 
wiki page for 2.6.33 .  The SVN appeared a bit messy to me, probably 
because I'm not familiar with it yet, so wasn't sure if they just reused 
the folder name or if it was truly for Linux 2.6.33.  And couldn't find 
the Linux 4.4's at the time until I rummaged through the SVN the next day.

Look further down on the post.  I've tried the Linux 4.4 branch but 
couldn't get that to work.  There's some missing Makefiles.

> 
>> I tinkered around with this at some point.  I had it originating from
>> 192.168.0.6 > 10.10.0.4 but same results.  Based on what you wrote,
>> unless I get xfrm_user module installed, this won't work regardless of
>> what source IP it's coming from?
> 
> No, that's unrelated.  You need that module to use the IPsec stack in
> the kernel (i.e. to run without kernel-libipsec or ipsec0 interface).
> The whole point of the userland IPsec stack is that it bypasses the
> kernel and can run with reduced privileges (e.g. on Android where apps
> can create TUN devices via VpnService API but can't access the kernel's
> IPsec stack via Netlink/XFRM).
> 
>> instead of originating from the WAN IP. No reply of course.  My routes
> 
> Are ESP packets sent?  If yes, are any returned?  If not, then this
> seems to be an issue on the other end.  So try to follow the traffic there.

That is what I'm not sure about.  Between StrongSwan (SSW) and Azure VPN 
Gateway, I'm not able to find which one is it.  I've setup a packet 
trace from the Azure VPN Gateway but the only option it gave me as a 
target was against one of the Azure VM's.  Not between Azure VPN Gateway 
and the on-prem gateway.

So in the least I was hoping to confirm if everything was sent correctly 
from SSW then I'll be more sure that the issue is really with Azure VPN 
Gateway blocking traffic.

What I do know is that I can ping from the Azure VM's back down to my 
on-prem VLAN (192.168.0.X/24 ) but NOT FROM my router that's running 
SSW. In other words, traffic flows only one way.  Down.

So to me this looked like an issue where:

1) Like you said, ESP packets are not getting sent properly from SSW to 
Azure VPN Gateway.  (  How do I confirm this with 100% certainty?  What 
should I look for to determine if there's any dropped packets on my 
on-prem F/W that's on this router? )

2) The Azure VPN Gateway is blocking on-prem to itself.  I've made sure 
the F/W on the Azure side is not an issue.



> 
>> root at DD-WRT:~# ip route
> 
> Again, strongSwan installs its routes in table 220, that is, use `ip
> route show table 220` (or `all`).

root at DD-WRT:~# ip route show table all
default via 100.100.100.50 dev vlan2
10.0.0.0/24 via 192.168.0.1 dev br0  metric 20
10.1.0.0/24 via 192.168.0.1 dev br0  metric 20
10.1.1.0/24 dev tun2 scope link  src 10.1.1.1
10.2.0.0/24 via 192.168.0.1 dev br0  metric 20
10.3.0.0/24 via 192.168.0.1 dev br0  metric 20
100.100.100.75/27 dev vlan2 scope link  src 100.100.100.100
127.0.0.0/8 dev lo scope link
192.168.0.0/24 dev br0 scope link  src 192.168.0.6
192.168.45.0/24 dev wl0.1 scope link  src 192.168.45.1
192.168.75.0/24 dev wl1.1 scope link  src 192.168.75.1
broadcast 10.1.1.0 dev tun2 table local scope link  src 10.1.1.1
local 10.1.1.1 dev tun2 table local scope host  src 10.1.1.1
broadcast 10.1.1.255 dev tun2 table local scope link  src 10.1.1.1
broadcast 100.100.100.75 dev vlan2 table local scope link  src 
100.100.100.100
local 100.100.100.100 dev vlan2 table local scope host  src 100.100.100.100
broadcast 100.100.100.25 dev vlan2 table local scope link  src 
100.100.100.100
broadcast 127.0.0.0 dev lo table local scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo table local scope host  src 127.0.0.1
local 127.0.0.1 dev lo table local scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo table local scope link  src 127.0.0.1
broadcast 192.168.0.0 dev br0 table local scope link  src 192.168.0.6
local 192.168.0.6 dev br0 table local scope host  src 192.168.0.6
broadcast 192.168.0.255 dev br0 table local scope link  src 192.168.0.6
broadcast 192.168.45.0 dev wl0.1 table local scope link  src 192.168.45.1
local 192.168.45.1 dev wl0.1 table local scope host  src 192.168.45.1
broadcast 192.168.45.255 dev wl0.1 table local scope link  src 192.168.45.1
broadcast 192.168.75.0 dev wl1.1 table local scope link  src 192.168.75.1
local 192.168.75.1 dev wl1.1 table local scope host  src 192.168.75.1
broadcast 192.168.75.255 dev wl1.1 table local scope link  src 192.168.75.1
root at DD-WRT:~#


root at DD-WRT:~# ip route show table 220
root at DD-WRT:~#


( Redacted the IP hence why you see 100.100.100.X for the ISP GW )

> 
> Regards,
> Tobias
> 


-- 
Thx,
TK.