- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 31 2023
The same bug was with ipoe-server https://vyos.dev/T5283
It is the actual address x.x.x.0 for UNIX devices and PPP interfaces, but it could be issue work Windows clients
There is a simple fix https://github.com/vyos/vyos-1x/commit/8a79769bf447cb18d456f061afd6a7997b8264f8
I'm sorry.
I tested this is VyOS 1.3.3.
I tested mutliple configurations, from subnet /23 all the way up to /32 with the command "set service pppoe-server client-ip-pool subnet <x.x.x.x/x>"
After setting the subnet i'd connect multiple clients to VyOS and check wether all the available IP addresses were used, and they were.
Which version?
Which tested config? Which generated config?
It would be more clear if you provided tangible examples.
Jul 30 2023
Just to sync this task to PR 2118:
As mentioned in https://vyos.dev/T5419 the offloading should not only apply for NAT.
Duplicate of the task https://vyos.dev/T4502
And there also a PR https://github.com/vyos/vyos-1x/pull/2062
It is waiting for merging firewall refactoring
Jul 29 2023
This particular case was resolved by adding:
For "show dhcp client" command https://github.com/vyos/vyos-1x/pull/2120
I added this comment to PR 2118:
A not too uncommon workaround for this is to disable the lease-file (if possible) and give out leases based on option82 information instead.
Is this a limit of wireguard?
I'm using the *-parameters in isc-dhcp to manage ddns updates to an external nameserver. This way dns-entries supplied by dhcp-server will be kept in sync, even when using dhcp-failover.
I would love to still be able to keep this functionality with Kea in some way. Either by providing corresponding custom-parameters, or adding native support for this scenario.
Jul 28 2023
I have submitted PR 2118 for this issue.
You skip this warning and delte version number line
// Warning: Do not remove the following line // vyos-config-version: "bgp@4:broadcast-relay@1:cluster@1:config-management@1:conntrack@3:conntrack-sync@2:container@1:dhcp-relay@2:dhcp-server@6:dhcpv6-server@1:dns-dynamic@1:dns-forwarding@4:firewall@10:flow-accounting@1:https@4:ids@1:interfaces@29:ipoe-server@1:ipsec@12:isis@3:l2tp@4:lldp@1:mdns@1:monitoring@1:nat@5:nat66@1:ntp@2:openconnect@2:ospf@2:policy@5:pppoe-server@6:pptp@2:qos@2:quagga@11:rip@1:rpki@1:salt@1:snmp@3:ssh@2:sstp@4:system@26:vrf@3:vrrp@4:vyos-accel-ppp@2:wanloadbalance@3:webproxy@2" // Release version: 1.4-rolling-202307090317
I've recently migrated from a PCEngines APU2C4 to a Wyse 5070 with a X520 card, as well as upgrading to VyOS 1.4-rolling-202305081003
After which I was unable to reproduce this issue. Roaming now works fine without the ICMP check.
Jul 27 2023
It is a bug that it’s on by default, see other task. Will be fixed after new firewall refactor is merged.
From the VyOS documentation and https://community.openvpn.net/openvpn/wiki/DataChannelOffload
Then how come conntrack modules are loaded (and there is content in the ruleset "sudo nft -s list ruleset") when I have no firewall rules configured?
CLI adjusted to:
Conntrack should be disabled by default https://vyos.dev/T5080
It is not a bug.
It is the implementation of TACACS authentication https://github.com/vyos/vyos-1x/pull/2038
https://github.com/vyos/vyos-1x/blob/fa07179ae7f1dc07e6ccc1b20d2b81384b6efe07/debian/vyos-1x.postinst#L47-L52
Jul 26 2023
Tested and verified as described in the pull request:
Thanks for testing and submitting PR
Pull request created: https://github.com/vyos/vyos-1x/pull/2112
There is this line in the code https://github.com/vyos/vyos-1x/blob/688755a988e233e221bf920e391e35d5ddc9cb56/src/op_mode/show_ntp.sh#L21
@c-po just added the sudo on a live box to test the changes and I can confirm that fixes it. No auth prompt when doing a load config.
Now I did notice that every time I do a load config it runs that migration script which stops/starts the container which is not ideal.
Jul 25 2023
I can confirm that altering line 21 as suggested fixes this issue.
We probably wan't to load/unload the Kernel Module given what the user want's to do
Out of the blue it seems like "network namespaces" would solve alot of current VRF compatability issues within VyOS:
Workaround until "system name-server" becomes vrf aware seems to be to change context into vrf INTERNET and then do a ping with VRF syntax like so:
I would vote for:
Can you check changing