<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 7/20/2017 17:30, peljasz wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:6ea19666-7388-0835-63bf-2a9299f39ae0@yahoo.co.uk">
      <br>
      <br>
      On 20/07/17 22:57, Karl Denninger wrote:
      <br>
      <blockquote type="cite">
        <br>
        On 7/20/2017 16:46, peljasz wrote:
        <br>
        <blockquote type="cite">
          <br>
          <br>
          On 20/07/17 21:57, Karl Denninger wrote:
          <br>
          <blockquote type="cite">
            <br>
            That can be made to work provided you do not need inbound
            connections to things on the client side.
            <br>
            <br>
            <br>
          </blockquote>
          exactly like that.
          <br>
          How to even phrase a query to find docs/howtos on such a
          setup?
          <br>
          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?
          <br>
          <br>
          many thanks.
          <br>
          L
          <br>
          <br>
        </blockquote>
        <br>
        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.
        <br>
        <br>
        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.)
        <br>
        <br>
        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.
        <br>
        <br>
      </blockquote>
      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.
      <br>
      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).
      <br>
      What is working as of now:
      <br>
      - 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)
      <br>
      - 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)
      <br>
      <br>
      ! 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)
      <br>
      <br>
      what I want:
      <br>
      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)
      <br>
      <br>
      something I am missing.
      <br>
    </blockquote>
    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)?<br>
    <br>
    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.)<br>
    <br>
    <div class="moz-signature">-- <br>
      Karl Denninger<br>
      <a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
      <i>The Market Ticker</i><br>
      <font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
    </div>
  </body>
</html>