Web lists-archives.com

Re: TCP proxy for host on subnet

Hash: SHA1

On Tue, Jun 06, 2017 at 10:59:30AM +0100, Ron Leach wrote:
> On 05/06/2017 14:08, Henning wrote:
> >
> >socat
> >
> Henning, thank you for that.  socat seems a very flexible package.
> Have you used it yourself, at all?  I couldn't see from the
> documentation how to terminate socat.  I was planning to use a
> variation of one of their examples, like this:

I'm using it all the time, to have ssh access through a corporate

Corporate firewalls and their priests tend to believe in Numerology,
and for some $REASONS ports 80 and 443 are Good and all other ~65K
are Evil. So I wrap my ssh connections in a port 443 tunnel --
for good measure I wrap that in SSL (I don't even want to know
whether our corporate firewall does stateful inspection, and I guess
there's nobody in house who knows: some higher-order subcontractor
perhaps [1]).

Anyway, on my laptop "lappy" (some names changed, to protect
the innocent:

  myself: my user name
  lappy: my "road warrior" laptop
  example.net: my base station "out there" with a fixed IP
  example.tun: fake name for my base station, as viewed
               from lappy through the tunnel)

to access example.net:

  myself@lappy:~$ cat ~/bin/tun

  socat TCP4-LISTEN:2023,fork,reuseaddr \

As you can see, I use my own self-signed certificate. I'd notice
if our firewall tried to mess with the traffic (unless they are
able to break SSL to MITM me, but I think they are too incompetent
to even spell that; OTOH that's exactly they'd want me to think
*if* they were halfway competent, so there you are :)

On the base station side (which we nicknamed example.net), I have

  myself@myselfium:~$ cat .tls/runsocat
  # Must be root!
  /usr/bin/socat \
    -lf socat-443.log \
    OPENSSL-LISTEN:443,su=myself,reuseaddr,pf=ip4,fork,cert=$CERTS/example.tun/cert.pem,key=$CERTS/example.tun/key1.pkcs8,cafile=$CERTS/root/cert.pem \
    TCP4:localhost:22 &
  exit 0

Combine this with some ssh magic (if I use the target address
to be example.tun, the ssh client on lappy knows to knock on
localhost:2023, where the tunnel's proximal end is listening),
and you have a pretty automated tunnel. The next step would
be actually using a TUN or TAP device and setting up routing
tables, like the grown-ups do ;-P

Of course, I could have set up the ssh daemon at 443 on the
base station, but...

 - traffic doesn't quite "look" like SSL. I don't even want
   to find out whether corp firewall freaks out on this

 - I might someday want to run a "real" https on 443 on
   base station. Then I could multiplex on SNI host name
   to decide whether it's a real https request or someone
   is knocking at my tunnel's door.

Enjoy, feel free to ask things.

- -- t
Version: GnuPG v1.4.12 (GNU/Linux)