2. FreeBSD Doc
  3. articles_filtering-bridge
  4. Spanish
  5. Translate

Translation

(itstool) path: sect1/para
Let's look at an example setup. Note first that at the top of <filename>/etc/rc.firewall</filename> there are already standard rules for the loopback interface <filename>lo0</filename>, so we should not have to care for them anymore. Custom rules should be put in a separate file (say <filename>/etc/rc.firewall.local</filename>) and loaded at system startup, by modifying the row of <filename>/etc/rc.conf</filename> where we defined the <option>open</option> firewall:
563/4700
Context English Spanish State
Before rebooting in order to load the new kernel or the required modules (according to the previously chosen installation method), you have to make some changes to the <filename>/etc/rc.conf</filename> configuration file. The default rule of the firewall is to reject all IP packets. Initially we will set up an <option>open</option> firewall, in order to verify its operation without any issue related to packet filtering (in case you are going to execute this procedure remotely, such configuration will avoid you to remain isolated from the network). Put these lines in <filename>/etc/rc.conf</filename>: Antes de reiniciar para cargar el nuevo kernel o los módulos requeridos (de acuerdo con el método de instalación elegido anteriormente) debe realizar algunos cambios en el archivo de configuración <filename>/etc/rc.conf</filename>. La regla predeterminada del firewall es rechazar todos los paquetes IP. Inicialmente configuraremos un firewall en modo <option>open</option> para verificar que funciona sin ningún problema en relación con el filtrado de paquetes (en el caso de que vaya a ejecutar este procedimiento de forma remota dicha configuración evitará que permanezca aislado de la red). Coloque estas líneas en el archivo <filename>/etc/rc.conf</filename>:
firewall_enable="YES"
firewall_type="open"
firewall_quiet="YES"
firewall_logging="YES" 		firewall_enable="YES"
firewall_type="open"
firewall_quiet="YES"
firewall_logging="YES"
The first row will enable the firewall (and will load the module <filename>ipfw.ko</filename> if it is not compiled in the kernel), the second one to set up it in <option>open</option> mode (as explained in <filename>/etc/rc.firewall</filename>), the third one to not show rules loading and the fourth one to enable logging support. La primera línea activará el firewall (y cargará el módulo <filename>ipfw.ko</filename> si no está compilado en el kernel), la segunda lo configurará en modo <option>open</option> (como se explica en el archivo <filename>/etc/rc.firewall</filename>), la tercera hará que no se muestren la carga de las reglas y la cuarta habilitará el soporte de logging.
About the configuration of the network interfaces, the most used way is to assign an IP to only one of the network cards, but the bridge will work equally even if both interfaces or none has a configured IP. In the last case (IP-less) the bridge machine will be still more hidden, as inaccessible from the network: to configure it, you have to login from console or through a third network interface separated from the bridge. Sometimes, during the system startup, some programs require network access, say for domain resolution: in this case it is necessary to assign an IP to the external interface (the one connected to Internet, where <acronym>DNS</acronym> server resides), since the bridge will be activated at the end of the startup procedure. It means that the <filename>fxp0</filename> interface (in our case) must be mentioned in the ifconfig section of the <filename>/etc/rc.conf</filename> file, while the <filename>xl0</filename> is not. Assigning an IP to both the network cards does not make much sense, unless, during the start procedure, applications should access to services on both Ethernet segments. En cuanto a la configuración de las interfaces de red la forma más utilizada es asignar solo una IP a una de las tarjetas de red; el bridge funcionará igualmente, aunque ambas interfaces tengan una o no tengan ninguna IP configurada. En el último caso (IP-less) la máquina bridge quedará aún más oculta, ya que es inaccesible desde la red. Para configurarla, debe iniciar sesión desde la consola o mediante una tercera interfaz de red separada del bridge. A veces durante el inicio del sistema algunos programas requieren acceso a la red, por ejemplo para la resolución del dominio. En este caso es necesario asignar una IP a la interfaz externa (la que está conectada a Internet, donde se encuentra el servidor <acronym>DNS</acronym>) ya que el bridge se activará al final del procedimiento de arranque. Esto significa que la interfaz <filename>fxp0</filename> (en nuestro caso) debe añadirse en la sección ifconfig del archivo <filename>/etc/rc.conf</filename>, mientras que <filename>xl0</filename> no. Asignar una IP a ambas tarjetas de red no tiene mucho sentido, a menos que durante el procedimiento de inicio las aplicaciones tengan que acceder a servicios en ambos segmentos Ethernet.
There is another important thing to know. When running IP over Ethernet, there are actually two Ethernet protocols in use: one is IP, the other is <acronym>ARP</acronym>. <acronym>ARP</acronym> does the conversion of the IP address of a host into its Ethernet address (<acronym>MAC</acronym> layer). In order to allow the communication between two hosts separated by the bridge, it is necessary that the bridge will forward <acronym>ARP</acronym> packets. Such protocol is not included in the IP layer, since it exists only with IP over Ethernet. The FreeBSD firewall filters exclusively on the IP layer and therefore all non-IP packets (<acronym>ARP</acronym> included) will be forwarded without being filtered, even if the firewall is configured to not permit anything. Hay otra cosa importante que hay que saber. Cuando se ejecuta IP over Ethernet, en realidad hay dos protocolos Ethernet en uso: uno es IP, el otro es <acronym>ARP</acronym>. <acronym>ARP</acronym> realiza la conversión de la dirección IP de un host a su dirección de Ethernet (capa <acronym>MAC</acronym>). Para permitir la comunicación entre dos hosts separados por el bridge, es necesario que el bridge reenvíe los paquetes <acronym>ARP</acronym>. Dicho protocolo no está incluido en la capa IP, ya que solo existe con IP over Ethernet. El firewall de FreeBSD filtra exclusivamente en la capa IP y, por lo tanto, todos los paquetes no IP (<acronym>ARP</acronym> incluido) se reenvían sin ser filtrados, aunque el firewall esté configurado para no permitir nada.
Now it is time to reboot the system and use it as before: there will be some new messages about the bridge and the firewall, but the bridge will not be activated and the firewall, being in <option>open</option> mode, will not avoid any operations. Ahora es el momento de reiniciar el sistema y usarlo como antes: habrá algunos mensajes nuevos sobre el bridge y el firewall, pero el bridge no se activará y el firewall, en el modo <option>open</option>, no bloqueará ninguna operación.
If there are any problems, you should sort them out now before proceeding. Si hay algún problema, debe solucionarlo ahora antes de continuar.
Enabling the Bridge Habilitando el bridge
At this point, to enable the bridge, you have to execute the following commands (having the shrewdness to replace the names of the two network interfaces <filename>fxp0</filename> and <filename>xl0</filename> with your own ones): En este momento para habilitar el bridge debe ejecutar los siguientes comandos (no olvide reemplazar los nombres de las dos interfaces de red <filename>fxp0</filename> y <filename>xl0</filename> por las suyas):
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.config=fxp0:0,xl0:0</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.ipfw=1</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.enable=1</userinput> 		<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.config=fxp0:0,xl0:0</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.ipfw=1</userinput>
<prompt>#</prompt> <userinput>sysctl net.link.ether.bridge.enable=1</userinput>
The first row specifies which interfaces should be activated by the bridge, the second one will enable the firewall on the bridge and finally the third one will enable the bridge. La primera línea especifica qué interfaces deben ser activadas por el bridge, la segunda habilitará el firewall en el bridge y finalmente la tercera habilitará el bridge.
At this point you should be able to insert the machine between two sets of hosts without compromising any communication abilities between them. If so, the next step is to add the <literal>net.link.ether.bridge.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal> portions of these rows to the <filename>/etc/sysctl.conf</filename> file, in order to have them execute at startup. En este momento debería poder insertar la máquina entre dos conjuntos de host sin comprometer ninguna capacidad de comunicación entre ellos. Si ha funcionado, el siguiente paso es añadir lo siguiente <literal>net.link.ether.bridge.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal> al archivo <filename>/etc/sysctl.conf</filename>, para que se ejecute al inicio.
Configuring The Firewall Configurando el firewall
Now it is time to create your own file with custom firewall rules, in order to secure the inside network. There will be some complication in doing this because not all of the firewall functionalities are available on bridged packets. Furthermore, there is a difference between the packets that are in the process of being forwarded and packets that are being received by the local machine. In general, incoming packets are run through the firewall only once, not twice as is normally the case; in fact they are filtered only upon receipt, so rules that use <option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an older syntax, but one that has a sense when you read it. Another limitation is that you are restricted to use only <option>pass</option> or <option>drop</option> commands for packets filtered by a bridge. Sophisticated things like <option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can still be used, but only on traffic to or from the bridge machine itself (if it has an IP address). Ahora es el momento de crear su propio archivo de configuración con las reglas personalizadas del firewall para proteger la red interna. Se encontrará con algunas complicaciones porque no todas las funcionalidades del firewall están disponibles en los paquetes bridge. Hay además una diferencia entre los paquetes que están en proceso de reenvío y los paquetes que está recibiendo la máquina local. En general, los paquetes de entrada pasan por el firewall solo una vez, no dos veces, como suele ser el caso; en realidad se filtran solo después de la recepción, por lo que las reglas que usan <option>out</option> o <option>xmit</option> nunca coincidirán. Yo utilizo <option>in via</option>, que es una sintaxis más antigua pero tiene sentido cuando la lees. Otra limitación es que usted solo puede usar solo los comandos <option>pass</option> o <option>reject</option> para los paquetes filtrados por un bridge. Opciones más complejas como <option>divert</option>, <option>forward</option> o <option>reject</option> no están disponibles. Estas opciones pueden seguir utilizándose, pero solo en el tráfico hacia o desde la propia máquina bridge (si tiene una dirección IP).
New in FreeBSD 4.0, is the concept of stateful filtering. This is a big improvement for <acronym>UDP</acronym> traffic, which typically is a request going out, followed shortly thereafter by a response with the exact same set of IP addresses and port numbers (but with source and destination reversed, of course). For firewalls that have no statekeeping, there is almost no way to deal with this sort of traffic as a single session. But with a firewall that can <quote>remember</quote> an outgoing <acronym>UDP</acronym> packet and, for the next few minutes, allow a response, handling <acronym>UDP</acronym> services is trivial. The following example shows how to do it. It is possible to do the same thing with <acronym>TCP</acronym> packets. This allows you to avoid some denial of service attacks and other nasty tricks, but it also typically makes your state table grow quickly in size. El concepto de firewall con estado se incluyó por primera vez en FreeBSD 4.0. Es una gran mejora para el tráfico <acronym>UDP</acronym>, el cual generalmente es una solicitud de salida seguida poco después por una respuesta con exactamente el mismo conjunto de direcciones IP y números de puerto (pero obviamente con origen y destino invertidos). Con los firewalls que no mantienen el estado no hay forma de lidiar con este tipo de tráfico en una única sesión. Pero con un firewall que puede <quote>recordar</quote> un paquete saliente de <acronym>UDP</acronym> y, durante los próximos minutos, permitir una respuesta el manejo de servicios <acronym>UDP</acronym> es trivial. El siguiente ejemplo muestra cómo hacerlo. Es posible hacer lo mismo con los paquetes <acronym>TCP</acronym>. Esto le permite evitar algunos ataques de denegación de servicio y y otras maldades, pero también hace que su tabla de estado crezca rápidamente de tamaño.
Let's look at an example setup. Note first that at the top of <filename>/etc/rc.firewall</filename> there are already standard rules for the loopback interface <filename>lo0</filename>, so we should not have to care for them anymore. Custom rules should be put in a separate file (say <filename>/etc/rc.firewall.local</filename>) and loaded at system startup, by modifying the row of <filename>/etc/rc.conf</filename> where we defined the <option>open</option> firewall: Veamos una configuración de ejemplo. Lo primero, tenga en cuenta que en la parte superior del archivo <filename>/etc/rc.firewall</filename> ya existen reglas predeterminadas para la interfaz de loopback <filename>lo0</filename>, por lo que no es necesario preocuparse de ellas. Las reglas personalizadas deben colocarse en un archivo separado (por ejemplo, <filename>/etc/rc.firewall.local</filename>) y cargarse al inicio del sistema, modificando la línea en el archivo <filename>/etc/rc.conf</filename> donde definimos el firewall en modo <option>open</option>:
firewall_type="/etc/rc.firewall.local" firewall_type="/etc/rc.firewall.local"
You have to specify the <emphasis>full</emphasis> path, otherwise it will not be loaded with the risk to remain isolated from the network. Debe especificar la ruta <emphasis>completa</emphasis>, de lo contrario, no se cargará, con el riesgo de permanecer aislado de la red.
For our example imagine to have the <filename>fxp0</filename> interface connected towards the outside (Internet) and the <filename>xl0</filename> towards the inside (<acronym>LAN</acronym>). The bridge machine has the IP <systemitem class="ipaddress">1.2.3.4</systemitem> (it is not possible that your <acronym>ISP</acronym> can give you an address quite like this, but for our example it is good). Para nuestro ejemplo, imagine que tiene la interfaz <filename>fxp0</filename> conectada hacia el exterior (Internet) y la <filename>xl0</filename> hacia el interior (<acronym>LAN</acronym>). La máquina que haga de brigde tiene la IP <systemitem class="ipaddress">1.2.3.4</systemitem> (su <acronym>ISP</acronym> no puede proporcionarle una dirección así, pero para nuestro ejemplo nos sirve).
# Things that we have kept state on before get to go through in a hurry
add check-state

