[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718474#comment-14718474
 ] 

Wilder Rodrigues commented on CLOUDSTACK-8688:
----------------------------------------------

Current status:

Isolated Netowrk
Redundant Netowrk
Single VPC
Redundant VPC

FIXED

Working on Shared Network (dhcpsrvr)

We also fixed the forwarding rules for the Redundant Networks

If I can't finish the shared networks today, I will create a partial PR with 
the other fixes.

Cheers,
Wilder 

> Default policy for INPUT and FORWARD chain is ACCEPT in VR filter table
> -----------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8688
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8688
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Virtual Router
>    Affects Versions: 4.6.0
>         Environment: Latest build from ACS master.
> Zone type: Advanced
>            Reporter: Sanjeev N
>            Assignee: Wilder Rodrigues
>            Priority: Blocker
>             Fix For: 4.6.0
>
>
> Defualt policy for INPUT and FORWARD chain is ACCEPT in VR filter table
> Steps to reproduce the issue:
> =======================
> 1.Bring up CS in advanced zone with any supported hypervisor (e.g. Xenserver)
> 2.Create an isolated network with Network Offering 
> "DefaultIsolatedNetworkOfferingWithSourceNatService"
> 3.Deploy one guest vm within that network
> Result:
> =======
> IP tables rules on the VR created are as follows:
> root@r-7-VM:~# iptables --list
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> NETWORK_STATS  all  --  anywhere             anywhere
> ACCEPT     all  --  anywhere             vrrp.mcast.net
> ACCEPT     all  --  anywhere             225.0.0.50
> ACCEPT     all  --  anywhere             anywhere             state 
> RELATED,ESTABLISHED
> ACCEPT     icmp --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     all  --  anywhere             vrrp.mcast.net
> ACCEPT     all  --  anywhere             225.0.0.50
> ACCEPT     all  --  anywhere             anywhere             state 
> RELATED,ESTABLISHED
> ACCEPT     icmp --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
> ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http 
> state NEW
> ACCEPT     tcp  --  anywhere             anywhere             tcp 
> dpt:http-alt state NEW
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> NETWORK_STATS  all  --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere             state 
> RELATED,ESTABLISHED
> ACCEPT     all  --  anywhere             anywhere             state NEW
> ACCEPT     all  --  anywhere             anywhere             state 
> RELATED,ESTABLISHED
> ACCEPT     all  --  anywhere             anywhere             state 
> RELATED,ESTABLISHED
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> NETWORK_STATS  all  --  anywhere             anywhere
> Chain NETWORK_STATS (3 references)
> target     prot opt source               destination
>            all  --  anywhere             anywhere
>            all  --  anywhere             anywhere
>            tcp  --  anywhere             anywhere
>            tcp  --  anywhere             anywhere
> But the Default policy for INPUT and FORWARD chain should be DROP instead of 
> ACCEPT. Otherwise all the traffic would be allowed to VR.
> Same is the case with VPC and Shared network as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to