[strongSwan] client to site but as a gateway(nat)?
peljasz at yahoo.co.uk
Fri Jul 21 21:53:10 CEST 2017
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.
>>> 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
>>> 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.)
pretty basic conf:
with above the client gets to server's site no probs.
A node on client's(linux box as in the other email explained
does everything, out via an ISP) local LAN can ping client's
vpn IP but cannot any other site's IPs.
That node still reaches everything on the Internet via the
client-linux-nat-ISP(as it is the default gw for home LAN on
which a node resides) except for vpn's 192.168.0.0/16.
It feels to me like I'm missing something in swan rather
Basically so the swan client would take local LAN and route
it, or rather nat it to vpn site destination and back.
I thought everybody does that :)
> Karl Denninger
> karl at denninger.net <mailto:karl at denninger.net>
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
More information about the Users