Please share your OpenVPN config
Wed, Oct 14
Tue, Oct 13
I think we could generate private/public keys using openssl instead of using the tinc utility to generqte it... But i have not tested it
I am implementing tinc, but there is a problem I haven't figured out. Normally, in order for tinc to run, it must have a public key and a private key, and it happens that there will be a prompt for this generation command (ask where to save, etc), and it happens that the public key of the local node in the hosts directory is usually used together with some host configuration options. Is there a better way to implement it?
This bug seems to be worse than I thought.
Here's an example:
On reboot an openvpn client inteface will come up outside the vrf. Any routes that get pushed by the server will not get added to the client because it's wants to add the routes inside the vrf of the vtun interface - but the vtun isn't a member.
Heres a log snippet:
PR for CRUX https://github.com/vyos/vyos-1x/pull/568
You're right, if-up.d scripts only get run for the interfaces defined in /etc/network/interfaces.
PR with increasing validator values https://github.com/vyos/vyos-1x/pull/566
I wrote a preliminary CLI configuration file rule. This is the first step in tinc implementation. For details, please read: https://github.com/jack9603301/vyos-1x/blob/T766/interface-definitions/interfaces-tinc .xml.in
Mon, Oct 12
The last thing I think we can add is the dual stack capability options. We only got 2.
Ok, so here's the import LDP FEC one that I think we could take advantage of as well.
set system syslog host 10.0.3.2 format 5424 - description stating this uses RFC5424 style format
set system syslog host 10.0.3.2 format ocetet-counted - description stating messages are octet counted
Ok, so here's the export LDP FEC one that I think we could take advantage of.
It seems to be working now, for some reason it didn't work when I first tried, but now it seems OK.
The one after that I feel would be fairly easy to also implement is customized label allocation. Again, it is under the family of IPv4 or IPv6.
The next one that I think would be fairly easy to add would be the following:
Hello sir. I am unsure if you're able to add more under LDP but I have found others if you possibly could add. They should be simple additions and are already supported under FRR 7.3.1.
I can't reproduce it in the latest rolling
placing the tinc deb in vyos-build/packages is appropriate while writing support for tinc, but for building on a production iso that is distribute it is not appropriate.. but it's quite easy to add the package to our own repository if we need that...
Another option is to compile and package by yourself, but the location of the repository is the problem
The version of tinc vpn supplied with buster is 1.0.35, and 1.1-pre17 is only availabe in the experimental repository as for now. The first release of 1.1pre is from 2011 and i would say that it is quite mature at this point.
I don't think it's necessary to compile DEB packages because they can be obtained directly from apt
ATS looks nice, Varnish / Apache is really a good choice.
Sun, Oct 11
@c-po , it looks like the wrong CLI definition, we can increase the limit in XML.
@Dmitry is this a limitation of Accel-PPP or can we increase the limits on the CLI?
I can feel that pain! When looking at the source from VyOS 1.2 (crux) it looks like it always behaved in this way.
Please post at forum.vyos.io for support
Sat, Oct 10
@christophedc0 Have you enabled NAT rule logging?
Fri, Oct 9
cpo@LR4.wue3# lsmod | grep qat qat_200xx 20480 0 intel_qat 299008 2 usdm_drv,qat_200xx dh_generic 16384 1 intel_qat uio 20480 1 intel_qat authenc 16384 1 intel_qat
Thu, Oct 8
Wed, Oct 7
Tue, Oct 6
Ongoing discussion in the forum on this matter:
Summary to follow when there is a reproducer.
sudo ip link add name tun6 type ip6tnl local 2001:192:168:122:520d:ff:fe03:2 remote 2001:192:168:122:520d:ff:fe01:2 mode any sudo ip link set dev tun6 up sudo ip add add 100.64.0.1/30 dev tun6 sudo ip add add 2001:db8:aa::1/64 dev tun6
Pull request https://github.com/vyos/vyos-1x/pull/563
Mon, Oct 5
The error message is gone now,so that's ok.
When accessing the nat rule, nothing shows up in the monitor.
Okay 2017 is like yesterday in NIS history so we then should keep it!
Any rolling newer then vyos-1.3-rolling-202010050117-amd64.iso will have this included.
I did a minor improvement and reused the fqdn validator in our system. In addition I refactored the domain-search into an includable snippet - so changing grammar, validators can be done in one single file.
Honestly it's not anything I've ever used. But from asking around some people still use it (not specifically in VyOS, just in general)
@christophedc0 please check out any rolling release which is newer then vyos-1.3-rolling-202010050117-amd64.iso as I have found two bugs in the implementation (one for source nat logging) and the other for the warning you have posted.
There are 2 issues: