- User Since
- Feb 15 2016, 11:55 AM (78 w, 3 d)
Sat, Aug 12
Please vote in https://phabricator.vyos.net/V4
Sat, Aug 5
@syncer I think the problem is that many fields (eg. within the NAT, WLB, PBR facilities) don't allow to use groups you can use in the firewall stanzas. I think there's no need to poll on this, seems to me like a no-brainer, everyone wants this. Many modern products also add auto variables such as eth0_ipaddresses or eth0_networks. Juniper has an implementation that also allows for hierarchical grouping.
Fri, Aug 4
This required a little voting or some input by a core member on syntax. Once that's established implementation proceeds.
Thu, Aug 3
Merijn is right in my experience. I think root should get unix and the rest the vyos-cli. If you make it a configurable setting within the vyos-cli it would be bestest for everyone.
Sat, Jul 22
Jul 17 2017
is already implemented. great!
Jul 4 2017
could you create a phabricator test paste with the correct permission settings as example. Next step is to programmaticly create the same and then integrate w/ vyos.
Jul 3 2017
This requires that VyOS has either some kind of token that allows him to post-as user or the user credentials for pastebin. PHabricator Bots could be perhaps leveraged.
May 29 2017
I added a force-gateway option some time ago. Regardless it's somewhat expected on 1.2, it needs testing and review. I meant 1.1.7 in my previous post (yes, confusion).
May 22 2017
save https://github.com/vyos/vyatta-op-dhcp-server/commit/64817db98e485eee75b53caf4b308197d094784c in /opt/vyatta/share/perl5/Vyatta/DHCPServerOpMode.pm
May 21 2017
@tsumaru720 Could you provide feedback?
I'm sorry for the belated response. This is great. Thanks for your contribution @fatihusta! Once testing checks out I'll add this to my CLI integration todo.
What version have you been using?
Apr 29 2017
Apr 18 2017
@mdsmds you sure that is not it's intended purpose; scare away people from enabling root on their boxes ;p I'm hoping to have some time soon to do some small stuff like this.
Okay, so maybe we should expand the configuration in that case a little. Let's make it replace whatever value is found and allow all three options in the CLI?
Mar 5 2017
There's no point in having VyOS on a rpi, it's too slow to be useful.
This is more likely a configuration problem. Did you enable the local-traffic-loadbalancing option and is your SSH traffic handled by any WLB rule (or left untouched?). Also post your routing table when all wan interfaces are up. What is the status of the enable-sticky-connections option? From where do you test your SSH connectivity from (a connected subnet of vyos? a routed-subnet ?)
Jan 7 2017
Can you provide the output of /etc/logrotate.conf via a pastebin
Dec 21 2016
@elico if you apply a 'source my-lan-clients, destination port-80, proto tcp' rule with gateway your proxy server + the custom testing-target script. If the proxy is up it will be routed towards it. If the target goes down, without any other policies the packet will fall onto PBR and then routing. Isn't that the behaviour you were looking for?
Dec 20 2016
Wan-load-balance. Example is here: https://github.com/vyos/vyatta-wanloadbalance/blob/current/scripts/http_test.pl and implementation https://github.com/vyos/vyatta-wanloadbalance/blob/current/templates/load-balancing/wan/interface-health/node.tag/test/node.tag/type/node.def
@elico it's pretty simple since WLB supports custom tests for gateway/targets. You can simply script it up to that.
In for a quick meeting. I think one of the major points would be 118; what goes in and what not; this shouldn't take more than 10 minutes, I think.
Dec 16 2016
I'll start with 1.2 and backport from there if necessary.
@oliveriandrea what happens when you use double-quotes for vyos-config and single-quotes for the statement within? Can you also test out the other possible combinations; eg. "--with-escaping-the \"inner quotes\""; this is just for reference (I agree with @syncer recommendations for now). I would be especially interested in if they are treated differently by the tab-completion feature as IIRC it generates somewhat broken suggestions (vyos@vyos #delete openvpn-opt<tab> .. ).
Dec 11 2016
set system options beep-on-startup
That's strange because it's exactly what the code does: https://github.com/vyos/vyatta-cfg-system/blob/current/templates/service/ssh/allow-root/node.def
Closed in https://github.com/vyos/vyatta-op/pull/7
Maybe it's interesting to attach the configs to the tested-build data-entry.
Nov 19 2016
I think the next step for this proof-of-concept is to be tried and validated (setup log rules, tcpdump and send in traffic, manually compare counters to dump) then merged into the regular build-process and finally come up with a CLI syntax.
Could this patch be your solution. I remember there was the duplicate print effect when using DHCP-FO on the entries in the lease file in a specific condition that I've made it to ignore.
Nov 9 2016
When doing DHCP-FO it's intentional both machines send out a lease. The duplicate 'lease' issue in the show statements should've been resolved in latest versions IIRC. Which version are you running?
Sep 26 2016
I have used nDPI on CentOS 5 in the past with 'fair' results. The problem is that the makers of nDPI went commercial and their old/OSS package is afair not maintained anymore.
Sep 20 2016
@rps I think he needs a more modern version of squid with sslbump support. I wouldn't put any effort in WCCP, it seems fairly legacy to me.
Sep 17 2016
or do a fallback to another device.
I prefer opt-in options over 'enable by proxy'.
and future get-lease-hostnames?
Sep 15 2016
Could you provide the contents of "sudo vi /opt/vyatta/etc/dhcpd.conf"? It could be related to previously fixed http://bugzilla.vyos.net/show_bug.cgi?id=334 / Reading into it.
Short answer: not really.
Sep 11 2016
You would have to forward traffic to your device. Preferably it handles all types of traffic. Otherwise you can forward dport 443 towards a specific IP.
Sep 1 2016
From the looks of the script it seems this hostname is coming from the DHCP-server upstream. I wonder if this behaviour is controlable.
Aug 25 2016
The page you've linked mentioned the fix: don't use legacy ciphers.
Aug 8 2016
Would this be a setting in the SSH service or rather system login. Because the former allows you to employ wildcards: VYOS-* while the latter feels more correct otherwise. Or you could have both, default the SSHd setting to no-one, and whitelist per user || employ the wildcard solution.
Jul 13 2016
Jul 4 2016
Commited into current, separate patch available for 117 users if needed be.
Jun 27 2016
Jun 21 2016
Jun 18 2016
On which version was this experienced? Cannot reproduce on 1.1.6, 1.1.7 and 1.2. Could you provide the output of sudo iptables-save? Or sudo iptables -t filter -L -nv (includes packet counters and should show you why your traffic is not hitting your log-rule).
Jun 14 2016
Jun 11 2016
Jun 6 2016
I'm telling you I cannot reproduce on 115,116 and 117.
Jun 5 2016
Can it be you have two protocol children entries and didn't tab twice? [cannot-confirm]
Jun 2 2016
Jun 1 2016
I think we can choose how to implement it. We can apply it as a default entry in one of the vyos chains or let the user-decide. The advantage with the latter is that both implementations can co-exist for a while. With the former solution I would remove the old implementation to not confuse the user.
May 25 2016
abferm, could you work out which other settings would be typically employed w/ a syntax proposal. This way we would implement all at once (saving time).
May 12 2016
Ok, basicly the /tmp/keepalived.data format changed. There's no more OPMode.pm#250 in the output and it was replaced by 'Router ID: <n>' which could be used to do find_sync a bit cleaner. It could be in certain cases the multicast source IP is printed out but I'd have to check Keepalived sources to be sure. I could write it that it probes for a value and upon failure won't print out the Source IP or just remove that part all together. Any preferences: TL;DR: implement safer fail-back legacy behavior or YOLO it?
Apr 21 2016
I think its outside our scope. vyos is a network appliance. it provides services to transfer network traffic or services essential to transfer traffic (dns, dhcp). nfs does touch this aspect at all. Neighter would a radius service but that would enable pppoe-server or hostapd,... to move traffic. Nfs is not a requirement for any deamon to move traffic. ergo outside thhe scope.
Apr 19 2016
Could you give an example of an use-case? Because I think this choice was very much by-design.
Apr 13 2016
Can you make new tasks be assigned into some group 'triage' as for questions now is. The groups for questions should be kept simple as NAT, PBR, WLB, OPENVPN, IPSEC, DRIVER, KERNEL, ... because users will mostly interact with this part.
Apr 10 2016
Apr 9 2016
I ran the scenario 'on a stick' and was unable to reproduce. Please post more debug output using the commands described earlier.
recap from irc: one fix would be to negate the vpn-subnet in the source part of your dnat rule.
It will be possible once you can set the fail-over listen/target port. The problem is that it tries to listen on the same port using multiple sockets (if my memory is correct).
Apr 2 2016
Apr 1 2016
How about making firewall groups IPvAgnostic and have VyOS figure out which the correct IPvN is (depending on where you use it) in a somewhat systematic way. In FW it would be both in parallel, etc. The user would still be able to setup groups per IPvN as-is currently.
Mar 30 2016
I'm haven't looked into it but since I failovered my setup I have:
Mar 21 2016
I haven't been able to reproduce so far. The only difference would be I've used two seperate interfaces instead of 'on-a-stick', I don't think this should matter but will run on-a-stick tomorrow. Is there any NAT involved in your setup?
Mar 19 2016
By duplicate address detection you mean (examples cases):
- eth0 address 192.168.1.1/24 and eth0 address 192.168.1.1/25
- as 1) but between eth0 and eth1
- duplicate IP address on connected segment of interface (you share an IP with another node)
- as 3) but with all connected-segments
- as 4) but additionally in connected routes unique
Can you deploy the advanced ova on free products? Because iirc there are some restraints (eg. single node ESXi)?