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

[lejeczek]

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