What is wrong? "Creating metasocket failed"
Bert Jan Bakker
I'm trying to set tinc and I get the following messages:
Sep 6 13:31:33 leibniz tinc.acvpn[12352]: tincd 1.0.1 (Aug 14 2003 15:09:44) starting, debug level 0
Sep 6 13:31:33 leibniz tinc.acvpn[12352]: /dev/net/tun is a Linux tun/tap device (tun mode)
Sep 6 13:31:33 leibniz tinc.acvpn[12352]: Script tinc-up exited with non-zero status 126
Sep 6 13:31:33 leibniz tinc.acvpn[12352]: Creating metasocket failed: Address family not supported by protocol
Sep 6 13:31:33 leibniz tinc.acvpn[12352]: Ready
My kernel is 2.4.20-686-smp from a debian kernel-image package.
The version of tinc is 1.0.1-1.
A few questions:
- does the failure to create a metasocket mean tinc won't work? The
last message, "Ready", seems to indicate there's no problem
- 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/
Guus Sliepen
> A few questions:
> - does the failure to create a metasocket mean tinc won't work? The
> last message, "Ready", seems to indicate there's no problem
There is no problem. The socket that failed was an IPv6 socket. The IPv4
socket was created without problems, otherwise it wouldn't say "Ready".
If you want to get rid of this warning, add "AddressFamily = ipv4" to
tinc.conf.
> - 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?
I think so.
> - Is it necessary to let tinc load the tun module or does it depend it
> the tun module to be already loaded?
It depends on the module to be loaded or the kernel to autoload it when
tinc tries to open /dev/net/tun.
> - 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?
Tinc doesn't load it, your kernel should do it or another boot script.
> - 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?
Sounds complicated. I don't know, it depends on how your cable router
works. You can also try adding "TCPOnly = yes" to tinc.conf, that way
only a TCP connection is made, which probably won't be mangled as badly
as UDP by your router.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <gu...@sliepen.eu.org>
Brian Costello
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:ber...@asset-control.com]
Sent: Saturday, September 06, 2003 4:58 AM
To: ti...@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)
Jason
> On Sat, Sep 06, 2003 at 05:51:57PM -0700, Brian Costello wrote:
>
>>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.
>
> I used tcp-repeaters to work around this problem back in the very ealy
> versions of tinc, I had the problem of a wingate proxy at that time.
> tcp repeaters can work great, but it can get very confusing when
> debugging.
> I'm very glad this problem is solved now by replacing all gateways by
> linuxboxes about 2 yrs ago.
Just a comment in general: a friend of mine has and uses a D-Link brand
firewall/router/NAT appliance. He just tells it to forward 655 to a
linux box behind the NAT and he runs tinc on that linux box in udp mode
with no problems. I am not sure if his NAT device just tries not to
rewrite the outbound UDP source port if at all possible, or if it is
because of the port forward configuration that it leaves it alone..
Also, it is good to avoid TCPOnly mode if at all possible for more than
just the reasons mentioned in this thread already. See
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
Jason
I.R. van Dongen
> 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.
versions of tinc, I had the problem of a wingate proxy at that time.
tcp repeaters can work great, but it can get very confusing when
debugging.
I'm very glad this problem is solved now by replacing all gateways by
linuxboxes about 2 yrs ago.
Gr,
Ivo van Dongen