Ubuntu – Apt-cacher-ng not responcible to vm-client


I did not manage to get apt-cacher-ng working in network.
I wonder which of all its prerequisites are still not fulfilled (?)
Maybe someone will come with deciding hint.
Furthermore, while on troubleshooting several questions arise on my side.
Also, few facts are suggesting it is the apt-cacher-ng issue rather than networking.

Below the situation description:
computer A: virtual machine with apt-cacher-ng installed and in operation.
computer B: quite regular virtual machine connects to comp. A instead of
going to public repository for package installation/update.

Those two virt machines run on one single physical host and for both Ubuntu 15.10 is used as guest OS; used virtualization solution is VmWare Fusion. Both virt. machines use Fusion Internet Sharing for network connection. apt-cacher-ng was installed using Ubuntu's package management. Package management claims it is the 0.8.5-1ubuntu0.1 version. No customization was made on apt-cacher-ng, except for CacheDir setting.
Firewall is off on computer A.
Comp B' apt-get is configured in following way: /etc/apt/apt.conf.d/01proxy, the file 01proxy reads a single line Acquire::http::Proxy "http://ip6-<comp-A-ip>:3142";

Comp B is not able to connect to apt-cacher-ng, sudo apt-get update gets hanged in very beginning when the message reads connecting to ip6-comp-A-ip:3142.End of problem

However, following is working fine
All the achieved is merely to update / install packages on computer A through apt-cacher-ng.
No problems when comp B connects to public repositories directly and bypassing apt-cacher-ng.
If to start samba server on computer A and setup a file share then to connect to this share from computer B all works fine.
Also computer B can successfully ping comp A.
Physical host can successfully ping comp A too.
Also it is possible to have Firefox on comp B and open http://<comp-A-ip>:3142/acng-report.html>.
End of stuff working fine

Daemon is started by init.d with command line option pointing to socket path.
That's the point where I have to wonder, because working local client (same virt. machine) is using comp A' ip address, not a socket.

Best Answer