Is it possible to support SSH and SNMP on multiple VRF instances? That way we can have inband and out of band access to the device? I notice that when doing the set snmp service vrf XXX it overwrites the previous one
TL;DR - It does not appear so currently. Time for a feature request unless a dev wants to correct me.
I was going to point at this option set vrf bind-to-all but trying it on my lab did not have the expected results. I had to do a nasty hack to get another ssh process to bind to the vrf I wanted. On top of that I had to bind to the specific IP of my dummy interface because it looks like the kernel looks at the requested ListenAddress before throwing the process into the vrf table.
I have my ssh process configured to listen on the default vrf unbound.
vyos@vyos# sh vrf
bind-to-all
name oracle {
table 1000
}
name test {
table 2000
}
[edit]
vyos@vyos# sh service
<snip>
ssh {
}
<snip>
[edit]
vyos@vyos#
vyos@vyos# ss -lnt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
<snip>
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
<snip>
LISTEN 0 128 [::]:22 [::]:*
To get my desired outcome I had to run things outside of the norm with sudo ip vrf
Before binding to specific IP:
vyos@vyos# sudo ip vrf exec test /usr/sbin/sshd -d -f /run/sshd/sshd_config2
debug1: sshd version OpenSSH_9.2, OpenSSL 3.0.8 7 Feb 2023
debug1: private host key #0: ssh-rsa SHA256:*****
debug1: private host key #1: ssh-dss SHA256:*****
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:*****
debug1: private host key #3: ssh-ed25519 SHA256:*****
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-f'
debug1: rexec_argv[3]='/run/sshd/sshd_config2'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Cannot bind any address.
[edit]
vyos@vyos#
Specifying IP of dum0:
vyos@vyos# sudo ip vrf exec test /usr/sbin/sshd -d -f /run/sshd/sshd_config2
debug1: sshd version OpenSSH_9.2, OpenSSL 3.0.8 7 Feb 2023
debug1: private host key #0: ssh-rsa SHA256:*****
debug1: private host key #1: ssh-dss SHA256:*****
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:*****
debug1: private host key #3: ssh-ed25519 SHA256:*****
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-f'
debug1: rexec_argv[3]='/run/sshd/sshd_config2'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 172.16.0.1.
Server listening on 172.16.0.1 port 22.
And there we are…
vyos@vyos# ss -lnt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
<snip>
LISTEN 0 128 172.16.0.1%test:22 0.0.0.0:*
<snip>
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
<snip>
LISTEN 0 128 [::]:22 [::]:*
[edit]
vyos@vyos#
I’m thinking services should also be included under the vrf context (like protocols)?
Which version are you using?
I can connect to SSH with VRF without issues.
$ ssh vyos@192.168.100.254
Hello!
Last login: Wed May 31 23:12:48 2023 from 192.168.100.1
vyos@r14:~$
vyos@r14:~$ sudo tcpdump -ni foo port 22
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on foo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:18:21.122284 IP 192.168.100.254.22 > 192.168.100.1.54788: Flags [P.], seq 3251862502:3251862690, ack 97138475, win 76, options [nop,nop,TS val 4041808684 ecr 3279542099], length 188
23:18:21.122436 IP 192.168.100.1.54788 > 192.168.100.254.22: Flags [.], ack 188, win 501, options [nop,nop,TS val 3279542120 ecr 4041808684], length 0
23:18:21.219047 IP 192.168.100.254.22 > 192.168.100.1.54788: Flags [P.], seq 188:560, ack 1, win 76, options [nop,nop,TS val 4041808781 ecr 3279542120], length 372
23:18:21.219179 IP 192.168.100.1.54788 > 192.168.100.254.22: Flags [.], ack 560, win 501, options [nop,nop,TS val 3279542217 ecr 4041808781], length 0
23:18:21.322920 IP 192.168.100.254.22 > 192.168.100.1.54788: Flags [P.], seq 560:916, ack 1, win 76, options [nop,nop,TS val 4041808885 ecr 3279542217], length 356
23:18:21.323063 IP 192.168.100.1.54788 > 192.168.100.254.22: Flags [.], ack 916, win 501, options [nop,nop,TS val 3279542321 ecr 4041808885], length 0
23:18:21.426883 IP 192.168.100.254.22 > 192.168.100.1.54788: Flags [P.], seq 916:1272, ack 1, win 76, options [nop,nop,TS val 4041808989 ecr 3279542321], length 356
23:18:21.427264 IP 192.168.100.1.54788 > 192.168.100.254.22: Flags [.], ack 1272, win 501, options [nop,nop,TS val 3279542425 ecr 4041808989], length 0
23:18:21.530897 IP 192.168.100.254.22 > 192.168.100.1.54788: Flags [P.], seq 1272:1628, ack 1, win 76, options [nop,nop,TS val 4041809093 ecr 3279542425], length 356
23:18:21.531005 IP 192.168.100.1.54788 > 192.168.100.254.22: Flags [.], ack 1628, win 501, options [nop,nop,TS val 3279542529 ecr 4041809093], length 0
23:18:21.634942 IP 192.168.100.254.22 > 192.168.100.1.54788: Flags [P.], seq 1628:1984, ack 1, win 76, options [nop,nop,TS val 4041809197 ecr 3279542529], length 356
23:18:21.635093 IP 192.168.100.1.54788 > 192.168.100.254.22: Flags [.], ack 1984, win 501, options [nop,nop,TS val 3279542633 ecr 4041809197], length 0
^C
12 packets captured
16 packets received by filter
0 packets dropped by kernel
vyos@r14:~$
vyos@r14:~$ show conf com | match "vrf|ssh"
set interfaces ethernet eth1 vrf 'foo'
set interfaces ethernet eth2 vrf 'bar'
set service ssh disable-host-validation
set vrf bind-to-all
set vrf name bar table '1012'
set vrf name foo table '1010'
vyos@r14:~$
And I did it many times without any issues
My current version
vyos@r14:~$ show ver
Version: VyOS 1.4-rolling-202305260317
Release train: current
Built by: autobuild@vyos.net
Built on: Fri 26 May 2023 03:17 UTC
Did you try connecting to the address with VRF interface?
I’m running a rolling from last week.
Looks like I need to re-test. I didn’t see the listening port pointing towards the vrf in netstat|ss -lnt so no left that out.
Will post results shortly.
vyos@vyos:~$ sh ver
Version: VyOS 1.4-rolling-202305220317
Release train: current
Built by: autobuild@vyos.net
Built on: Mon 22 May 2023 03:17 UTC
Ok yeh so I re-tested and it does work. I wish netstat|ss would reflect that the vrf table is listening 
You can bind to a specific vrf
set service ssh vrf 'foo'
1 Like
also check if the command :
set vrf bind-to-all
it’s applied , allow to bind service in a different vrf (not default)
That I know… but the OP and I wanted to bind to multiple VRFs and probably on different listening IPs, not having to rely on the service being unbound. So config could look something like
ssh {
listen-address 192.168.1.250 <----- assumed to be in default
vrf test
{
listen-address 172.16.0.1
port 1234
}
vrf test2
{
listen-address 10.0.0.35
port 3456
}
}
Resulting netstat table would be:
vyos@vyos# ss -lnt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 172.16.0.1%test:1234 0.0.0.0:*
LISTEN 0 128 10.0.0.35%test2:3456 0.0.0.0:*
LISTEN 0 128 192.168.1.250:22 0.0.0.0:*
[edit]
vyos@vyos#
Unbound is working for me, I’ll take it. Just have to make sure I cover my bases in the additional firewall rules needed.
Thanks for the second set of eyes.
hi, I think you missed my point.
It is currently working on single VRF.
I have 2 VRF where I want both SSH and SNMP to work. Currently it is only working on one
That’s right. I’m a bit skeptical unbounding it but I guess I have no choice for now…
With bind to all but without specified vrf it will work in all vrfs
I thought of that just now.
Then I’ll just lock/block SSH on default VRF.
Hi there,
I just tried this. NO firewall rule. SSH works fine, but SNMP isn’t. Any suggestions? Process seems to be listening on all interfaces based on below.
I can SNMP the interface on default vrf
I can see SNMP traffic hitting the device interface (on VRF) when I run TCP dump but no response from VYOS. It is coming from
The source IP is listed on snmp client statement, allowing their IPs to SNMp the device.
snmpd 3389 Debian-snmp 10u IPv4 25037 0t0 UDP *:snmp
snmpd 3389 Debian-snmp 11u IPv6 25038 0t0 UDP *:snmp
snmpd 3389 Debian-snmp 13u IPv4 25044 0t0 TCP localhost:smux (LISTEN)
the same with snmp
set service snmp vrf MGMT