I ran into the same firewall issue with Xen the first time I tried a clean install of CS 4.0.1 with XS 6.02 and CentOS 6.2. After a few days of trying to determine the cause, I wiped the management server and hosts and reinstalled. I was never able to duplicate that bug.
-----Original Message----- From: Carlos Reátegui [mailto:create...@gmail.com] Sent: Tuesday, April 30, 2013 10:49 PM To: users@cloudstack.apache.org Subject: Re: SSVM unable to connect to DNS On Apr 30, 2013, at 7:09 PM, Ahmad Emneina <aemne...@gmail.com> wrote: > What version cloudstack are you running. First time hearing of this issue, I'd imagine its a bug. 4.0.1 from Ubuntu package. Hosts are XS 6.0.2 fully patched up. Don't know if it makes a difference but I don't recall having this problem when I did not use network bonds. > > Ahmad > > On Apr 30, 2013, at 6:32 PM, Carlos Reategui <create...@gmail.com> wrote: > >> I decided to stop iptables on the host and now the SSVM works and is >> able to get to DNS and download the default Centos template. Is this >> a known issue? >> >> This is what it looked like before I stopped it: >> >> [root@srvengxen01 ~]# iptables -L >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> RH-Firewall-1-INPUT all -- anywhere anywhere >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> RH-Firewall-1-INPUT all -- anywhere anywhere >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain RH-Firewall-1-INPUT (2 references) >> target prot opt source destination >> ACCEPT all -- anywhere anywhere >> ACCEPT icmp -- anywhere anywhere icmp any >> ACCEPT esp -- anywhere anywhere >> ACCEPT ah -- anywhere anywhere >> ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns >> ACCEPT udp -- anywhere anywhere udp dpt:ipp >> ACCEPT tcp -- anywhere anywhere tcp dpt:ipp >> ACCEPT udp -- anywhere anywhere udp dpt:bootps >> ACCEPT all -- anywhere anywhere state >> RELATED,ESTABLISHED >> ACCEPT udp -- anywhere anywhere state NEW udp >> dpt:ha-cluster >> ACCEPT tcp -- anywhere anywhere state NEW tcp >> dpt:ssh >> ACCEPT tcp -- anywhere anywhere state NEW tcp >> dpt:http >> ACCEPT tcp -- anywhere anywhere state NEW tcp >> dpt:https >> REJECT all -- anywhere anywhere reject-with >> icmp-host-prohibited >> >> >> >> On Tue, Apr 30, 2013 at 6:19 PM, Carlos Reategui <create...@gmail.com>wrote: >> >>> Looks like my previous email only went to Ahmad... >>> >>> To add to my below response. I also installed bind9 on my >>> management server and set it up as a caching dns to rule out issues >>> with our corporate MS dns servers and still does not work. >>> >>> >>> >>> On Tue, Apr 30, 2013 at 3:41 PM, Carlos Reategui <car...@reategui.com>wrote: >>> >>>> >>>> On Tue, Apr 30, 2013 at 3:18 PM, Ahmad Emneina <aemne...@gmail.com>wrote: >>>> >>>>> looks like you cant route out to the internet. can you ping >>>>> 8.8.8.8 directly from the ssvm? >>>> >>>> Network connectivity appears fine. As you can see from the test >>>> script it is able to ping the internal DNS server. I am also able >>>> to ping Google's DNS: >>>> >>>> root@s-1-VM:~# ping 8.8.8.8 >>>> PING 8.8.8.8 (8.8.8.8): 56 data bytes >>>> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=45 time=30.694 ms >>>> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=23.546 ms >>>> >>>> However I just recalled our corporate network does not allow >>>> external dns so I need to stick to the internal one that the SSVM >>>> is already configured for. >>>> >>>> The odd thing is if I try to telnet to port 53 it says no route to >>>> host (Is there a similar way to test a udp connection?): >>>> root@s-1-VM:~# telnet 172.30.20.176 53 Trying 172.30.20.176... >>>> telnet: Unable to connect to remote host: No route to host >>>> >>>> But yet a ping works. >>>> >>>> root@s-1-VM:~# ping 172.30.20.176 >>>> PING 172.30.20.176 (172.30.20.176): 56 data bytes >>>> 64 bytes from 172.30.20.176: icmp_seq=0 ttl=127 time=0.690 ms >>>> 64 bytes from 172.30.20.176: icmp_seq=1 ttl=127 time=0.674 ms >>>> 64 bytes from 172.30.20.176: icmp_seq=2 ttl=127 time=0.674 ms >>>> >>>> Traceroute looks ok: >>>> root@s-1-VM:~# traceroute -n 172.30.20.176 traceroute to >>>> 172.30.20.176 (172.30.20.176), 30 hops max, 60 byte packets >>>> 1 172.30.45.32 0.273 ms !X 0.235 ms !X 0.211 ms !X >>>> >>>> any other ideas? >>>