# Throw away RFC 1918 networks
add drop all from 10.0.0.0/8 to any in via fxp0
add drop all from 172.16.0.0/12 to any in via fxp0
add drop all from 192.168.0.0/16 to any in via fxp0

# Allow the bridge machine to say anything it wants
# (if the machine is IP-less do not include these rows)
add pass tcp from 1.2.3.4 to any setup keep-state
add pass udp from 1.2.3.4 to any keep-state
add pass ip from 1.2.3.4 to any

# Allow the inside hosts to say anything they want
add pass tcp from any to any in via xl0 setup keep-state
add pass udp from any to any in via xl0 keep-state
add pass ip from any to any in via xl0

# TCP section
# Allow SSH
add pass tcp from any to any 22 in via fxp0 setup keep-state
# Allow SMTP only towards the mail server
add pass tcp from any to relay 25 in via fxp0 setup keep-state
# Allow zone transfers only by the slave name server [dns2.nic.it]
add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
# Pass ident probes. It is better than waiting for them to timeout
add pass tcp from any to any 113 in via fxp0 setup keep-state
# Pass the "quarantine" range
add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state

# UDP section
# Allow DNS only towards the name server
add pass udp from any to ns 53 in via fxp0 keep-state
# Pass the "quarantine" range
add pass udp from any to any 49152-65535 in via fxp0 keep-state

# ICMP section
# Pass 'ping'
add pass icmp from any to any icmptypes 8 keep-state
# Pass error messages generated by 'traceroute'
add pass icmp from any to any icmptypes 3
add pass icmp from any to any icmptypes 11

# Everything else is suspect
add drop log all from any to any 		# Cosas para las que tenemos que mantener el estado
add check-state

# Desechar todas las redes RFC 1918
add drop all from 10.0.0.0/8 to any in via fxp0
add drop all from 172.16.0.0/12 to any in via fxp0
add drop all from 192.168.0.0/16 to any in via fxp0

# Permitir que la máquina bridge diga lo que quiera
# (si la máquina es IP-less no incluya estas líneas)
add pass tcp from 1.2.3.4 to any setup keep-state
add pass udp from 1.2.3.4 to any keep-state
add pass ip from 1.2.3.4 to any

# Permitir que los hosts internos digan lo que quieran
add pass tcp from any to any in via xl0 setup keep-state
add pass udp from any to any in via xl0 keep-state
add pass ip from any to any in via xl0

# Sección TCP
# Permitir SSH
add pass tcp from any to any 22 in via fxp0 setup keep-state
# Permitir SMTP solo hacia el servidor de correo
add pass tcp from any to relay 25 in via fxp0 setup keep-state
# Permitir transferencias de zona solo por el servidor de nombres esclavo [dns2.nic.it]
add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
# Dejar pasar ident probes. Es mejor que esperar a que se agote el tiempo
add pass tcp from any to any 113 in via fxp0 setup keep-state
# Dejar paso al rango "quarantine"
add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state

