How about starting with a simple interface and allowing to set interface for binding address?
set high-availability vrrp group foo address 203.0.113.1 interface ethX Possible completions: > ethN Interfcae used to assign virtual address > eth0 > eth1 > eth2
@insignia96 Will be present in the next rolling release.
Re-opened as this task regarding dhcp-server, not dhcp-client
Fixed VyOS 1.3.0:
vyos@r4# run show conf com | match dhcp
set interfaces ethernet eth2 vif 35 address 'dhcp'
[edit]
vyos@r4# run show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 192.168.122.14/24 u/u WAN
eth1 203.0.113.14/24 u/u Lan
192.0.2.14/24
eth2 - u/u
eth2.35 10.0.2.10/24 u/uTo reproduce:
set interfaces ethernet eth2 vif 35 set interfaces pppoe pppoe0 authentication password 'MYPASSWORD' set interfaces pppoe pppoe0 authentication user 'MYUSER' set interfaces pppoe pppoe0 default-route 'force' set interfaces pppoe pppoe0 mtu '1492' set interfaces pppoe pppoe0 redirect 'ifb0' set interfaces pppoe pppoe0 source-interface 'eth2.35' set interfaces pppoe pppoe0 traffic-policy out 'OUT2' set interfaces input ifb0
Commit:
vyos@r11-roll# commit [ interfaces pppoe pppoe0 redirect ifb0 ] Cannot find device "pppoe0" tc qdisc ingress failed at /opt/vyatta/sbin/vyatta-qos.pl line 334.
Fixed in eceaa3a7
Just fork the repository vyos-1x and create a PR with propper commit format.
https://docs.vyos.io/en/equuleus/contributing/development.html#fork-repository-and-submit-patch
https://github.com/vyos/vyos-1x/blob/current/CONTRIBUTING.md
One issue with static + dhcp on one interface at the same time.
After renew, the static address 192.168.122.11 is disappears
To reproduce:
vyos@r11-roll:~$ show conf com | match eth0 set interfaces ethernet eth0 address '192.168.122.11/24' set interfaces ethernet eth0 address 'dhcp'
Renew dhcp:
vyos@r11-roll:~$ renew dhcp interface eth0
Static address not in the system:
vyos@r11-roll:~$ show int Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down Interface IP Address S/L Description --------- ---------- --- ----------- eth0 192.168.122.166/24 u/u WAN eth1 203.0.113.1/24 u/u
@johannrichard Is there any real example that you want to achieve?
PR https://github.com/vyos/vyos-1x/pull/1124
set service ssh disable-host-validation set service ssh listen-address '192.168.122.11' set service ssh listen-address 'fe80::5054:ff:fe48:a0c6%eth0'
Chek service and listen-addresses:
vyos@r11-roll# cat /run/sshd/sshd_config | grep List ListenAddress 192.168.122.11 ListenAddress fe80::5054:ff:fe48:a0c6%eth0
It still doesn't work for 1.3
This regex not for all IPv6 peers
There is a task for "loadbalancing" T4109
Some of the options can be included in the config:
set interfaces openvpn vtun10 openvpn-option-include '/config/openvpn/included.conf'
Just configure minimal OpenVPN configuration and include what you want
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1122
@NikolayP Change it https://github.com/vyos/vyatta-cfg-firewall/blob/1e06e3f891f8238d565ff0eddb4cd8c9b6032346/templates/firewall/name/node.tag/rule/node.def#L5-L9 to the required range.
In T891#20803, @Watcher7 wrote:
- VyOS command syntax cannot currently specify both a next-hop and interface for the same static route, despite FRR being able to do so.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1120
PR for crux https://github.com/vyos/vyatta-cfg-vpn/pull/53
It doesn't matter what you add mobike disable or enable
A possible reason it generates incorrect swanctl.conf for option mobike
@nikeshhajari thanks, I can reproduce it in 1.3:
set interfaces ethernet eth0 address '192.168.122.14/24' set interfaces tunnel tun0 encapsulation 'gre' set interfaces tunnel tun0 multicast 'enable' set interfaces tunnel tun0 parameters ip key '1' set interfaces tunnel tun0 source-address '192.168.122.14' set protocols nhrp tunnel tun0 cisco-authentication 'orange' set protocols nhrp tunnel tun0 holding-time '300' set protocols nhrp tunnel tun0 multicast 'dynamic' set protocols nhrp tunnel tun0 redirect set protocols nhrp tunnel tun0 shortcut set vpn ipsec esp-group ESP-HUB compression 'disable' set vpn ipsec esp-group ESP-HUB lifetime '3600' set vpn ipsec esp-group ESP-HUB mode 'tunnel' set vpn ipsec esp-group ESP-HUB pfs 'dh-group21' set vpn ipsec esp-group ESP-HUB proposal 1 encryption 'aes256' set vpn ipsec esp-group ESP-HUB proposal 1 hash 'sha256' set vpn ipsec esp-group ESP-HUB proposal 2 encryption 'aes256' set vpn ipsec esp-group ESP-HUB proposal 2 hash 'sha256' set vpn ipsec ike-group IKE-HUB ikev2-reauth 'no' set vpn ipsec ike-group IKE-HUB key-exchange 'ikev2' set vpn ipsec ike-group IKE-HUB lifetime '28800' set vpn ipsec ike-group IKE-HUB proposal 1 dh-group '21' set vpn ipsec ike-group IKE-HUB proposal 1 encryption 'aes256' set vpn ipsec ike-group IKE-HUB proposal 1 hash 'sha256' set vpn ipsec ike-group IKE-HUB proposal 2 dh-group '21' set vpn ipsec ike-group IKE-HUB proposal 2 encryption 'aes256' set vpn ipsec ike-group IKE-HUB proposal 2 hash 'sha256' set vpn ipsec ipsec-interfaces interface 'eth0' set vpn ipsec profile NHRPVPN authentication mode 'pre-shared-secret' set vpn ipsec profile NHRPVPN authentication pre-shared-secret 'PRE_SHARED_KEY' set vpn ipsec profile NHRPVPN bind tunnel 'tun0' set vpn ipsec profile NHRPVPN esp-group 'ESP-HUB' set vpn ipsec profile NHRPVPN ike-group 'IKE-HUB' commit
Add mobile disable:
set vpn ipsec ike-group IKE-HUB mobike 'disable' commit [ vpn ] Warning: unable to [reload changes to swanctl.conf], received error code 5632
I prefer to rewrite the whole https://github.com/vyos/vyatta-config-mgmt to XML/python
A similar bug I see in 1.2 with such configuration:
set service snmp contact 'test' set service snmp listen-address 192.168.122.12 set service snmp location 'test' set service snmp v3 user foo auth encrypted-key '0x2e312e332e362e312e362e332e31302e312e322e34' set service snmp v3 user foo auth type 'sha' set service snmp v3 user foo privacy encrypted-key '0x' set service snmp v3 user foo privacy type 'aes'
@m.korobeinikov Could you re-check it and close if necessary?
@ernstjo Do you have any news regarding this issue or should we close it?
@SrividyaA Could you re-check it?