Re: [openstack-dev] FWaaS iptables implementation
Hi Miyashita, The second rule is 'accept' on state being 'established' or 'related'. In case of ICMP, if a request has gone out from inside network, then the reply to that will match this rule. A new ICMP message initiated from outside will not match this rule. I hope I understood your question correctly. Let me know if this addresses your concern. Thanks, -Rajesh Mohan On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro miy...@jp.fujitsu.com wrote: Hi, I want to ask about FWaaS iptables rule implementation. firewall rule are deployed as iptables rules in network node , and ACCEPT target is set at second rule(*). Chain neutron-l3-agent-iv431d7bfbc (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED (*) 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.2.0/231.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.6.0/241.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 0 0 neutron-l3-agent-liD31d7bfbc all -- * * 0.0.0.0/00.0.0.0/0 Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP or other protocol such as UDP/TCP)? This causes some wrong scenario for example... [outside openstack cloud] --- Firewall(FWaaS) -- [inside openstack cloud] 1) admin create Firewall and create Filrewall rule accepting ICMP request from outside openstack cloud, and 2) ICMP request packets incoming from outside to inside, and 3) someday, admin detects that ICMP rule is security vulnerability and create Firewall rule blocking ICMP request from outside. but ICMP request packets still incoming due to ACCEPT rule(*), because ICMP connection still hit rule at second(*). Thanks. kazuhiro MIYASHITA __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][FWaaS] FFE request: fwaas-service-insertion
Hi All, I would like to request FFE for the following patch https://review.openstack.org/#/c/62599/ The design and the patch has gone through many reviews. We have reached out to folks working on other advanced services as well. This will be a first good step towards true service integration with Neutron. Would also allow for innovative service integration. Nachi and Sumit looked at this patch closely and are happy. Akihiro also gave useful comments and I have addressed all his comments. Please consider this patch for merge in I3. Thanks, -Rajesh Mohan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Representing PEM Format file as string
Thanks John. My initial approach is similar to Keystone's. This is mainly to unblock me from making progress on the driver. Nachi is doing the API part. I will discuss with him to explore other options. Can you send us the link to your review? Thanks, -Rajesh Mohan On Mon, Jan 27, 2014 at 6:00 AM, John Dennis jden...@redhat.com wrote: On 01/26/2014 05:36 PM, rajesh_moh...@dell.com wrote: I am working on SSL VPN BP. CA certificate is one of the resources. We decided to use PEM formatted certificates. It is multi-line string 1 -BEGIN CERTIFICATE- 2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD snip 21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW 22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S 23 -END CERTIFICATE- Is there a standard way to represent this as single line string? Maybe there is some other project that passes certificates on command line/url. I am looking for some accepted way to represent PEM formatted file on command line. I am thinking of concatenating all lines into single string and rebuilding the file when configuration file is generated.Will we hit any CLI size limitations if we pass long strings. In general PEM formatted certificates and other X509 binary data objects should be exchanged in the original PEM format for interoperabilty purposes. For command line tools it's best to pass PEM objects via a filename. However, having said that there is at least one place in Openstack which passes PEM data via a HTTP header and/or URL, it's the Keystone token id which is a binary CMS object normally exchanged in PEM format. Keystone strips the PEM header and footer, strips line endings and modifies one of the base64 alphabet characters which was incompatible with HTTP and URL encoding. However what keystone was doing was not correct and in fact did not follow an existing RFC (e.g. URL safe base64). I fixed these problems and in the process wrote two small Python modules base64utils and pemutils to do PEM transformations correctly (plus general utilities for working with base64 and PEM data). These were submitted to both keystone and oslo, Oslo on the assumption they should be general purpose utilities available to all of openstack. I believe these have languished in review purgatory, because I was pulled off to work on other issues I haven't had the time to babysit the review. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Representing PEM Format file as string
Nachi, I did not know that we could give files names. Since we had String in the database, I assumed we need to give string as input. I guess, the neutron client will convert the file to string and then call the API. That should work. Thanks for the clarification. On Mon, Jan 27, 2014 at 10:49 AM, Nachi Ueno na...@ntti3.com wrote: Hi Rajesh May I ask why we need single line representation of PEM format? For CLI, we will use file_name as same as nova keypair-add. We won't specify PEM on the URL. 2014-01-27 Rajesh Mohan rajesh.mli...@gmail.com: Thanks John. My initial approach is similar to Keystone's. This is mainly to unblock me from making progress on the driver. Nachi is doing the API part. I will discuss with him to explore other options. Can you send us the link to your review? Thanks, -Rajesh Mohan On Mon, Jan 27, 2014 at 6:00 AM, John Dennis jden...@redhat.com wrote: On 01/26/2014 05:36 PM, rajesh_moh...@dell.com wrote: I am working on SSL VPN BP. CA certificate is one of the resources. We decided to use PEM formatted certificates. It is multi-line string 1 -BEGIN CERTIFICATE- 2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD snip 21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW 22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S 23 -END CERTIFICATE- Is there a standard way to represent this as single line string? Maybe there is some other project that passes certificates on command line/url. I am looking for some accepted way to represent PEM formatted file on command line. I am thinking of concatenating all lines into single string and rebuilding the file when configuration file is generated.Will we hit any CLI size limitations if we pass long strings. In general PEM formatted certificates and other X509 binary data objects should be exchanged in the original PEM format for interoperabilty purposes. For command line tools it's best to pass PEM objects via a filename. However, having said that there is at least one place in Openstack which passes PEM data via a HTTP header and/or URL, it's the Keystone token id which is a binary CMS object normally exchanged in PEM format. Keystone strips the PEM header and footer, strips line endings and modifies one of the base64 alphabet characters which was incompatible with HTTP and URL encoding. However what keystone was doing was not correct and in fact did not follow an existing RFC (e.g. URL safe base64). I fixed these problems and in the process wrote two small Python modules base64utils and pemutils to do PEM transformations correctly (plus general utilities for working with base64 and PEM data). These were submitted to both keystone and oslo, Oslo on the assumption they should be general purpose utilities available to all of openstack. I believe these have languished in review purgatory, because I was pulled off to work on other issues I haven't had the time to babysit the review. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] FWaaS IceHouse summit prep and IRC meeting
This is good discussion. +1 for using Neutron ports for defining zones. I see Kaiwei's point but for DELL, neutron ports makes more sense. I am not sure if I completely understood the bump-in-the-wire/zone discussion. DELL security appliance allows using different zones with bump-in-the-wire. If the firewall is inserted in bump-in-the-wire mode between router and LAN hosts, then it does makes sense to apply different zones on ports connected to LAN and Router. The there are cases where the end-users apply same zones on both sides but this is a decision we should leave to end customers. We should allow configuring zones in bump-in-the-wire mode as well. On Wed, Oct 23, 2013 at 12:08 PM, Sumit Naiksatam sumitnaiksa...@gmail.comwrote: Log from today's meeting: http://eavesdrop.openstack.org/meetings/networking_fwaas/2013/networking_fwaas.2013-10-23-18.02.log.html Action items for some of the folks included. Please join us for the meeting next week. Thanks, ~Sumit. On Tue, Oct 22, 2013 at 2:00 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Reminder - we will have the Neutron FWaaS IRC meeting tomorrow Wednesday 18:00 UTC (11 AM PDT). Agenda: * Tempest tests * Definition and use of zones * Address Objects * Counts API * Service Objects * Integration with service type framework * Open discussion - any other topics you would like to bring up for discussion during the summit. https://wiki.openstack.org/wiki/Meetings/FWaaS Thanks, ~Sumit. On Sun, Oct 13, 2013 at 1:56 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, For the next of phase of FWaaS development we will be considering a number of features. I am proposing an IRC meeting on Oct 16th Wednesday 18:00 UTC (11 AM PDT) to discuss this. The etherpad for the summit session proposal is here: https://etherpad.openstack.org/p/icehouse-neutron-fwaas and has a high level list of features under consideration. Thanks, ~Sumit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