# Sección UDP
# Permitir DNS solo hacia el servidor de nombres
add pass udp from any to ns 53 in via fxp0 keep-state
# Dejar pasar el rango "quarantine"
add pass udp from any to any 49152-65535 in via fxp0 keep-state

# Sección ICMP
# Dejar paso a 'ping'
add pass icmp from any to any icmptypes 8 keep-state
# Dejar paso a los mensajes de error generados por 'traceroute'
add pass icmp from any to any icmptypes 3
add pass icmp from any to any icmptypes 11

# Todo lo demás es sospechoso.
add drop log all from any to any
Those of you who have set up firewalls before may notice some things missing. In particular, there are no anti-spoofing rules, in fact we did <emphasis>not</emphasis> add: Aquellos de ustedes que hayan instalado firewalls antes notarán que faltan algunas cosas. En particular, no hay reglas contra la suplantación de identidad, de hecho, <emphasis>no</emphasis> las añadimos:
add deny all from 1.2.3.4/8 to any in via fxp0 add deny all from 1.2.3.4/8 to any in via fxp0
That is, drop packets that are coming in from the outside claiming to be from our network. This is something that you would commonly do to be sure that someone does not try to evade the packet filter, by generating nefarious packets that look like they are from the inside. The problem with that is that there is <emphasis>at least</emphasis> one host on the outside interface that you do not want to ignore: the router. But usually, the <acronym>ISP</acronym> anti-spoofs at their router, so we do not need to bother that much. Es decir, descartar los paquetes que vienen del exterior diciendo pertenecer a nuestra red. Esto es algo que normalmente haría para asegurarse de que alguien no trata de evadir el filtrado de paquetes, generando paquetes corruptos que parecen ser de dentro de la red. El problema es que hay <emphasis>al menos</emphasis> un host en la interfaz externa que no desea ignorar: el router. Pero, por lo general, el <acronym>ISP</acronym> tiene reglas contra la suplantación de identidad en su router, por lo que no tenemos que preocuparnos excesivamente.
The last rule seems to be an exact duplicate of the default rule, that is, do not let anything pass that is not specifically allowed. But there is a difference: all suspected traffic will be logged. La última regla parece ser un duplicado exacto de la regla predeterminada, es decir, no dejar pasar nada que no esté específicamente permitido. Pero hay una diferencia: todo tráfico sospechoso será registrado.
There are two rules for passing <acronym>SMTP</acronym> and <acronym>DNS</acronym> traffic towards the mail server and the name server, if you have them. Obviously the whole rule set should be flavored to personal taste, this is only a specific example (rule format is described accurately in the <citerefentry><refentrytitle>ipfw</refentrytitle><manvolnum>8</manvolnum></citerefentry> man page). Note that in order for <quote>relay</quote> and <quote>ns</quote> to work, name service lookups must work <emphasis>before</emphasis> the bridge is enabled. This is an example of making sure that you set the IP on the correct network card. Alternatively it is possible to specify the IP address instead of the host name (required if the machine is IP-less). Hay dos reglas para permitir el tráfico <acronym>SMTP</acronym> y <acronym>DNS</acronym> hacia los servidores de correo y de nombres, si dispone de ellos. Obviamente todo el conjunto de reglas debe ser definido de acuerdo con sus preferencias personales; esto es solo un ejemplo específico (el formato de la regla se describe con precisión en la página del manual de <citerefentry><refentrytitle>ipfw</refentrytitle><manvolnum>8</manvolnum></citerefentry>). Tenga en cuenta que para que el <quote>relay</quote> y el <quote>ns</quote> funcionen las búsquedas del servicio de nombres deben funcionar <emphasis>antes de</emphasis> que el bridge esté activado. Este es un ejemplo de cómo asegurarse de configurar la IP en la tarjeta de red correcta. Otra forma de hacer las cosas sería especificar la dirección IP en lugar del nombre del host (requerido si la máquina no tiene IP).
People that are used to setting up firewalls are probably also used to either having a <option>reset</option> or a <option>forward</option> rule for ident packets (<acronym>TCP</acronym> port 113). Unfortunately, this is not an applicable option with the bridge, so the best thing is to simply pass them to their destination. As long as that destination machine is not running an ident daemon, this is relatively harmless. The alternative is dropping connections on port 113, which creates some problems with services like <acronym>IRC</acronym> (the ident probe must timeout). Quienes estén acostumbrados a configurar firewalls probablemente también suelan usar una regla <option>reset</option> o <option>forward</option> para los paquetes ident (<acronym>TCP</acronym> puerto 113). Por desgracia esta no es una opción válida con el bridge, por lo tanto la mejor opción es simplemente pasarlos a su destino. A menos que la máquina de destino esté ejecutando un dæmon ident es realmente inofensivo. La alternativa es eliminar las conexiones en el puerto 113, lo que creará algunos problemas con servicios como <acronym>IRC</acronym> (el probe del ident dará timeout).
The only other thing that is a little weird that you may have noticed is that there is a rule to let the bridge machine speak, and another for internal hosts. Remember that this is because the two sets of traffic will take different paths through the kernel and into the packet filter. The inside net will go through the bridge, while the local machine will use the normal IP stack to speak. Thus the two rules to handle the different cases. The <literal>in via fxp0</literal> rules work for both paths. In general, if you use <option>in via</option> rules throughout the filter, you will need to make an exception for locally generated packets, because they did not come in via any of our interfaces. Lo único raro que puede haber notado es que existe una regla para permitir que la máquina que hace de bridge hable y otra para los hosts internos. Recuerde que esto sucede porque los dos conjuntos de tráfico tendrán diferentes rutas a través del kernel y del filtro de paquetes. La red interna pasará por el bridge, mientras que la máquina local utilizará el stack normal de IP para hablar. Por lo tanto, cada regla se ocupa de una cosa diferente. Las reglas <literal>in via fxp0</literal> funcionan para ambas rutas. En general, si utiliza las reglas <option>in via</option> en todo el filtro, debe añadir una excepción para los paquetes generados localmente, ya que no llegaron a través de ninguna de nuestras interfaces.
Contributors Colaboradores
Many parts of this article have been taken, updated and adapted from an old text about bridging, edited by Nick Sayer. A pair of inspirations are due to an introduction on bridging by Steve Peterson. Muchas partes de este artículo han sido obtenidas, actualizadas y adaptadas de un texto antiguo sobre el bridging, editado por Nick Sayer. Unas cuantas ideas muy inspiradoras vienen de una introducción sobre el bridging que escribió Steve Peterson.
A big thanks to Luigi Rizzo for the implementation of the bridge code in FreeBSD and for the time he has dedicated to me answering all of my related questions. Mi más sincero agradecimiento a Luigi Rizzo por la implementación del código de bridge en FreeBSD y por el tiempo que ha dedicado a responder todas mis preguntas.
A thanks goes out also to Tom Rhodes who looked over my job of translation from Italian (the original language of this article) into English. Un agradecimiento también a Tom Rhodes, quien revisó mi trabajo de traducción del italiano (el idioma original de este artículo) al inglés.

