If snmpwalk responds on the localhost, then snmp is most likely configured properly on the test target.
This state is further confirmed if at least some remote machines are able to query snmp data on the test target.
For those targets that do not respond, it's highly likely that the route to the snmp port is being blocked or the port is closed or otherwise has restricted access. Since you said that you used a copy of the config file from a running snmp client I am going to assume that all machines are using the same port and have the same public (and private) community string.
Of course the above may not be true so check to make sure that snmpwalk is given all the correct access information needed to query the MIB.
On the remote machine that is unable to access the target snmp data, install nmap if it isn't already installed.
sudo apt update
sudo apt install nmap
Verify that the snmp listening port responds
nmap <target hostname or ip address>
Example:
frankie@ubuntu-m8h:~$ nmap 192.168.0.9
Starting Nmap 7.80 ( https://nmap.org ) at 2023-03-16 15:31 PDT
Nmap scan report for 192.168.0.9
Host is up (0.00017s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
161/udp open snmp
514/tcp open shell
631/tcp open ipp
The correct usage of snmpwalk is:
snmpwalk -r:<device_IP> -c:<community string> -v:<SNMP version>
If the snmp port responds but a snmpwalk times out, check to make sure that the community string matches (public is the default community string).
It's a best practice to initially install snmp using the defaults. Do not change ports or community strings until proper operation has been confirmed. It is wise to change the private community string before starting snmpd though.