Is there any kind of ETA on this? It hasn't moved in a few months, and it is preventing me from being able to upgrade. I understand this probably isn't a huge priority, but an ETA would be nice.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Feb 14 2023
Feb 13 2023
In T5004#142577, @n.fort wrote:Can you provide this configuration on both setups:
show config comm | grep relay # And route to relay server show ip route <relay_server>
Can you provide this configuration on both setups:
Then lets close it
I have prepared a configuration example using one of the latest 1.4 images, where more features were introduced.
Scenario and requirements:
- One vyos router
- 3 Uplinks to internet (eth0, eth1 and eth2). Static IP used on three links
- 2 VLANs
- vif 2: + New Connections from vif-2 routed through WAN-2 + Server on vif 2 should accept ssh connections from internet, through dnat on 3 WAN interfaces (outside port 122)
- vif 4: + NewConnections from vif-24routed through WAN-2 + Server on vif 4 should accept ssh connections from internet, through dnat on 3 WAN interfaces (outside port 222)
Don't see any issue with 1.3
vyos@r1:~$ monitor bandwidth-test initiate 192.168.122.14 ------------------------------------------------------------ Client connecting to 192.168.122.14, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.122.11 port 58042 connected with 192.168.122.14 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 6.37 GBytes 5.47 Gbits/sec vyos@r1:~$ vyos@r1:~$ show version
Everything works on version 1.4
In T4774#142529, @c-po wrote:Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing
Keys should not be re-used
Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing
Everything just worked fine.
service {
+ pppoe-server {
+ authentication {
+ mode radius
+ radius {
+ server 172.31.255.2 {
+ key 123456
+ }
+ }
+ }
+ interface eth1 {
+ }
+ }
}Feb 12 2023
Sorry about the trouble - fixed in next rolling release.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1813
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1812
okay, so with https://vyos.dev/T4997 in place (tested via my custom build https://github.com/b-/vyos-build-action/releases/tag/v1.4-rolling_bri_add-dhcp-user-hooks ) and the following file in /config/scripts/dhcp-client/post-hooks.d/set-addrgroup
#!/bin/sh # # /config/scripts/dhcp-client/post-hooks.d/set-addrgroup
Feb 11 2023
Reading more of the fancy internal scripting going on inside VyOS, there's already both a place to put this script (that would cause it to automatically be called by dhclient upon a new address), _and_ it sets a bunch of variables for us so I don't have to hac hac hac parse output that really isn't intended to be parsed. https://github.com/vyos/vyos-1x/tree/current/src/etc/dhcp/dhclient-exit-hooks.d
This is quiet interesting as container memory defaults to 512.
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
WAN_IF_GROUP=wan
show firewall group interface ${WAN_IF_GROUP} | cut -c 2- | cut -d' ' -f2 > /tmp/WANS
WANS=$(</tmp/WANS)
getip(){
#ip -4 a show ${1} | grep -Po 'inet \K[0-9.]*'
run show interface ${1:0:3} $1 brief | tr -s ' ' | grep $1 | cut -d' ' -f2 | cut -d/ -f1 | grep -v ':'
# returns like 123.234.34.34
# grep -v : removes ipv6
}In T2196#125917, @lue30499 wrote:This feature would be very helpfull for hairpin nat as we can see from the mentions.
Might also be helpfull for ipv6 as well.
I am aware its a different product but edgeos from ubiquiti does something like this (looks to be a managed address group that populates dynamically) for nat and fw:destination { group { address-group ADDRv4_eth0 } }
I just want to really strongly second this issue — if this feature isn't added and I can't find a good workaround, I won't be able to stick with VyOS :(
Feb 10 2023
Thanks @Viacheslav, that makes sense.
Take a look at this T4165
Maybe the same issue but per rule. Different order of "comment"
Thanks for reporting.
We will take a look at it.