New package: tinc (mesh VPN) - Need assistance packaging
-
OK, that request was merged. You may want to bump the version number on the package when you make changes like that. Even if you don't change the binaries, you can see some of the other packages have a separate "package" version that changes independently of the underlying software, so people know to reinstall to pick up recent changes in the package code.
Haven't hit that menu bug before but it's not terribly surprising. That was probably done to avoid duplicate menu entries at some point.
-
is this package now generally available? i cant see it in the list?
-
I believe it's only on 2.1.
-
you dont mean … 2.0.1 ? :(
-
No, only 2.1-BETA
-
This would be handy to have on 2.0.x if someone happens to have the time and it's not too much trouble, it sounds like it's just a packaging issue? Unless 2.1 is really, really close to release, but it's hard to judge release timeframes based on past history with pfSense yet :-)
-
x2
Original developer originally had it in 2.0 but went with just 2.1 since that's primarily what he ran. Would be far more interested in playing with tinc on 2.0 than moving everything everywhere to 2.1.
-
FYI, I upgraded everything everywhere to use it, before 2.1 went final. Couldn't help myself, the package works nice. Status page gets brain dead after it runs for a while, but that seems to be due to log file truncation than any error in the php. You can restart and it looks all pretty, but really, it's usually fine despite what the sometimes blank status page may lead you to believe.
When looking at the tincd man page, looks like if you send a HUP, it will rehash the configuration (and connect/disconnect depending on changes in hosts) and it restart the log file. I tried it locally with no luck, maybe because tincd is not actually called with –logfile=/var/log/tinc.log? More investigation is needed there.
SIGNALS ALRM Forces tincd to try to connect to all uplinks immediately. Usually tincd attempts to do this itself, but increases the time it waits between the attempts each time it failed, and if tincd didn't succeed to connect to an uplink the first time after it started, it defaults to the maximum time of 15 minutes. HUP Partially rereads configuration files. Connections to hosts whose host config file are removed are closed. New outgoing connections specified in tinc.conf will be made. If the --logfile option is used, this will also close and reopen the log file, useful when log rotation is used.The hardest part about the install for most will be generating the tinc key. I think if we could finagle a way to have a 'generate keypair' button on the configuration page (suppose we could lift template from OpenVPN or other page), it would make life easier for new installs. (After that you just copy the keys form one web gui to another, so simple!)
There are a few tweaks the package needs, as the reinstall/upgrade issues are definitely annoying. It would be nice to fix it so the status showed the status every time, and a generate keypair option would go a long way to making this package quite feature complete.
If you like the idea of a simple, mesh VPN for linking multiple networks together, this is about as easy as it gets. So far I've been very happy with it, and other than to view real status, I haven't had to hardly touch it once setup. (One deployment was 4 subnets, another is 5 with more planned)
If we are able to touch up a few things in the package, I don't see why this couldn't make its way into the standard release. Perhaps tinc just needs to become more popular first. Maybe a small tinc install walk through somewhere on the wiki would help that too.
Anyone else care to comment on how they like tinc so far?
-
I've just started using this package in a test environment and so far its pretty good!
The few things I can see that would be beneficial:
1.) RSA keygen (You know this already)
2.) Should auto-add VPN WAN rule while following "Disable Auto-added VPN rules" in advanced system settings.
3.) In my particular case I ended up needing to add a firewall rule to ensure traffic was routed through tinc:
(pass in quick on $LAN inet from any to 192.168.5.0/24 keep state label "USER_RULE: Route to tinc")
Would there be a way for this to set up a Firewall Alias that is auto-populated with the subnets being detected?Overall it's a amazing to have this functionality in pfSense now!
-
I've just got this partly working on my pfSense box. I can connect from a remote computer and ping the router. I can't access the router or any other devices on the network.
I've got it configured as follows:General Router Config
Routers LAN IP: 192.168.5.254
Router DHCP Range: 192.168.5.100 - 192.168.5.200Tinc Router Config:
Name: tincrouter
Local IP: 192.168.5.254
Local Subnet: 192.168.5.0/24
VPN Netmask: 255.255.0.0
Address Family: AnyTinc Router Config, for tincclient host:
Name: tincclient
Address: Whatever the address of the client is
Subnet: 192.168.254.0/24Tinc Client Config:
Name: tincclient
Address Family: ipv4
ConnectTo: tincrouter
Interface: tun0
Device: /dev/net/tun
OS: Ubuntu 12.04LTSTinc Client Config, for tincrouter host:
Address: Whatever the router address is
Subnet: 192.168.254.0/24Are there any special firewall rules that need to be added?
-
I've just been fiddling some more. I just discovered, that I actually cant ping my router. For some reason my tun0 interface is getting the same ip as my router, so i was pinging myself…
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.5.254 P-t-P:192.168.5.254 Mask:255.255.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:2028 (2.0 KB)This explains why the ping time was so low 0.09ms :-\ Should have picked it up earlier, guess that's what you get for working at 2am...
