VestaCP stop resolving names on fresh install (LXC Container)

[amvidalrc]

Operating System (OS/VERSION):

Debian 9, CentOS 7

VestaCP Version:

vesta/stable,now 0.9.8-19 amd64 [installed]

Installed Software (what you got with the installer):

Full package (Including PostgreSQL, Remi) without Quota

Steps to Reproduce:

Over Proxmox:

• New LXC Container with Debian 9

• Ping Ok

• apt update

• apt upgrade -y

• apt install curl -y

• curl -O http://vestacp.com/pub/vst-install.sh

• bash vst-install.sh --nginx yes --apache yes --phpfpm no --named yes --remi yes --vsftpd yes --proftpd no --iptables yes --fail2ban yes --quota yes --exim yes --dovecot yes --spamassassin yes --clamav yes --softaculous yes --mysql yes --postgresql yes

• When installation ends, ping any host, not working. resolv.conf its OK. Ping to any IP its ok:

root@vestaCP:~# ping google.com ^C root@vestaCP:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=5.00 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=5.02 ms ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 5.008/5.016/5.024/0.008 ms

Related Issues/Forum Threads:

NO found nothing.

Other Notes:

Nothing 👍 Checked the issue happen in CentOS 7 too.

[amvidalrc]

This is the last step that Vesta Installer do correctly:

--2018-03-22 16:54:05-- http://c.vestacp.com/ubuntu/16.04/fail2ban.tar.gz Resolving c.vestacp.com (c.vestacp.com)... 104.236.66.100 Connecting to c.vestacp.com (c.vestacp.com)|104.236.66.100|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 777 [application/octet-stream] Saving to: 'fail2ban.tar.gz'

fail2ban.tar.gz 100%[========================================================================================>] 777 --.-KB/s in 0s

2018-03-22 16:54:05 (158 MB/s) - 'fail2ban.tar.gz' saved [777/777]

At this point, ping stop resolving.

Confirmed happening in Ubuntu 16.04 too.

[Skamasle]

In that step vesta configure firewall and fail2ban

Check your firewall rules, check your LXC and check if your node have all iptables modules

[amvidalrc]

I have checked and everything its OK. I have old proxmox running OK, its happening only with the latest vestacp version.

[amvidalrc]

If I install without iptables and fail2ban, everything goes fine.

[noogen]

I also maintain a docker container for VestaCP with ubuntu 16.04 - https://github.com/niiknow/vestacp. Beside occasionally having weird DNS issue with antivirus definition download part of the install, I don't have any issue with the install. Here are my builds, you can check the detail of builds are fine: https://hub.docker.com/r/niiknow/vestacp/builds/

[jeret15]

I had the same problem on my Ubuntu 16.04 container. Upgrading the Proxmox pve kernel (to version 4.15.17-8) on the hypervisor seems to have fixed the problem for me.

[luizjr]

I have the same problem. Proxmox LXC with Ubuntu 16.04 I installed the Latest Version. But after that to ping ping or external connections

[luizjr]

@amvidalrc Hello. Today I have already solved this problem here. I am using Proxmox in OVH, I created an LXC and before starting everything I added permission in Firewall Container (LXC).

Notice how it was in the picture.

[trestylez]

I just experienced the same issue. Looks like the iptable rules does not allow external DNS lookups, so if you use an external DNS you should get the IP from /etc/resolve.conf and add the following rules which fixed the issue for me: iptables -A OUTPUT -p udp -d --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p udp -s --sport 53 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp -d --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp -s --sport 53 -m state --state ESTABLISHED -j ACCEPT

[JOduMonT]

I have the same issue with

VestaCP 0.9.8 on a Debian 9 turning as a unprivileged container under Proxmox 5.2.1

VestaCP is installed with this command :

bash vst-install.sh --nginx yes --phpfpm yes --apache no --mysql yes \ --iptables yes --fail2ban yes --quota yes \ --exim no --dovecot no --spamassassin no --clamav no \ --softaculous no --named no --remi no \ --vsftpd no --proftpd no \ --postgresql no \ --hostname \ --email \ --password

After finishing the install, before a reboot;

1. PING is able to resolve www.com and ttt.com (yes they are real website)
2. after the reboot PING is unable to resolve www.com and ttt.com but still working for IP like 8.8.8.8

If I turn of IPTables ping resolve anything

[JOduMonT]

@trestylez where did you execute these ?

1. on the vesta guest or directly on the proxmox host ?

2. your container was privileged ?

[JOduMonT]

