Hi Gaurav, Network mode should be bridge for SG rules work.
Some of security group rules (iptables rules) are configured match the traffic in/out from the bridge. Also eatables rules needs bridge. Cloudstack Basic and Advanced needs bridge mode for SG networks. Thanks, Jayapal 1. On 20-Jan-2014, at 3:55 PM, Gaurav Aradhye <gaurav.arad...@clogeny.com> wrote: > Hi Jayapal, > > CSP is installed but the network mode is set to openvswitch. Should it be > "bridge"? > > Here are few doubts. > > 1) Does Security Group feature always requires network mode set to bridge > irrespective of basic or advanced zone setup? > > 2) In what scenarios we will need it to be openvswitch / bridge? And why > exactly? I reckon openvswitch has more features than the basic bridge > networking mode. > > > Regards, > Gaurav > > > On Mon, Jan 20, 2014 at 2:18 PM, Jayapal Reddy Uradi < > jayapalreddy.ur...@citrix.com> wrote: > >> Hi Gaurav, >> >> Did you install CSP in xenserver ? >> Is host network mode set to bridge ? >> check file /etc/xensource/network.conf for 'bridge' >> >> From the host iptables, there are no SG rules got configured. >> >> Thanks, >> Jayapal >> >> >> >> >> On 20-Jan-2014, at 12:27 PM, Gaurav Aradhye <gaurav.arad...@clogeny.com> >> wrote: >> >>> Hello all, >>> >>> I am facing issue while SSHing to VM in security groups enabled advanced >>> zone (XenServer host) even after applying the ingress rule for the >> security >>> group in which VM is deployed. >>> >>> Also, even if I can see the ingress rule being applied through API >> listing >>> and on UI, I can't see the iptables on host being updated after >>> adding/removing ingress rule. >>> >>> Is there any existing problem with XenServer regarding this? I read on >> few >>> blogs about some people encountering similar issue with Xenserver. I have >>> not yet tried on KVM. >>> >>> The output of command "iptables -L -v -n" on host is as following. >>> >>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes) >>> pkts bytes target prot opt in out source >>> destination >>> 0 0 ACCEPT 47 -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> 109M 110G RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> >>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) >>> pkts bytes target prot opt in out source >>> destination >>> 0 0 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> >>> Chain OUTPUT (policy ACCEPT 91M packets, 149G bytes) >>> pkts bytes target prot opt in out source >>> destination >>> >>> Chain RH-Firewall-1-INPUT (2 references) >>> pkts bytes target prot opt in out source >>> destination >>> 54M 76G ACCEPT all -- lo * 0.0.0.0/0 >>> 0.0.0.0/0 >>> 8430 520K ACCEPT icmp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 icmp type 255 >>> 0 0 ACCEPT esp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> 0 0 ACCEPT ah -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> 0 0 ACCEPT udp -- * * 0.0.0.0/0 >>> 224.0.0.251 udp dpt:5353 >>> 0 0 ACCEPT udp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 udp dpt:631 >>> 0 0 ACCEPT tcp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 tcp dpt:631 >>> 0 0 ACCEPT udp -- xenapi * 0.0.0.0/0 >>> 0.0.0.0/0 udp dpt:67 >>> 47M 32G ACCEPT all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 state RELATED,ESTABLISHED >>> 0 0 ACCEPT udp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 state NEW udp dpt:694 >>> 19 1132 ACCEPT tcp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 state NEW tcp dpt:22 >>> 3919 204K ACCEPT tcp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 state NEW tcp dpt:80 >>> 346K 21M ACCEPT tcp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 state NEW tcp dpt:443 >>> 7721K 1583M REJECT all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 reject-with icmp-host-prohibited >>> >>> >>> Any directions? >>> >>> Regards, >>> Gaurav >> >>