Loading…

User avatar carlavilla@FreeBSD.org

Translation changed

FreeBSD Doc / articles_filtering-bridge — Spanish

Let's look at an example setup. Note first that at the top of <filename>/etc/rc.firewall</filename> there are already standard rules for the loopback interface <filename>lo0</filename>, so we should not have to care for them anymore. Custom rules should be put in a separate file (say <filename>/etc/rc.firewall.local</filename>) and loaded at system startup, by modifying the row of <filename>/etc/rc.conf</filename> where we defined the <option>open</option> firewall:
Veamos una configuración de ejemplo. PLo primero, tenga en cuenta que en la parte superior del archivo <filename>/etc/rc.firewall</filename> ya existen reglas predeterminadas para la interfaz de loopback <filename>lo0</filename>, por lo que no es necesario preocuparse porde ellas. Las reglas personalizadas deben colocarse en un archivo separado (por ejemplo, <filename>/etc/rc.firewall.local</filename>) y cargarse al inicio del sistema, modificando la línea en el archivo <filename>/etc/rc.conf</filename> donde definimos el firewall en modo <option>open</option>:
10 months ago
User avatar carlavilla@FreeBSD.org

Translation changed

FreeBSD Doc / articles_filtering-bridge — Spanish

Let's look at an example setup. Note first that at the top of <filename>/etc/rc.firewall</filename> there are already standard rules for the loopback interface <filename>lo0</filename>, so we should not have to care for them anymore. Custom rules should be put in a separate file (say <filename>/etc/rc.firewall.local</filename>) and loaded at system startup, by modifying the row of <filename>/etc/rc.conf</filename> where we defined the <option>open</option> firewall:
Veamos una configuración de ejemplo. Primero, tenga en cuenta que en la parte superior del archivo <filename>/etc/rc.firewall</filename> ya existen reglas predeterminadas para la interfaz de loopback <filename>lo0</filename>, por lo que no es necesario preocuparse más por ellas. Las reglas personalizadas deben colocarse en un archivo separado (por ejemplo, <filename>/etc/rc.firewall.local</filename>) y cargarse al inicio del sistema, modificando la línea den el archivo <filename>/etc/rc.conf</filename> donde definimos el firewall en modo <option>open</option>:
a year ago
User avatar None

New source string

FreeBSD Doc / articles_filtering-bridge — Spanish

New source string a year ago
Browse all component changes

Glossary

English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Source string location
article.translate.xml:256
String age
a year ago
Source string age
a year ago
Translation file
articles/es_ES/filtering-bridges.po, string 44