[strongSwan] StrongSwan w/ multiple local subnets.
tomkcpr at mdevsys.com
Wed Jun 24 16:40:24 CEST 2020
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.
>> 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
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
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
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 )
More information about the Users