New package: tinc (mesh VPN) - Need assistance packaging
-
I've been toying with a package for the tinc mesh VPN (http://www.tinc-vpn.org) and I think I've gotten it working pretty well. The one area I've got no clue on is the new PBI/build stuff so I'd like someone who knows how this stuff works to let me know if I specified it all correctly. In testing I've been using the FreeBSD binary packages. It's a pretty straight forward install with only one dependency (lzo2).
Here is what I have in my pkg_config.8.xml.amd64 file:
<package><name>tinc</name> <website>http://www.tinc-vpn.org/</website> <descr>tinc is a Virtual Private Network (VPN) daemon that uses tunnelling and encryption to create a secure private mesh network between hosts on the Internet.</descr> <category>Network Management</category> <depends_on_package_base_url>http://files.pfsense.org/packages/amd64/8/All/</depends_on_package_base_url> <depends_on_package>lzo2-2.06.tbz</depends_on_package> <depends_on_package_pbi>tinc-1.0.18-amd64.pbi</depends_on_package_pbi> <build_port_path>/usr/ports/security/tinc</build_port_path> <build_port_path>/usr/ports/archivers/lzo2</build_port_path> <build_pbi><ports_before>archivers/lzo2</ports_before> <port>security/tinc</port></build_pbi> <version>1.0.18</version> <status>ALPHA</status> <pkginfolink>http://doc.pfsense.org/index.php/tinc_package</pkginfolink> <required_version>2.0</required_version> <config_file>http://www.pfsense.com/packages/config/tinc/tinc.xml</config_file> <configurationfile>tinc.xml</configurationfile> <logging><facilityname>tinc</facilityname> <logfilename>tinc.log</logfilename> <logtab>tinc</logtab></logging></package>The various config and XML files can be grabbed here if anyone wants to take a look: http://s3.botch.com/tinc-pfsense.tgz
My main question is did I put in all the build_* tags correctly to get the system to actually build the two binaries?
If so, how do I go about getting this added to the real repo?
-
If you want it to work on 2.0.x as well as 2.1, you need a depends_on_package tag for a tinc tbz file also.
The depends_on_package tags are used by 2.0.x - they are ignored by 2.1.
The build_port_path and build_pbi tags look OK, though if the FreeBSD port of tinc already depends on lzo2 you probably do not need to specify that manually (in build_port_path, depends_on_package or in ports_before).
If you only want it to work on 2.1 in a PBI, then you can remove the build_port_path, and depends_on_package tags, then set the required version to 2.1.
-
Thanks jimp. I started this on 2.0 but have only been testing on 2.1 lately so I think I'll just make it 2.1 only. How does the below look:
<package><name>tinc</name> <website>http://www.tinc-vpn.org/</website> <descr>tinc is a Virtual Private Network (VPN) daemon that uses tunnelling and encryption to create a secure private mesh network between hosts on the Internet.</descr> <category>Network Management</category> <depends_on_package_base_url>http://files.pfsense.org/packages/amd64/8/All/</depends_on_package_base_url> <depends_on_package_pbi>tinc-1.0.18-amd64.pbi</depends_on_package_pbi> <build_pbi><port>security/tinc</port></build_pbi> <version>1.0.18</version> <status>ALPHA</status> <pkginfolink>http://doc.pfsense.org/index.php/tinc_package</pkginfolink> <required_version>2.1</required_version> <config_file>http://www.pfsense.com/packages/config/tinc/tinc.xml</config_file> <configurationfile>tinc.xml</configurationfile> <logging><facilityname>tinc</facilityname> <logfilename>tinc.log</logfilename> <logtab>tinc</logtab></logging></package>Assuming it's good, how do I go about getting it added to the repo?
Also, on an unrelated note, do you know if there is any way for a package to add a network interface? I could not find any other packages that do it nor any documentation around it. Looking at the pfSense code it appears OpenVPN gets special hardcoded treatment to support its interfaces showing up when a new VPN is created. My package works fine without an interface in the GUI (you just need to manually handle routing and add broader firewall rules elsewhere) but it'd be nice if it could integrate similar to OpenVPN.
-
That looks OK.
To get it in, the best way is to sign up on github, make a fork of the packages repo, add your files/code, then submit a pull request.
Not sure about the interfaces bit. We do a bit of fudging on the backend with openvpn to rename its interfaces from tunX to ovpnXY. What sort of interfaces does tinc make?
-
Thanks, I'll set up a git account.
As to the interfaces, tinc uses the same sort of tun interfaces that OpenVPN does (it can also use tap but I'm guessing that'll be pretty rare for pf users). I'd played around with adding them into the GUI via various php calls and manual config editing. I can get them to show up by renaming them like ovpnXY but that's pretty confusing GUI wise and I'd need to make sure to track interfaces along with openvpn. I managed to get them in the GUI called tincXY but there is some process on boot that deletes any interfaces with names that don't fit a certain pattern. At that point I decided it'd like take changes to the base code and likely wasn't something that could be done in a package. I thought I'd throw out the question though. If you all are looking to expand the things that packages are able to do in the future that may be something worth considering.
-
Might be worth opening a feature request ticket for on http://redmine.pfsense.org/ with a target of "future"
Having them named tincXX would be best so they fit the right pattern. Most things don't need to know or care that the OpenVPN interfaces exist though, assigning them is optional.
Is there a reason you need to touch the interfaces themselves in the GUI? In older versions (pfSense 1.2.x) OpenVPN was treated mostly like a package.
-
Nothing that can't be handled by some easy command line stuff. It just allows you to do things on the interface in the GUI like you can for all the other interfaces, such as routing and firewall rules. I was just trying to make a nicely integrated package. I have the configuration all in the GUI, logs in logging section, service started in services, status page, etc. next step seemed to be to give it a proper interface to apply routing and firewall rules to.
-
For the firewall rules, it would be easy to just make an interface group under Interfaces > (assign) (or add one to the config from the pkg), and then when you bring up the tinc interface, add it to the group with ifconfig. OpenVPN does this and that's how the openvpn rules apply to all OpenVPN interfaces.
Routing might be a little trickier, but could be handled in the VPN's interface.
-
Good idea on the interface group, I'll have to give that a try.
In the mean time I think I've committed it to git and put in a pull request. Let me know if I need to tweak anything.
-
Looks OK I need to give it another glance before merging - you might want to add the pkg to the non-amd64 pkg_config.8.xml also (just change the package base url so it doesn't have "amd64" in it when copying it there), unless this package really only works on amd64.
-
FYI- it compiled OK and uploaded but it's a little newer than what you put in the XML
tinc-1.0.19-amd64.pbi
Adjust the name and submit another pull request then it should be ready to use.
-
Thanks I think I've bumped version to 1.0.19, added 32-bit, and sent a new pull request.
-
ok, that's all merged and built and uploaded
-
I added the interface group creation during package install. Seems to work well, thanks for the idea. Sent a PR your way for it.
Also, I found what may be a small bug. You can't add menu items to more then one section if they have the same name. In my case I wanted to add an entry in both the VPN and Status menus (similar to how OpenVPN is listed) but it would only show the first one. After a glance at the code it seems to match on name only when seeing if it already exists and doesn't take placement into consideration. For the time being I just changed the name slightly on the Status menu.
-
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...
