helo:
…neither from my network nor from any other place…
… and obviously , i cannot update feeds…
… it´is just me, or is there any issue from youre side?
thanks
There is a firewall in place, you need to check the Service with Netcat on the TCP rsync port. Anything else will not work.
1 Like
k… thanks a lot
Running traceroute may help you find where the connection is being blocked in case you have multiple host / network firewalls in place.
traceroute 45.135.106.143
traceroute to 45.135.106.14 (45.135.106.14), 30 hops max, 60 byte packets
1 ***** ***** *****
| 2 | core23.fsn1.hetzner.com | 213.239.245.237 | de | 2.193 ms | 0.393 ms | |
|---|---|---|---|---|---|---|
| core24.fsn1.hetzner.com | 213.239.245.241 | de | 0.351 ms |
| 3 | core0.fra.hetzner.com | 213.239.224.66 | de | 4.843 ms | 4.937 ms | |
|---|---|---|---|---|---|---|
| core0.fra.hetzner.com | 213.239.224.82 | de | 4.819 ms |
4 10GE-7-1.DECIX1.FRA.IAG.EU 80.81.194.46 de 5.204 ms 5.193 ms 5.203 ms
5 po1-1422.ccr2.whp26.fra.iag.eu 89.146.193.246 de 5.307 ms 5.302 ms 5.283 ms
6 no.ptr.set.yet 195.34.169.230 us 6.380 ms 5.809 ms 6.522 ms
7 ***** ***** *****
I would use a tcp-traceroute that will give you much more detail and if the service is reachable at all 
1 Like
Sorry, I put the wrong IP address in the traceroute command above. I Missed the last digit. You might want to try again with the correct one since the wrong may not be blocked by a firewall that is affecting your connection.
ok… but anyway did not work. I have open all for and front mi source IP… and still don´t work…
in previous comment Lukas said that 45.135.106.143 is firewalled, so, will not respond to ping…
but tcptraceroute to port 24 or 443 must respond… i think… but i don´t get any trace.
i have implemented a kali linux and install openvas into it… everything ok untill feed updates… it didn´t work…
here is output
kali@kali:~$ sudo gvm-check-setup
gvm-check-setup 22.4.1
*** Test completeness and readiness of GVM-22.4.1***
Step 1: Checking OpenVAS (Scanner)…
*** OK: OpenVAS Scanner is present in version 22.4.1.***
*** OK: Notus Scanner is present in version 22.4.4.***
*** OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.***
Checking permissions of /var/lib/openvas/gnupg/*
*** OK: _gvm owns all files in /var/lib/openvas/gnupg***
*** OK: redis-server is present.***
*** OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock***
*** OK: redis-server is running and listening on socket: /var/run/redis-openvas/redis-server.sock.***
*** OK: redis-server configuration is OK and redis-server is running.***
*** OK: the mqtt_server_uri is defined in /etc/openvas/openvas.conf***
*** ERROR: Directories containing the NVT collection not found.***
*** FIX: Run the NVT synchronization script greenbone-nvt-sync.***
*** sudo runuser -u _gvm – greenbone-nvt-sync.***
*** ERROR: Your GVM-22.4.1 installation is not yet complete!***
when i run : sudo runuser -u _gvm – greenbone-nvt-sync here is the output:
sudo runuser -u _gvm – greenbone-nvt-sync
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): No route to host (113)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]
… is there any way to check if service is available? how to check if 45.135.106.143 is responding?
i have tried tcptraceroute 45.135.106.143:24 and 443 but no response… have tried online tracert with same result…
any idea?
same result … no trace to host… i´ve even try online tools to trace, i´ve tried to check ports 24 , 443… but no response…
is ther a way to check if service is available? or it´s a blackbox ?
it´s very frustrating be completely blind. 
best regards
The only reason I suggested using traceroute (or tcptraceroute if you like) is to verify whether requests to the IP address (or domain) are able to leave your local network. This would determine if the firewall is on your host, within your local network - or beyond.
Below you can see that the requests are able to go beyond my local network router.
$ traceroute feed.community.greenbone.net
traceroute to feed.community.greenbone.net (45.135.106.143), 64 hops max, 52 byte packets
1 mynetwork (192.168.2.1) 2.626 ms 0.294 ms 0.221 ms
2 lnsm2-torontoxn_lo0.net.bell.ca (64.230.11.215) 3.343 ms 1.448 ms 1.782 ms
...
Rsync runs over rsh/ssh, which uses TCP, so tcptraceroute would also verify that TCP is not explicitly blocked to the server.
Also you can’t use a port with the traceroute or tcptraceroute commands
Use rsync native and not SSH or HTTPS. Both are not supported by the community server. Only the commercial products do support that …
yap … i know that but cannot get to comunity feeds site even from outside… i´m trying from my network and its not working. … ok… but trying from Port Checker - Check Open Ports Online didn´t work … port 24,443, and any… allways time out…
there must be a way to check if the service is running and accesible from the other side…
as i see it, you got to close your eyes ,cross fingers and thrust in god…
Sorry you are not reading what is suggested here and on your other posts, you need to use RSYNC TCP/873 as destination port. FORGET HTTP / SSH / HTTPS …
1 Like
well … sorry… i´m not familiar with linux, english , nither rsync… i saw it from bricks´s answer…
… anyway… problem solved… port blocked in firewall, even when admin told me “everything is open”
but ovbiously not…
thanks a lot!!!
I know that you have resolved this issue already, but I thought I would add what I think to be the most effective way to troubleshoot the rsync connection to Greenbone’s feed sync servers in case someone else has this issue.
The nping command is part of the nmap tool. It can be used to directly traceroute a TCP connection to a specific port while traceroute and tcptraceroute cannot be configured to test a specific port. This will help identify port-based firewall rules as well as host / IP-based firewall rules.
sudo nping --tcp --traceroute -c 13 -p 873 feed.community.greenbone.net
** Note: nping --tcp command requires sudo or root.
The output here:
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2023-06-28 13:48 EDT
SENT (0.0274s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=1 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (0.0280s) ICMP [192.168.2.1 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=43189 iplen=68 ]
SENT (1.0281s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=2 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (1.0296s) ICMP [64.230.11.215 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=254 id=0 iplen=56 ]
SENT (2.0300s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=3 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (2.0452s) ICMP [64.230.97.188 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=244 id=0 iplen=168 ]
SENT (3.0315s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=4 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (3.0468s) ICMP [64.230.51.151 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=246 id=19613 iplen=168 ]
SENT (4.0330s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=5 id=37878 iplen=40 seq=2348950242 win=1480
SENT (5.0344s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=6 id=37878 iplen=40 seq=2348950242 win=1480
SENT (6.0358s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=7 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (6.0539s) ICMP [64.230.79.73 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=249 id=0 iplen=56 ]
SENT (7.0379s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=8 id=37878 iplen=40 seq=2348950242 win=1480
SENT (8.0392s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=9 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (8.1506s) ICMP [4.69.163.106 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=240 id=0 iplen=56 ]
SENT (9.0398s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=10 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (9.1496s) ICMP [62.67.19.26 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=54 id=1090 iplen=72 ]
SENT (10.0407s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=11 id=37878 iplen=40 seq=2348950242 win=1480
RCVD (10.1505s) ICMP [195.34.175.194 > 192.168.2.251 TTL=0 during transit (type=11/code=0) ] IP [ttl=241 id=0 iplen=56 ]
SENT (11.0417s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=12 id=37878 iplen=40 seq=2348950242 win=1480
SENT (12.0431s) TCP 192.168.2.251:1323 > 45.135.106.143:873 S ttl=13 id=37878 iplen=40 seq=2348950242 win=1480
Max rtt: 111.280ms | Min rtt: 0.551ms | Avg rtt: 47.643ms
Raw packets sent: 13 (520B) | Rcvd: 8 (700B) | Lost: 5 (38.46%)
Nping done: 1 IP address pinged in 13.07 seconds
If there is something wrong with this solution let me know.
thanks again …
but… i used a simples online tool from Port Checker - Check Open Ports Online
if it´s ok … then the problem is inside network…
best regards
