[strongSwan] client to site but as a gateway(nat)?

[lejeczek]

it turns out all it needs is to put mascare on the interface 
strongswan creates when clients vpn successfully.
On fedora it's as simple as doing:
$ firewall-cmd --zone=external --add-interface=ipsec0

now - questions: how to make above happen, or something that 
would result in the same, upon successful vpn tunnel 
established?

many thanks, L.

On 20/07/17 23:37, Karl Denninger wrote:
>
>
>
> On 7/20/2017 17:30, peljasz wrote:
>>
>>
>> On 20/07/17 22:57, Karl Denninger wrote:
>>>
>>> On 7/20/2017 16:46, peljasz wrote:
>>>>
>>>>
>>>> On 20/07/17 21:57, Karl Denninger wrote:
>>>>>
>>>>> That can be made to work provided you do not need 
>>>>> inbound connections to things on the client side.
>>>>>
>>>>>
>>>> exactly like that.
>>>> How to even phrase a query to find docs/howtos on such 
>>>> a setup?
>>>> Or, tips on setup/config much appreciated - I have a 
>>>> working client to site setup - is it only strongswan 
>>>> or/and routing/nating outside of swan?
>>>>
>>>> many thanks.
>>>> L
>>>>
>>>
>>> There's really nothing specific related to StrongSwan 
>>> there other than not mapping your own client NAT 
>>> implementation on top of whatever address/subnet the VPN 
>>> gateway gives you.
>>>
>>> Essentially your client is responsible for NATting the 
>>> client-attached traffic which is then sent to the VPN 
>>> gateway, which (presumably) will NAT it again.  It 
>>> should work with few potential issues (the big one being 
>>> if you have a UDP client of some sort and the 
>>> intermediate NAT times out on stateful tables you'll 
>>> lose some replies, but this usually isn't much of a 
>>> factor.)
>>>
>>> This is, in essence, what running a Hotspot that is also 
>>> a StrongSwan client back to a server winds up being -- 
>>> the VPN server is NATing traffic to the Internet, and 
>>> the Hotspot is NATing traffic for its attached clients.  
>>> It should all "just work" in most cases.
>>>
>> well, if I understand it correctly then my setup is a bit 
>> different, but I thought it still would be commonly 
>> desired that there would be many and easy to find howtos.
>> Namely: a linux box with a public IP(not static per say 
>> but almost the same IP all the time) and that box is the 
>> default gateway/nat for local/home lan. Now that very box 
>> calls out(as a client) to a VPN's site(server I have no 
>> control over).
>> What is working as of now:
>> - linux box vpns out with rightsubnet=192.168.0.0/16 but 
>> the rest(from itself and home lan go out via linux 
>> nat(via my ISP)
>> - from another node on local/home lan I can ping linux's 
>> vnp client IP(given by the swan server), on the node a 
>> added route to 192.168.0.0/16 via 10.1.1.100(linux's 
>> local lan IP which is the default gateway for local/home 
>> lan to the Internet via ISP)
>>
>> ! but I cannot reach anything else on 192.168.0.0/16 from 
>> that same node that can ping 192.168.2.111(vpn client IP)
>>
>> what I want:
>> a node(s) 10.1.1.200 -> 10.1.1.100/nat/publicIP => the 
>> whole Internet (except to 192.168.0.0/16 should go via 
>> linux's vpn client)
>>
>> something I am missing.
> I'm not understanding the network topology in question... 
> is the VPN server on a separate connection from your 
> general Internet ISP or is it a site on the Internet (and 
> thus transports down that connection)?
>
> I suspect the issue is either (1) a routing one or (2) the 
> packets you're tossing down the VPN connection have not 
> been NAT'd before they go down the VPN and thus from the 
> perspective of the server end they're *not* coming from 
> your attached host (which it knows how to reach) but 
> rather from a random 192.168.0.0 address, which is private 
> and unrouteable (and thus getting tossed on the floor on 
> the other end.)
>
> -- 
> Karl Denninger
> karl at denninger.net <mailto:karl at denninger.net>
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/