HI, VPC routers (used by single and redundant VPCs) already fixed. Now testing shared/isolated routers.
PR will be available in a few hours. Cheers, Wilder > On 03 Aug 2015, at 11:47, Wilder Rodrigues <wrodrig...@schubergphilis.com> > wrote: > > Yep… that bit I know and it was already in the code. > > > What I just found out was that the DROP was put before there, in a probably > first run of the code. What I changed now was to have the DROP added only > after the control nic is configured. It should work, but I still need to test > it - new RPMs, etc. > > I’m now looking for the place where the port 3922 is added in the case of a > VPC router. > > Hope to get it working still today so I can create a PR. > > Cheers, > Wilder > > >> On 03 Aug 2015, at 11:38, Sanjeev N <sanj...@apache.org> wrote: >> >> I think we need to allow tcp port 3922 in INPUT chain for the host to ssh >> to VR. >> >> On Mon, Aug 3, 2015 at 3:00 PM, Wilder Rodrigues < >> wrodrig...@schubergphilis.com> wrote: >> >>> Hi Sanjeev, >>> >>> I added some comments to the issue on Jira, but will share it here as well >>> since not many people are watching the issue: >>> >>> I updated the CsAddress.py file and deployed a KVM datacenter, with new >>> agent/common RPM packages. The router has now INPUT/FORWARD with DROP >>> instead of ACCEPT. >>> >>> However, it seems to block communication with the host, since the router >>> stays stuck on "starting" state on ACS management server. >>> >>> I managed to access the router via libvirt console command. See details >>> below: >>> >>> [root@kvm2 ~]# virsh console 4 >>> Connected to domain r-4-VM >>> Escape character is ^] >>> >>> root@r-4-VM:~# iptables --list >>> Chain INPUT (policy DROP) >>> target prot opt source destination >>> ACCEPT tcp -- anywhere anywhere tcp dpt:10086 >>> 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 DROP) >>> 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 >>> root@r-4-VM:~# >>> >>> I will compare the new iptables configuration with the old >>> iptables-vpcrouter/iptables-router files. >>> >>> Cheers, >>> Wilder >>> >>> >>>> On 31 Jul 2015, at 06:03, Sanjeev N <sanj...@apache.org> wrote: >>>> >>>> Thanks for working on it Wilder !! >>>> >>>> On Thu, Jul 30, 2015 at 6:05 PM, Wilder Rodrigues < >>>> wrodrig...@schubergphilis.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> We discussed that one yesterday and I already assigned the issue to >>> myself >>>>> on Jira. I will fix it. >>>>> >>>>> Cheers, >>>>> WIlder >>>>> >>>>> >>>>> >>>>>> On 30 Jul 2015, at 14:09, Sanjeev N <sanj...@apache.org> wrote: >>>>>> >>>>>> Agree with Kishan Kavala and Jayapal. >>>>>> >>>>>> On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala < >>> kishan.kav...@citrix.com >>>>>> >>>>>> wrote: >>>>>> >>>>>>> This is a security issue with high impact. >>>>>>> We should treat it as a blocker. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] >>>>>>> Sent: 30 July 2015 02:07 PM >>>>>>> To: <dev@cloudstack.apache.org> <dev@cloudstack.apache.org> >>>>>>> Subject: Re: [Blocker] Default ip table rules on VR >>>>>>> >>>>>>> I see VR ingress traffic is blocked by default from iptables mangle >>>>> table. >>>>>>> But on the guest interface all the traffic is accepted. >>>>>>> Also egress firewall rule will break because of FORWARD policy. >>>>>>> >>>>>>> Thanks, >>>>>>> Jayapal >>>>>>> >>>>>>> On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi < >>>>>>> jayapalreddy.ur...@citrix.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> It is security concern on the VR. All the ingress traffic onto the VR >>>>> is >>>>>>> accepted. >>>>>>>> Let it be blocker. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jayapal >>>>>>>> >>>>>>>> On 30-Jul-2015, at 12:28 PM, Daan Hoogland <daan.hoogl...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I changed it to critical. It is only a blocker if we agree on this >>>>>>>>> list that it is. >>>>>>>>> >>>>>>>>> On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N <sanj...@apache.org> >>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> In latest ACS builds, the ip table rules in VR have ACCEPT as the >>>>>>>>>> default policy in INPUT and FORWARD chains, instead of DROP. >>>>>>>>>> >>>>>>>>>> Created a blocker bug for this issue >>>>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-8688 >>>>>>>>>> >>>>>>>>>> Can somebody please fix it? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sanjeev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Daan >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >
