As principally a concept of philosophical schools, logic may serve in a role in numerous material vocations – such as in any number of legal domains, material vocational domains, and financial domains of vocational practices. Ostensibly, logic may also find a role in any number of more nuanced vocations, such as in prcactices of social sciences and in creative fields of the arts. It may seeem a trivial thing to denote, thus, that a sense of logic may be derived of the technically practical syntax and procedural semantics of any single network firewall configuration framework.
Presently, this article will diverge from the broadly philosophical view as to focus principally about the IPFW firewall architecture, as IPFW providing one available packet filtering interface on a typically built FreeBSD operating system. As the FreeBSD kernel provides a complete firewall architecture corresponding with OS kernel services that may be configured with the ‘ipfw’ shell command and other, corresponding shell command line utilities, this article will endeavor to provide albeit a broad topical overview about services architectures as corresponding immediately with the IPFW shell command line interface – herein, denoted as the IPFW CLI. In this article, albeit broadly, the IPFW architecture will be juxtaposed to the PF and IPF firewall frameworks, such that are also available – as in a manner of a parallel corespondenance to IPFW – in the canonical FreeBSD kernel.
In short synopsis, FreeBSD provides three distinct firewall architectures – such that a network systems administrator may select from, in any development of any number of individual network systems applications. Although it may seem, in a manner, modestly mystifying to a novice administrator, but in respects to the state of the art in FreeBSD kernel applications – such a diversity of firewall frameworks, in a single operating system – it may certainly permit for any manner of a scholastic survey of the individual firewall frameworks, thus available. All three of the individual firewall frameworks – as denoted – are documented in the FreeBSD handbook, such that may serve as a fortuitious manner of a “Starting Point,” for any scholastic review as such.
Administrators’ opinions may vary, as to the nuances of individual firewall designs and of corresponding firewall applications. In the opinions of the author of this article, PF – for instance – provides for a novel manner of a firewall scaling function, such that may be of some use for any number oc applications in rural wireless broadband internetworking – such as, in digital networks applying any manner of a commercial satellite internetworking service – if not also of use in some mobile-to-mobile (M2M) and Internet of Things (IoT) wireless networks. Specifically, the ‘high-latency’ option for PF firewall configuration provides a feature of a seemingly unique nature, across the proverbial “Gang of Three” of firewall architectures available on the FreeBSD OS. Certainly, this may not be the only unique feature that may be discovered of any scholastic survey of the FreeBSD firewall space. By only a small coincidence of geography, it occurs to the considerations of the author of this article, as so.
If in any instance of migrating a firewall configuration across any two of the three available firewall frameworks available in FreeBSD, perhaps any manner of a logical model of firewall services may be developed, as in a manner apropos to the task. As a a network firewall representing a manner of a feature of an operating system – broadly, as a feature of open source softwade systems – a firewall may be studied as a manner of a development onto a framework of packet-oriented communications networking. Thus, one may begin at the conventional OSI Seven Layer Model, such that may be studied as towards developing a manner of a principally vendor-neutral logical model. The OSI Seven Layer Model – broadly – as having developed as a feature of the “State of the Art,” in packet-switched networking services, the same model provides a manner of a normative domain-oriented view about network architectures.
Towards developing a depth of a detailed view, as to how the OSI Seven Layer Model is effectively reified in individual network systems architectures, of course one may begin at the simple characteristics of network media – whether of physical network media or wireless network media, and whether of electromagnetic wireless media or of any novel, if not experimental instances of optical wireless media. As such, the logical model could entail a definition of any number of commonly known digital network signaling protocols, if not towards a principally channel-oriented definition of network media. Thence, any number of software services may be defined to the model, such as begininng at the “Next lowest level” – such as viz a viz logical data types for network interface addressing and procedures of network address resolution in individual network topologies, viz token ring, star, or other topological models. Thence, the interface addresses may be represented in the model as for how those are effecitvely extended with any higher-level addressing schemes, at which point there are the “Lowest level” of network packet formats. Proceeding as to model a TCP/IP network, the model may then be developed as with regards to name resolution services, and thence, secure tunneling and data compression services. Lastly, the model may be extended as to represent each of the connectionless datagram models of UDP applications and the stateful message-oriented models of TCP applications, for how each may be finally realized in a network application protocol such as HTTP or IIOP.
Thus, perhaps it may be understood that any single concrete reification of the OSI Seven Layer Model – essentially, a topical model – may be non-trivial to develop as to any appreciable depth of concrete logical representation. Albeit as a manner of a principally orthogonal diversion from the parimary topical focus of this article, perhaps the outline presented in the previous paragraph may serve towards at least a broad overview of how the OSI Seven Layer Model is realized in any number of practical network systems applications.
As a network firewall effectively residing – in an abstract manner – residing in an application of the OSI Seven Layer Model, but the firewall itself must apply any number of concrete network services, such that would be available as services of any single operating system (OS) in which the respective firewall would be implemented. Thus, beside all of the semantic nature of the OSI Seven Layer Model, but a firewall is implemented as principally a software service in any single operating system. Returning attention, thus, from addressing the vendor-netural logical model – momentarily, avoiding any far detailed description of how the OSI Seven Layer model is effectively realized in FreeBSD – this article returns attention to a domain of computer operating systems, after a brief aside with regards to applications of operating systems. Certainly, no single OS model resides as though in a vacuum.
Any single vendor-neutral architectural model might not as well survive a transition to commercial marketing practices, once addressed into a domain of commercial software development. As with regards to a logical model of TCP/IP networking, perhaps some commercial software developments may serve to not obscure the nature of the underlying architecture – contrasted to any more intensively brand-oriented models, as in which any single concept of software as product may effectively serve to obscure any single of concept of software as a concretely logical construct. However, not every single commercial software product campaign may serve to inherently confuse the nature of software systems design.
Thus, there are the Microsoft products, the OS X products, and the products of so many lesser known commercially branded operating system sales programs, and then there are the architectures of the software products that those same sales programs may endeavor to derive any manner of a commercial capital about. There are also so many free/open source operating systems, ostensibly developed as independent of single capital sales and marketing programs.
In a manner semantically narrower than of any individual “Products Domain,” thus – more narrowly – any single manner of an “Applications Domain” may be observed, such as in a scholastic study of applications of computing services in human society. This article will not propose any single logical model of the latter – that the details of any single concrete, technical architecture may be tedious enough to describe, and that the logical if not creative semantics of any single socio-ethnographic model may seem no less demanding for its scholastic nature. Certainly, not all things of human society may devolve to a statistical oversimplification.
That it is in human society – broadly, thus – where computing systems are applied, of course so many applications of computing may not seem to devolve entirely to a statistical model of material capital. The author of this article proposes that the human nature of applications of computing may seem to be most apparent in a context of any single Small Office/Home Office (SOHO) computing environment – and that, as such, perhaps a SOHO LAN may not seem in all ways analogous to any corporate commercial server farm.
Thus, this article will be developed not as though to focus about the high-volume and no doubt very capital-intensive environment of any manner of a prototypical commercial network. Neither will this article endeavor to present any manner of a tourist’s view of commercial academia – the strange hybrid of marketing and scholarly discourse that develops as of the heavily marketed technologies of individual products developed in a context of computing. Certainly, there was an era when computer systems were developed for not so much of a popular style, as much as for a scientifically reproducible state of the art – the veritable “Old Scrolls” of computer science might serve to provide something of a sense of context to that era. Perhaps it is an era not yet all or entirely lost to contemporary practitioners of product engineering and commercial systems development.
By now, this article has diverged to something of a semantic distance aside to the original topic, the IPFW architecture as a feature developed of the FreeBSD operating system. Not as though to abandon the original thesis concept, simply it may seem as though to trivialize the State of the Art, if any technical material about computing would be presented without a substantial sense of context, as towards a regard about the origins of the products therein applied.
So as to present the following overview beside a further sense of a contextual note as with regards to computer systems diagnostics: Though the marketing and the documentation developed about so many commercial products products may seem, in itself, somehow mystifying, but if there may be any singular concrete sense of nature developed as about computer science, it may theoretically be possible to develop a logical model of any single computer software and hardware product – no matter the aim of the modeling task, and no matter for the depth of marketing about the respective product. Thus, Microsoft Active Directory can be presented in albeit a “Buzkill” manner of view as it representing an amalgam of LDAP, DNS, optionally SQL, optionally Kerberos, and other existing network application protocols all completely described in open, accessible standards – up to the point in which the same protocols are implemented in the singular product, as such.
In a sense, a simple task of defining a logical model of a formal software system may serve – in a regards – towards developing a logical diagnosis of any feature of “Unexpected functionality” or lack of “Expected functionally” in the system thusly modeled. In that the modeling task, as such, may endeavor to develop a manner of a platform-agnostic view of the system being modeled, perhaps it may at least serve to limit any bias of opinion about the model and its reification.
Firewall configuration – as a feature consolidated directly of the design of an operating system kernel – may not be subjected to as much standardization as so many platform-agnostic communication protocols, application data channel interfaces, and hardware forms yet developed to the modern domain of computing. Thus, this article may not suppose to contribute any manner of a structural perspective for international standards organizations. The simple concept of a “Vendor standard” manner of firewall implementation may have to suffice.
Not, then, as though to oversimplify the lateral development of the IPFW firewall architecture in FreeBSD, but to begin at a more practical note: The IPFW command line interface – though it is not all there that there is to the IPFW architecture – rather, the documentation about the IPFW command line interface – as towards a sense not only for firewall configuration definition, but also for diagnostics about firewall configurations – would be lost to this article, perhaps, if this article had begun as so:
In a personal review of my LAN’s present IPFW configuration, I can’t seem to figure out what in my LAN gateway’s IPFW configuration is resulting in some packets getting “lost” – as in any HTTP requests made on the LAN and without a proxy. The concrete nature of that issue, as I am presently seeing it, is that the packets are not being blocked by the firewall – that there is no any kind of a “Connection refused” message being produced to the unproxied HTTP requests, they’re simply resulting in timeout and varaibly “No route to host” (via ‘fetch’) or “Operation time out” (via curl) error messages. Therefore, I believe that the packets are being lost, and I believe that it may be a consequence of the firewall configuration.
The issue is not a very high-priority issue – I can still use HTTP services on the LAN, so long as those HTTP services are communicated through the HTTP proxy on the LAN. For some applications, however, that may not be sufficient. In a manner of a personal sense, I do not believe it is sufficient that I am unable to understand “Why?” as to the nature of the packet lost in unproxied HTTP requests, juxtaposed to the present configuration of the IPFW service on the LAN gateway appliance.
To diagnose this issue, I am not foremost interested in taking a popular scalpel to my LAN’s present IPFW configuration. Thus, I will not be addressing the issue to the forums. Personally, I am not even greatly worried about the issue – it does not serve to interfere with the LAN’s primary functional applications – but is a logical conundrum, moreover a manner of a practical “Show stopper” to some applications on the network.
The IPFW CLI, in itself, provides a manner of a shell-oriented application programming interface for firewall configuration management. On review of the manual page for IPFW, it becomes apparent that there are more topical features of IPFW than have been presented immediately in the practical introduction in the Handbook. This, then, is not a criticism of the FreeBSD handbook – rather, this is a simple effort in extending beyond the handbook’s own imminently practical domain of discourse, while endeavoring to diagnose, sole, and describe an albeit non-blocking issue presently being encountered with regards to my own LAN’s gateway firewall configuration.
Of course, this oblique style of writing would not be sufficient for addressing the matter to a task. If there may be a long-and-short introduction to a task of network systems diagnostics, perhaps this article may at least serve as a manner of a rhetorical overview about the matter. A description of the technical details of it may be begun in a separate article, shortly.
Hardpan Media 