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 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
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 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 : > > 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 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 > >> > > >> > 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] 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 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 > > > > 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] 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 wrote: > 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 > 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
[openstack-dev] Advanced Services and Core plugins
I wrote a vendor specific fwaas-driver for our firewall (I also wrote the iptables reference fwaas driver). As per my understanding, the driver demux happens in L3 agent. Since we also wanted to enable our physical appliance for Fwaas, I had to extend L3 agent for insert the firewall into Neutron router. Ignoring service-insertion changes for now, if we just take the fwaas-driver demux happening in L3 agent, will this work with all core-plugins? When I look at other core-plugins (NVP or Big Switch), I see that L3 agent is not used (or not started).Does this mean that we have to have multiple implementations of fwaas-driver? As a firewall vendor, I would have expected that I write one one driver and it would work with all core-plugins. Is there some way this could be done? Is it possible with multi-host mode where one host runs L3 agent(and all advanced services can be used through this host) while other network services may be provided through vendor-specific core plugins. I am not sure if this is a good analogy. In Nova, we have different hypervisors being supported at the same time. For Neutron, can we have different core-plugins work at the same time. With the focus slowly increasing on advanced services and service insertion, is there a framework that we could follow that will work with all core-plugins. 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] devstack + neutron fails on firewall_driver
The links for the error messages are failing for me. Can you send me the actual error message? Thanks. On Thu, Aug 1, 2013 at 9:51 AM, James Kyle wrote: > Morning, > > I'm having some issues getting devstack + neutron going. > > If I don't use Q_USE_DEBUG_COMMAND, it completes and notes that the l3 > agent has failed to start. Here's a paste of the stack.sh error and the > stack trace from q-l3 => https://gist.github.com/jameskyle/6133049 > > If I do use the debug command, this is the error/logs I get: > https://gist.github.com/jameskyle/6133125 > > And this is my localrc https://gist.github.com/jameskyle/6133134 > > Currently running on an ubuntu 12.04 vm. > > The behavior is somewhat recent, last week or so. But I can't find any > references to the issue in bugs. > > Thanks for any input! > > Cheers, > > -james > ___ > 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