still investigating on this,

• @luizjrdeveloper; I tried your trick without success, but maybe it's because my container is unprivileged

anyway I found this message which probably point in the right direction

just after installing fail2ban

--2018-07-27 13:31:10-- http://c.vestacp.com/debian/9/fail2ban.tar.gz Resolving c.vestacp.com (c.vestacp.com)... 104.236.66.100 Connecting to c.vestacp.com (c.vestacp.com)|104.236.66.100|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 712 [application/octet-stream] Saving to: 'fail2ban.tar.gz' fail2ban.tar.gz 100%[=================>] 712 --.-KB/s in 0s
2018-07-27 13:31:10 (177 MB/s) - 'fail2ban.tar.gz' saved [712/712]

errors start with :

chattr: Permission denied while setting flags on /home/admin/conf mv: cannot move '/usr/local/vesta/data/ips/' to a subdirectory of itself, '/usr/local/vesta/data/ips/192.168.1.8' sed: -e expression #1, char 0: no previous regular expression mount: cannot remount rpool/data/subvol-8888-disk-1 read-write, is write-protected

than after this vesta start to being unable to resolve including himself

sudo: unable to resolve host vesta.dev.localdomain: Connection timed out

but again; if I stop IPTables services vesta works fine.

[dpeca]

No, it's another 'bug' - https://github.com/serghey-rodin/vesta/commit/f68bb795deb153bbb0b9da3a03b0f7377455bee9#commitcomment-29626998 I believe it's not related with this issue, that is described in this topic.

[trestylez]

@jodumont unprivileged container and DNS iptable rules run on the container itself.

[JOduMonT]

@trestylez sadly these rules are already and by default in VestaCP

root@vesta:~# iptables -L Chain INPUT (policy DROP) target prot opt source destination
f2b-sshd tcp -- anywhere anywhere multiport dports ssh fail2ban-VESTA tcp -- anywhere anywhere tcp dpt:8083 fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh ACCEPT all -- vesta.mydomain.com anywhere
ACCEPT all -- localhost anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere multiport dports http,https ACCEPT tcp -- anywhere anywhere multiport dports ftp,12000:12100 > ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere multiport dports smtp,urd,submission,2525 ACCEPT tcp -- anywhere anywhere multiport dports pop3,pop3s ACCEPT tcp -- anywhere anywhere multiport dports imap2,imaps ACCEPT tcp -- anywhere anywhere multiport dports mysql,postgresql ACCEPT tcp -- anywhere anywhere tcp dpt:8083 ACCEPT icmp -- anywhere anywhere

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Chain f2b-sshd (1 references) target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere

Chain fail2ban-SSH (1 references) target prot opt source destination
RETURN all -- anywhere anywhere

Chain fail2ban-VESTA (1 references) target prot opt source destination
RETURN all -- anywhere anywhere

[JOduMonT]

just to be sure;

vesta works perfectly as a unprivileged lxc container debian when iptables is disabled

bash vst-install.sh --nginx yes --phpfpm yes --apache no --named yes --remi no --vsftpd yes --proftpd no --iptables yes --fail2ban yes --quota no --exim no --dovecot no --spamassassin no --clamav no --softaculous no --mysql yes --postgresql no

than after the install update-rc.d -f iptables remove

and FYI no i'm not that crazy;

I have a frontend firewall (pfSense) who allow only http/https on this container.

[marph86]

I have unprivileged LXC. Malfunctioning FW is wrong.. ISPconfig with iptables + Fail2ban works correctly. I wanted to exchange ISPconfig for VESTACP. Thank you for repairing:) I can be assisted with the test.

[Azzazello1979]

I just experienced the same issue. Looks like the iptable rules does not allow external DNS lookups, so if you use an external DNS you should get the IP from /etc/resolve.conf and add the following rules which fixed the issue for me: iptables -A OUTPUT -p udp -d --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p udp -s --sport 53 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp -d --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp -s --sport 53 -m state --state ESTABLISHED -j ACCEPT

trestyley can you please elaborate on what you are doing here. I have external dns so I unchecked the the "manage DNS" when I added domains. My problem is what you describe here, Looks like the iptable rules does not allow external DNS lookups. However the commands gave me errors in sh: Bad argument `53'. Also what do you mean by you should get the IP from /etc/resolve.conf... ? Do I have to append that file? Get the ip from that file and do what with them? There are two nameserver ip addresses in that file. Thank you!

Everything times out like pinging a domain, using wget, even cronjobs dont work.