What is wrong? "Creating metasocket failed"

Brian Costello bc at preventsys.com
Sun Sep 7 02:51:57 CEST 2003


Bert:

1) The devfs filesystem itself actually makes that file, devfsd is a
userland daemon that controls the devfs filesystem (letting you override
ownership & protection defaults, among other things).  - devfs creates
whatever device files when they're needed, similar to the kernel module
autoloader.  For more information on devfs, look at
/usr/src/linux/Documentation/filesystems/devfs/README

2) Re: The NAT on your UDP connection - as Guus said, you can use
TCPOnly, which gets around having to use UDP sockets, which have strict
port requirements.  That is probably what you'll have to use, but if
your cablemodem router has "source nat" functionality, then you should
be able to write a rule that keeps the UDP connection's port as 655.
Linux's netfilter/iptables supports this functionality (SNAT), but
that's the only firewall I know of that has this functionality for sure
(cisco's PIX MIGHT have it, but it's been years since I worked with
PIX).  For more information about tinc with iptables, check Tinc's "how
to use tinc behind a masquerading firewall" example.  It is a pity that
Tinc's UDP traffic has the source port limitations, but I guess that is
part of the security model(?)

I had the same problem as you, but my workaround will most likely not
work with any router appliances.  My Firewall (openbsd's ipf replacement
called pf) doesn't support source nat (at least as far as I can tell).
I used TCPonly for a while, which worked, but it APPEARED (from the
documentation http://tinc.nl.linux.org/documentation/tinc_4.html#IDX60)
that Tinc's compression was for the UDP packets only, so presumably with
TCPonly you lose the compression benefit.  Also, tcp packets have a
larger header than udp packets, and I was using tinc over an already
taxed link.

So I used pf's rdr (redirect) functionality to make packets sent to the
tinc server / port 655 redirect to my firewall's localhost port 656.  I
then setup a UDP forwarder on my firewall that listened on localhost
port 656 and forwarded packets received on localhost to the tinc server
port 655 FROM port 655.  It's not an ideal solution by any means since
all my udp packets are routed through userland, but I haven't had any
problems with it as of yet, and the performance of the VPN seems
improved over the TCPonly configuration.

BTW: I'm not running tinc on my firewall (which would've gotten around
the NAT issue) because OpenBSD doesn't support switch mode, which is
necessary for my application.

If anyone wants to see my openbsd workaround, I could post the code &
the pf rule.  It SHOULD be adaptable for use on any firewall that has
redirection functionality, such as Darren Reed's ipf, Gauntlet, Linux
v2.2's ipchains, etc.  The udp forwarder doesn't use any
firewall-specific ioctls for transparent proxying, so it should be
easily ported to any unix-like OS.

bc

-----Original Message-----
From: Bert Jan Bakker [mailto:bertjan at asset-control.com] 
Sent: Saturday, September 06, 2003 4:58 AM
To: tinc at nl.linux.org
Subject: What is wrong? "Creating metasocket failed"


- I'm a bit confused about working with devfs. I noticed that loading
  the tun module causes the /dev/net/tun to be created. I assume devfsd
  does this for me. Is that right?
- Is it necessary to let tinc load the tun module or does it depend it
  the tun module to be already loaded?
- If tinc can take care of loading the tun module, how do I set this up?
Is the "alias char-major-10-200 tun" entry in the /etc/modules.conf
  enough?
- I'm trying to create a connection from home to the office.
  Unfortunately my home cable router maps the 655 port to an
  unpriviledged port when it does outgoing NAT. So I cannot initiate the
  connection from home. My idea as a workaround is to log in to
  the office firewall running tinc by ssh and do a ping to my home
  host. The home cable router is configured to redirect the incoming
  traffic on the tinc port to my home workstation. Will this work?

BertJan Bakker (bertjan at asset-control dot com)
Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://tinc.nl.linux.org/

Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://tinc.nl.linux.org/




More information about the Tinc mailing list