No internet access despite configured proxy

Hello,

The first question is whether you really need a proxy, and if so, does 10.0.0.1:3128 correspond to a valid proxy.

Could you perhaps explain how you connect to the Internet (via a box, in a corporate network, etc.)

Then, we need to check your IP configuration to better understand what might explain the problem. What do the commands return:

ip route cat /etc/resolv.conf host www.google.fr # Or: nslookup www.google.fr ping -c2 www.google.fr

Moreover, assuming you have a proxy at this address, what does it return:

ping -c2 10.0.0.1 nmap -p 3128 10.0.0.1 # If needed, install nmap: sudo apt update && sudo apt install nmap

Does this proxy server require authentication (username, password)? If so, you need to provide that information in all the chains you've configured. If that's the case, you need to include them. http://10.0.0.1:3128 becomes http://10.0.0.1:3128

Finally, a proxy is generally defined at the application level. Depending on the application, some look in common locations. For example:

• All applications related to APT look in /etc/apt/apt.conf.d/proxy.conf
• Text-mode applications check the environment variable http_proxy, which can be automatically initialized via /etc/environment and /etc/profile. You can verify that it is initialized with the command: 

  env | grep proxy

• Gnome/KDE applications look at the proxy settings defined in the network settings of the graphical environment

So my last question is: for which application does the proxy not seem to work? If it's for all (apt, the browser, etc.), I wonder if the specified proxy is needed and if so, whether it is correctly specified.

Good luck

Hello

This is a corporate network, so the proxy is essential; without it, there is no internet. It does not require authentication; only the address and the port are necessary.

The thing I did in the meantime is configure the proxy for HTTPS. Respectively in the aforementioned files:

In /etc/apt/apt.conf.d/proxy.conf:

acquire::http::proxy "http://10.0.0.1:3128/"; acquire::https::proxy "http://10.0.0.1:3128/"; 

In /etc/profile:

export http_proxy="http://10.0.0.1:3128/" export https_proxy="http://10.0.0.1:3128/" 

In /etc/environment:

http_proxy="http://10.0.0.1:3128/" https_proxy="http://10.0.0.1:3128/" 

It seems to have worked; here are the results of the suggested commands:

 $ ip route default via 172.16.10.254 dev eno1 proto dhcp metric 20100  169.254.0.0/16 dev eno1 scope link metric 1000  172.16.10.0/24 dev eno1 proto kernel scope link src 172.16.10.187 metric 100 

 $ cat /etc/resolv.conf nameserver 127.0.0.53 options edns0 trust-ad search claudel-vitry.local

 $ host www.google.fr www.google.fr has address 142.250.201.163 www.google.fr has IPv6 address 2a00:1450:4007:81a::2003

 ping -c2 10.0.0.1 64 bytes from 10.0.0.1: icmp_seq=1 ttl=63 time=0.929 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=63 time=0.694 ms --- ping statistics for 10.0.0.1 --- 2 packets transmitted, 2 received, 0% packet loss, time 1027 ms rtt min/avg/max/mdev = 0.694/0.811/0.929/0.117 ms

 nmap -p 3128 10.0.0.1 Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-13 18:47 CET Couldn't open a raw socket. Error: Permission denied (13)

Is everything okay? Does the last error have an impact?

Thank you

Hello,

Short answer

• Yes, everything is fine.
• Your problem was that the addresses you were trying to access had to be reached via HTTPS, not HTTP, and since it’s not the same protocol, you indeed needed to configure the environment variable https_proxy.
• You can ignore the last error; it’s just that you didn’t run nmap with administrative rights.

Detailed answer

The various commands I had you run were meant to diagnose the possible causes of the issue:

• The first two commands show that the IP configuration is correct on this machine:
  • ip route shows that you have a default route
  • cat /etc/resolv.conf shows that you have DNS servers configured
• The third shows that DNS resolution is working (meaning the configured DNS server is correct)
• The fourth shows that traffic is flowing (at least in ICMP) between your machine and www.google.fr, which means it’s not a firewall issue.
• The fifth would have been useful if we’d noticed that traffic was passing in ICMP but not in HTTP(S). The nmap command (which must be run with administrative rights, typically as root or prefixed with sudo) checks if a host (here 10.0.0.1) is responding and what its open ports are (in this case, we specifically probe port 3128). The command failed simply because you ran it as a regular user (your user, unlike root, does not have permission to open raw sockets—i.e., sockets in which we manually construct the entire packet) necessary for nmap to function correctly.

Best of luck

Thank you very much for these details; it is very helpful to have so much explanation when you are a novice.

Is there a way to also check that my fog service on this machine will successfully deploy images? If the proxy is configured this way, will it allow PXE connections between the other machines on the network?

Hello.

In response to message #4 :

Is there any way to also check if my fog service on this machine will successfully deploy images?

Probably, we would need to specify which software is involved. But in a new discussion thread since it's a new problem.

If the proxy is configured this way, will it allow connections via PXE between other machines on the network?

As I mentioned in my message #2, the proxy is an application consideration, which is generally designed to check specific places to see if a proxy has been configured or not (typically, the environment variables http_proxy and https_proxy, a dedicated configuration file (in the case of APT), or the gnome / KDE settings regarding most graphical applications.

Consequently, the proxy is only looked for on the machine that is running the HTTP(S) client (whether it's a web browser, package manager, or anything that establishes an HTTP(S) connection), so the proxy configuration is strictly local to the client machine.

In short, for your other machines to benefit from the proxy configuration, they need to set up the proxy locally themselves.

Good luck