[strongSwan] access roadwarriors from server's LAN - how?

Mon Jun 15 13:06:40 CEST 2020

Hi,

to get rid of ipsec0 interface, you need to set "load = no" to
kernel-libipsec.conf plugin

on Ubuntu 18.04 (it's pretty old and do not support xfrm), I'm using the
following configuration of VTI (this is netplan's config, by I guess you
can easily map it to another formats):

"network":
   "renderer": "networkd"
   "tunnels":
     "vti0":
       "addresses":
       - "y.y.y.y/22"
       "keys":
         "input": NN
         "output": MM
       "local": "x.x.x.x"
       "mode": "vti"
       "remote": "0.0.0.0"
   "version": 2

where vty0 is configured for one-to-many tunnels (take a note of
"remote" which is 0.0.0.0) and

- y.y.y.y is address from your pool for client connections
- x.x.x.x is host's address accessible by clients (where they connect to)
- NN/MM are just numbers, which corresponds to mark_in/mark_out
parameters in swanctl.conf

in similar way you can create another vti interface which will serve
your public connection thus having another mark_in/mark_out values and
exact address for "remote" field.

Hope this can help.

On 15.06.2020 13:50, lejeczek wrote:
>
> On 15/06/2020 10:29, Volodymyr Litovka wrote:
>> Hi,
>>
>> may be it makes sense to consider different interfaces?
>> One for public access, another one - for LAN access.
>>
>> Take a look into
>> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
>>
>> You can use VTI configuration for LAN purposes, while
>> having separate interface (with masquerading) for public
>> access.
>>
>> Hope this'll help.
>>
> That was my first thought and hope.
> My Strongswan creates "ipsec0" automatically and I've never
> bother to investigate how. One thing I know is that on RHEL
> and derivatives we have a 'strongswan-libipsec' package when
> installed, does the trick.
> How to create VDI or even better XFRM per connection? - I
> only started reading and have just tried
> "if_id_in/if_id_out" but I cannot see any effect of that.
>
> thanks, L
>> On 15.06.2020 12:00, lejeczek wrote:
>>> On 15/06/2020 08:53, lejeczek wrote:
>>>> On 15/06/2020 07:16, Volodymyr Litovka wrote:
>>>>> Hi L.,
>>>>>
>>>>> if you can ping server from client, then, in general, you
>>>>> can ping everything from everywhere.
>>>>>
>>>>> It is a question of routing and firewalls, e.g.
>>>>>
>>>>> - NodeA at LAN should know, that ClientA at VPN resides behind
>>>>> VPNSrv at LAN
>>>>>
>>>>> - ClientA at VPN should allow access to his services from VPN
>>>>> connection
>>>>>
>>>>>
>>>> Could it be that my strongswan does not handle my case well?
>>>> My case is such that:
>>>> a) my server runs a client to a "public" VPN of which end I
>>>> know almost nothing - this part works well.
>>>> b) my server is also the server for my own VPN clients - and
>>>> here is where I cannot access those roadwarriors (but they
>>>> can ping server's LAN)
>>>>
>>>> Here is when a roadwarrior connects okey and server show
>>>> this for table 220:
>>>>
>>>> 10.3.9.1 dev ipsec0 table 220 proto static src 10.3.1.101 (a
>>>> client connected to my server, pool for clients is
>>>> 10.3.9.0/24 while server's LAN is 10.3.1.0/24)
>>>> 172.16.0.0/12 dev ipsec0 table 220 proto static src
>>>> 172.16.32.73 (server is client to a public VPN)
>>>>
>>>> If I'm not asking too much then I wonder - is it the
>>>> strongswan not doing something or doing something wrong but
>>>> can be helped somehow? (config/plugin/hooks etc.)
>>>> Or it's exclusively OS firewall/routing which needs fixing
>>>> outside and independently of strongswan? (but then it would
>>>> sort of defeat the purpose of strongswan in my opinion)
>>>>
>>>> ps. If I give clients the pool of "dhcp" so roadwarriors
>>>> land on the same server's LAN then 'ping' to roadwarriors
>>>> works, but erratically.
>>>>
>>>> many thanks, L
>>>>
>>> Okey, I think I know what is going on, but to resolve in a
>>> way that "all" works will be a sticky wicket for me.
>>>
>>> I put masquerading on ipsec0 interface for this one reason -
>>> so some nodes on server's LAN have access to "public" VPN
>>> network when Strongswan is "client" to a public VPN - this
>>> mangles "something" in such a way that Strongswan's own LAN
>>> cannot ping/get to Strongswan's own roadwarriors.
>>>
>>> I'll keep fiddling with firewall as I hope there is a
>>> resolution to my case but in the meanwhile if anybody has
>>> any ideas and suggestions - I'll be grateful.
>>>
>>> many thanks, L.
>>>
>>>>> On 14.06.2020 23:02, lejeczek wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> I have a strongswan serving clients and all seem to flow
>>>>>> nicely from roadwarriors to server's LAN.
>>>>>> I wonder now, before I'd go into configs and settings, how
>>>>>> to make roadworriors accessible from server's LAN.
>>>>>> Is this sever-client issues or something completely
>>>>>> independent and falls into OS's realm of networking, would
>>>>>> you know?
>>>>>>
>>>>>> many thanks, L.
>>>>>>
>>>>> --
>>>>> Volodymyr Litovka
>>>>>    "Vision without Execution is Hallucination." -- Thomas Edison
>> --
>> Volodymyr Litovka
>>    "Vision without Execution is Hallucination." -- Thomas Edison
>
--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200615/2966b374/attachment.html>