I closed the other PR, and put in https://github.com/vyos/vyos-1x/pull/1572.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 8 2022
I'd like to see this feature added so I went ahead and implemented it: https://github.com/Rain/vyos-1x/commit/975f4fc358f0073f1ad825ea209169766dc2fa51
Oct 7 2022
Working directory here; PR pending:
https://github.com/vyos/vyos-1x/compare/current...jestabro:gql-simplify
Oct 6 2022
This a project for mobile access to enterprise networks. VyOS plays as an MPLS-PE router as well as L2TP Network Server. Every subscriber coming via l2tp is directed to the customer's VRF other than default (with RADIUS attribute)
Hi @aserkin! It looks like you have some frr server misbehavior. It sends up/down events with an unexisting vrf id.
Could you make/describe the setup that causes the issue to appear? Thanks
Oct 5 2022
Ah, yeah, that's a valid point for gretap.
In T4729#135223, @pasik wrote:well, "gre" and "gretap" are different types of tunnels, with different features.. so it makes sense to test and validate with the normal "gre", as in your config I don't see a need for "gretap".
I just checked based on your comment and I can also confirm that with 1.4-rolling-202210050218 (using also different syntax) is working perfectly with the authentication.
Update: latest rolling has a bit different syntax. I think users just not migrated properly on update. After adding
set service ipoe-server authentication interface eth1.50 mac 00:50:79:66:68:03 set service ipoe-server authentication interface eth1.51 mac 00:50:79:66:68:04
I see that chap-secrets file generated properly and users getsIPs
vyos@vyos# sudo cat /run/accel-pppd/ipoe.chap-secrets # username server password acceptable local IP addresses shaper eth1.50 * 00:50:79:66:68:03 * eth1.51 * 00:50:79:66:68:04 vyos@vyos# run show ipoe-server sessions ifname | username | calling-sid | ip | rate-limit | type | comp | state | uptime --------+----------+-------------------+-------------+------------+------+------+--------+---------- ipoe0 | eth1.50 | 00:50:79:66:68:03 | 172.16.50.2 | | ipoe | | active | 00:05:21 ipoe1 | eth1.51 | 00:50:79:66:68:04 | 172.16.98.2 | | ipoe | | active | 00:03:43
This issue also present in 1.3.0-1.3.2. Latest rolling 1.4-rolling-202210040218 also affected, it has empty user list in chap-secrets
vyos@vyos:~$ sudo cat /run/accel-pppd/ipoe.chap-secrets # username server password acceptable local IP addresses shaper vyos@vyos:~$
well, "gre" and "gretap" are different types of tunnels, with different features.. so it makes sense to test and validate with the normal "gre", as in your config I don't see a need for "gretap".
Oct 4 2022
In T4729#135221, @pasik wrote:Hmm, any specific reason for the tun0 encapsulation 'gretap' ? did you try with normal 'gre' tunnels ? Does it change anything?
Hmm, any specific reason for the tun0 encapsulation 'gretap' ? did you try with normal 'gre' tunnels ? Does it change anything?
Needs to check, maybe fixed with rewriting in T4678
Oct 3 2022
At least on my lab, with one of the latest 1.4, this is working for me:
In T4708#135016, @Viacheslav wrote:@narey83 Could you re-check it with the latest rolling (start since vyos-1.4-rolling-202209290218-amd64.iso)?
Oct 1 2022
Is there a way to isolate a NAT rule to operate within a VRF?
Sep 30 2022
If you document this check then everything commits.
https://github.com/vyos/vyos-1x/blob/f5a50135f07ac4ec8ed431a757b9c56e607d2132/src/conf_mode/dhcp_server.py#L265-L271
I installed the latest release and its not working for me. Whenever I boot I lose eth0 and eth2 interfaces.
I end up with an eth1 (previously eth2) interface and startup errors that seem to indicate that migrate failed.
I would reconfigure everything to help test this, but I do need two network interfaces.
Sep 29 2022
@pasik you can build your own image: https://github.com/vyos/vyos-build/compare/equuleus...fvlaicu:vyos-build:equuleus-1.3.2
It'd be nice to get a newer igc driver version in 1.3 branch though, as there are now multiple good 2.5 GbE based platforms out there..
Yes, and no updates for the driver in 1.3.2. Ok, thanks!
@pasik the problem is with the igc driver in the 5.4 kernel, not with vyos.
Sorted out the WARNING: terminal is not fully functional message with adding the following export command: -
Yeah, that new nightly release has fixed the issue, thanks. Strangely now getting some weird message in my show commands (WARNING: terminal is not fully functional). This message wasn't there on the previous nightly.
So hmm, is it still the same issue in stock vyos 1.3.2 with i225 nics?
@narey83 Could you re-check it with the latest rolling (start since vyos-1.4-rolling-202209290218-amd64.iso)?
@icyfire0573 Could you re-check it?
Should be fixed in vyos-1.4-rolling-202209290218-amd64.iso
I can't reproduce it, VyOS 1.4-rolling-202209290218
Config:
vyos@r14:~$ show conf com | match openv set interfaces openvpn vtun10 hash 'sha1' set interfaces openvpn vtun10 keep-alive failure-count '60' set interfaces openvpn vtun10 keep-alive interval '10' set interfaces openvpn vtun10 local-host '203.0.113.1' set interfaces openvpn vtun10 local-port '1194' set interfaces openvpn vtun10 mode 'server' set interfaces openvpn vtun10 openvpn-option '--data-ciphers-fallback BF-CBC' set interfaces openvpn vtun10 openvpn-option '--data-ciphers AES-128-CBC:AES-128-GCM:AES-256-CBC:AES-256-GCM:BF-CBC' set interfaces openvpn vtun10 openvpn-option '--comp-lzo yes' set interfaces openvpn vtun10 openvpn-option '--allow-compression yes' set interfaces openvpn vtun10 openvpn-option '--push redirect-gateway def1' set interfaces openvpn vtun10 openvpn-option '--push remote-gateway 10.9.1.1' set interfaces openvpn vtun10 openvpn-option '--push dhcp-option DNS 8.8.8.8' set interfaces openvpn vtun10 protocol 'udp' set interfaces openvpn vtun10 server client-ip-pool start '10.9.1.10' set interfaces openvpn vtun10 server client-ip-pool stop '10.9.1.99' set interfaces openvpn vtun10 server domain-name 'vtr.example.com' set interfaces openvpn vtun10 server max-connections '1000' set interfaces openvpn vtun10 server name-server '10.8.0.1' set interfaces openvpn vtun10 server subnet '10.9.1.0/24' set interfaces openvpn vtun10 server topology 'net30' set interfaces openvpn vtun10 tls ca-certificate 'ca' set interfaces openvpn vtun10 tls certificate 'cert' set interfaces openvpn vtun10 tls dh-params 'dh' set interfaces openvpn vtun10 use-lzo-compression vyos@r14:~$
Op-mode
vyos@r14:~$ show openvpn server
After digging a step deeper we could also move the function into:
Stumbled again about it and would ask if it is not possible to switch to the iptables extension so that rp filter will also work for IPv6.
From my point of view we must create in firewall setup a new chain RPFILTER in IPv4 and IPv6.
Sep 28 2022
Maybe something wrong with this check https://github.com/vyos/vyos-1x/blob/f5a50135f07ac4ec8ed431a757b9c56e607d2132/src/conf_mode/dhcp_server.py#L265-L271
Maybe incorrect parsing of port ranges (comma-separated)
rule 120 { description "Playstation - 172.16.136.96" destination { port 1935,3074,3478,3479,3480 }
PRs open to implement this:
Sep 27 2022
vyos@vyos:~$ show configuration
firewall {
interface eth2 { in { name OUTSIDE-IN } local { name OUTSIDE-LOCAL } } name OUTSIDE-IN { default-action drop rule 10 { action accept state { established enable related enable } } rule 20 { action accept destination { address 172.16.135.35 port 8123 } protocol tcp source { } state { new enable } } rule 21 { action accept destination { address 172.16.135.35 port 443 } protocol tcp state { new enable } } rule 30 { action accept destination { address 172.16.136.16 port 22 } protocol tcp source { address 13.90.97.251 } state { new enable } } rule 40 { action accept destination { address 172.16.136.96 port 1935,3478,3479,3480 } protocol tcp state { new enable } } rule 41 { action accept destination { address 172.16.136.96 port 3074,3478,3479 } protocol udp state { new enable } } } name OUTSIDE-LOCAL { default-action drop rule 10 { action accept state { established enable related enable } } rule 20 { action accept icmp { type-name echo-request } protocol icmp state { new enable } } rule 30 { action drop destination { port 22 } protocol tcp recent { count 4 time minute } state { new enable } } rule 31 { action accept destination { port 22 } protocol tcp state { new enable } } rule 40 { action accept destination { address 172.16.136.35 port 8123 } protocol tcp state { new enable } } }
}
interfaces {
ethernet eth0 { address 172.16.136.1/24 description INSIDE hw-id 6c:4b:90:52:32:75 } ethernet eth2 { address dhcp description OUTSIDE hw-id 7c:c2:c6:42:43:e1 } loopback lo { } wireless wlan0 { hw-id 50:5b:c2:ca:e1:03 physical-device phy0 }
}
nat {
destination { rule 10 { description "Port Forward: SSH to 172.16.136.16" destination { port 22 } inbound-interface eth2 protocol tcp source { address 13.90.97.251 } translation { address 172.16.136.16 } } rule 100 { description "HomeAssistant WAN" destination { port 8123 } inbound-interface eth2 protocol tcp translation { address 172.16.136.35 } } rule 110 { description "HomeAssistant Reflection To" destination { port 8123 } inbound-interface eth0 protocol tcp translation { address 172.16.136.35 } } rule 120 { description "Playstation - 172.16.136.96" destination { port 1935,3074,3478,3479,3480 } inbound-interface eth2 protocol tcp translation { address 172.16.136.96 } } } source { rule 100 { outbound-interface eth2 source { address 172.16.136.0/24 } translation { address masquerade } } rule 110 { description "HomeAssistant Reflection From" destination { address 172.16.136.0/24 } outbound-interface eth0 protocol tcp source { address 172.16.136.0/24 } translation { address masquerade } } }
}
service {
dhcp-server { shared-network-name LAN { domain-search drutherford.com subnet 172.16.136.0/24 { default-router 172.16.136.1 domain-name drutherford.com lease 86400 name-server 8.8.8.8 name-server 1.1.1.1 name-server 9.9.9.9 range 0 { start 172.16.136.50 stop 172.16.136.90 } static-mapping Backyard-Camera-Wireless { ip-address 172.16.136.101 mac-address 78:66:9D:7F:D7:73 } static-mapping Garage-Camera-Wireless { ip-address 172.16.136.99 mac-address 5C:C3:36:4C:D3:20 } static-mapping Green { ip-address 172.16.136.16 mac-address DC:A6:32:6D:20:54 } static-mapping HomeAssistant { ip-address 172.16.136.35 mac-address B8:27:EB:81:ED:01 } static-mapping Playstation4 { ip-address 172.16.136.96 mac-address 00:D9:D1:FD:E3:C8 } static-mapping Pool-Camera-Wireless { ip-address 172.16.136.100 mac-address 78:66:9D:5B:F8:9C } static-mapping RasPBX { ip-address 172.16.136.102 mac-address B8:27:EB:BA:9C:BD } static-mapping Roku-3 { ip-address 172.16.136.98 mac-address B8:3E:59:B3:DF:DB } static-mapping Roku-Ultra { ip-address 172.16.136.97 mac-address 88:DE:A9:C1:C0:41 } static-mapping client1 { ip-address 172.16.136.102 mac-address B8:27:EB:BA:9C:BD } } } } ssh { port 22 }
}
system {
config-management { commit-revisions 100 } conntrack { modules { ftp h323 nfs pptp sip sqlnet tftp } } console { device ttyS0 { speed 115200 } } host-name vyos login { user vyos { authentication { encrypted-password **************** } } } ntp { server time1.vyos.net { } server time2.vyos.net { } server time3.vyos.net { } } syslog { global { facility all { level info } facility protocols { level debug } } }
}
Can we see example destination NAT config with the issue?
still no good
vyos@vyos:~$ show nat destination rules
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/nat.py", line 302, in <module> res = vyos.opmode.run(sys.modules[__name__]) File "/usr/lib/python3/dist-packages/vyos/opmode.py", line 147, in run res = func(**args) File "/usr/libexec/vyos/op_mode/nat.py", line 280, in show_rules return _get_formatted_output_rules(nat_rules, direction, family) File "/usr/libexec/vyos/op_mode/nat.py", line 112, in _get_formatted_output_rules if 'prefix' in match['right'] or 'set' in match['right']:
TypeError: argument of type 'int' is not iterable
vyos@vyos:~$ show version
Version: VyOS 1.4-rolling-202209260217
Release train: sagitta
DEMO Notes:
=====================
1) You need to load the XDP program before starting frr so that it can find the LPM map on plugin initialization. To keep it simple, the VTY interface was not implemented for now. XDP side is accessible via `bpftool` 3) I`m monitoring packets for TOS/DSCP changes to see if marking happens But in another approach tag is associated with the packet and then read by the TC classifier 4) These are two traffic shaping examples. The point is that you have two options for marking: 4.1) Modifying the TOS byte and installing the u32 tc filter to match the value. This has a limited range of possible values (8 bits) + needs to modify the packet. 4.2) Using a custom BPF classifier. The XDP side extends the packet context and saves the value. Afterward, the classifier may read the context and control the shaping behavior by setting the `skb->tc_classid` or one of the fields mentioned below.
Therefore, BPF programs attached to the tc BPF hook can, for instance, read or write the skb’s mark, pkt_type, protocol, priority, queue_mapping, napi_id, cb[] array, hash, tc_classid or tc_index, vlan metadata, the XDP transferred custom metadata and various other information. All members of the struct __sk_buff BPF context used in tc BPF are defined in the linux/bpf.h system header. https://docs.cilium.io/en/stable/bpf/#tc-traffic-control