Any idea how you would like the CLI to look like for option 82 support?
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Nov 3 2021
I use Microsoft NPS and it feels correct for me:
I also have some of those APU4 devices and they work actually pretty good. The reasons for those "low" defaults are actually not from VyOS but from the Linux Kernel itself.
Same issue for me, i use the last RC 1.3 release (manualy builded yesterday).
Will you correct this bug until the LTS release ?
The problem exists because of the IKEv1 limitation - peer ID is unknown at the authentication stage. Since, both DMVPN and L2TP are configured for any remote peer address, one of them intercepts customers of the other one during authentication because it is not possible to find out which service will be connected after Phase 1.
Technically, the other one is a duplicate, but there are more details already.
Im not sure its possible to delete the "le" part from vtysh cli? I tried running no ipv6 prefix-list PUBLIC-IPV6 seq 10 permit 2001:db8::/32 le 64 from vtysh, but it never removed le part.
@sajiby3k you can use 0.0.0.0
set vpn l2tp remote-access outside-address '0.0.0.0'
Nov 2 2021
After the investigation, we figured out that it is possible to get the prefix and link-local address during the DHCP commit procedure.
The statement
log(info, binary-to-ascii(16, 8, ":", substring(option dhcp6.ia-pd, 24, 17)));
will give us the next info:
dhcpd[1568]: 40:20:1:ca:fe:11:11:ff:ff:0:0:0:0:0:0:0:0
So, a prefix can be extracted. Also, a link-local address may be generated from the MAC address extracted from the DHCP packet structure.
Submitted this PR https://github.com/vyos/vyos-1x/pull/1061 to fix the op command.
Possibly unrelated, but I'll leave it here
frr-reload output: 0 /usr/lib/frr/frr-reload.py:851: SyntaxWarning: "is not" with a literal. Did you mean "!="? frr-reload output: 1 if line is not "exit-vrf": frr-reload output: 2 2021-11-02 18:33:34,225 INF
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1060
set vpn sstp authentication local-users username foo password 'bar' set vpn sstp authentication local-users username foo2 password 'bar2' set vpn sstp authentication mode 'local' set vpn sstp client-ipv6-pool prefix 2001:db8::/48 set vpn sstp gateway-address '192.168.122.14' set vpn sstp ppp-options ipv4 'deny' set vpn sstp ppp-options ipv6 'allow' set vpn sstp ssl ca-cert-file '/config/user-data/sstp/ca.crt' set vpn sstp ssl cert-file '/config/user-data/sstp/server.crt' set vpn sstp ssl key-file '/config/user-data/sstp/server.key'
Check sessions:
vyos@r4-epa2:~$ show sstp-server s sessions statistics vyos@r4-epa2:~$ show sstp-server sessions ifname | username | ip | ip6 | ip6-dp | calling-sid | rate-limit | state | uptime | rx-bytes | tx-bytes --------+----------+-----------------------+-----------------------+--------+-----------------+------------+--------+----------+----------+---------- sstp0 | foo2 | 2001:db8:0:0:200::/64 | 2001:db8:0:0:200::/64 | | 192.168.122.222 | | active | 00:00:09 | 735 B | 506 B vyos@r4-epa2:~$
Additional note: this, of course, breaks the 'red' vrf connectivity.
If I manually add, using vtysh, the
vrf red vni 3000
everything on the 'red' vrf works fine.
Yes, It seems that rfc doesn't work , also I found this issues :
https://github.com/FRRouting/frr/issues/5824
@zoenan7 Sorry for the late reply! Yes, I got your email and could reproduce the crash using your PoC.
Still not fixed VyOS 1.3-beta-202110300342:
vyos@r4-epa2:~$ generate openvpn key foo Generating OpenVPN key to /config/auth/foo Your new local OpenVPN key has been generated vyos@r4-epa2:~$ vyos@r4-epa2:~$ ls -la /config/auth/ total 12 drwxrwsr-x 2 root vyattacfg 4096 Nov 2 09:00 . drwxrwxr-x 7 root vyattacfg 4096 Nov 2 08:54 .. -rw------- 1 root vyattacfg 636 Nov 2 09:00 foo vyos@r4-epa2:~$
Mentioned here (FRRouting):
BGP vpnv6 next hop address maybe error?