Marcus, here is that output you mentioned -- To avoid this from happening, I run a cronjob to clear the tables ever so often, as to not repopulate and cause issues.


Chain INPUT (policy ACCEPT 13136 packets, 71M bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
  236 19146 BF-cloudbr0  all  --  any    cloudbr0  anywhere             anywhere            PHYSDEV match --physdev-is-bridged
  219 15428 BF-cloudbr0  all  --  cloudbr0 any     anywhere             anywhere            PHYSDEV match --physdev-is-bridged
  219 15428 DROP       all  --  any    cloudbr0  anywhere             anywhere           
    0     0 DROP       all  --  cloudbr0 any     anywhere             anywhere           

Chain OUTPUT (policy ACCEPT 13116 packets, 71M bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain BF-cloudbr0 (2 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
  455 34574 BF-cloudbr0-IN  all  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-is-in --physdev-is-bridged
  446 31622 BF-cloudbr0-OUT  all  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-is-out --physdev-is-bridged
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-out eth0 --physdev-is-bridged

Chain BF-cloudbr0-IN (1 references)
 pkts bytes target     prot opt in     out     source               destination        
    9  2952 i-2-30-def  all  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-in vnet11 --physdev-is-bridged

Chain BF-cloudbr0-OUT (1 references)
 pkts bytes target     prot opt in     out     source               destination        
    8   766 i-2-30-def  all  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-out vnet11 --physdev-is-bridged

Chain i-2-30-VM (1 references)
 pkts bytes target     prot opt in     out     source               destination        
    8   766 DROP       all  --  any    any     anywhere             anywhere           

Chain i-2-30-VM-eg (1 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 RETURN     all  --  any    any     anywhere             anywhere           

Chain i-2-30-def (2 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
    9  2952 ACCEPT     udp  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-in vnet11 --physdev-is-bridged udp spt:bootpc dpt:bootps
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-out vnet11 --physdev-is-bridged udp spt:bootps dpt:bootpc
    0     0 RETURN     udp  --  any    any     66.232.104.214       anywhere            PHYSDEV match --physdev-in vnet11 --physdev-is-bridged udp dpt:domain
    0     0 i-2-30-VM-eg  all  --  any    any     66.232.104.214       anywhere            PHYSDEV match --physdev-in vnet11 --physdev-is-bridged
    8   766 i-2-30-VM  all  --  any    any     anywhere             anywhere            PHYSDEV match --physdev-out vnet11 --physdev-is-bridged


On Apr 19, 2013, at 02:22 PM, Marcus Sorensen <shadow...@gmail.com> wrote:

That's reflected by this line:

ACCEPT tcp -- anywhere anywhere tcp
dpts:vnc-server:synchronet-db

Although we don't know what interfaces it applies to because we don't have
an 'iptables -L -v'

If stopping iptables fixes Maurice's problem it would be interesting to
know, as the rules seem to let VNC through. It should be easy to tcpdump
and see what traffic is actually being blocked because his rules suggest
that VNC is wide open on the KVM host.


On Fri, Apr 19, 2013 at 12:15 PM, Edison Su <edison...@citrix.com> wrote:

> This rule will reject all the ingress activities: "REJECT all --
> anywhere anywhere reject-with icmp-host-prohibited"
> You can try:
> iptables -I INPUT -p tcp -m tcp --dport 5900:6100 -j ACCEPT
> to allow console access.
>
> From: Maurice Lawler [mailto:maurice.law...@me.com]
> Sent: Wednesday, April 17, 2013 7:48 PM
> To: Cloud Dev
> Cc: us...@cloudstack.apache.org; us...@cloudstack.apache.org
> Subject: IP tables blocking KVM/Console
>
> I have stopped iptables at least 15 times, because it keeps blocking my
> console access to my instances. How can I either A) disable Iptables all
> together / b add a rule to allow it's access.
>
> Right now, it has this:
>
> [root@lunder ~]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT udp -- anywhere anywhere udp dpt:bootps
> ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
> ACCEPT tcp -- anywhere anywhere tcp
> dpts:49152:49216
> ACCEPT tcp -- anywhere anywhere tcp
> dpts:vnc-server:synchronet-db
> ACCEPT tcp -- anywhere anywhere tcp dpt:16509
> ACCEPT tcp -- anywhere anywhere tcp dpt:websm
> ACCEPT tcp -- anywhere anywhere tcp dpt:8250
> ACCEPT tcp -- anywhere anywhere tcp
> dpt:empowerid
> ACCEPT tcp -- anywhere anywhere tcp
> dpt:webcache
> ACCEPT all -- anywhere anywhere state
> RELATED,ESTABLISHED
> ACCEPT icmp -- anywhere anywhere
> ACCEPT all -- anywhere anywhere
> ACCEPT tcp -- anywhere anywhere state NEW tcp
> dpt:ssh
> REJECT all -- anywhere anywhere reject-with
> icmp-host-prohibited
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> [root@lunder ~]#
>
> But there was plenty of other rules previously to my stopping it.
>
>
>

Reply via email to