The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: sect2/para
English
In this example, the first rule calls the proxy for outbound <acronym>FTP</acronym> traffic from the internal <acronym>LAN</acronym>. The second rule passes the <acronym>FTP</acronym> traffic from the firewall to the Internet, and the third rule handles all non-<acronym>FTP</acronym> traffic from the internal <acronym>LAN</acronym>:
Context English Turkish (tr_TR) State
The <replaceable>LAN_IP_RANGE</replaceable> is the range of <acronym>IP</acronym> addresses used by internal clients. Usually, it is a private address range such as <systemitem class="ipaddress">192.168.1.0/24</systemitem>. The <replaceable>PUBLIC_ADDRESS</replaceable> can either be the static external <acronym>IP</acronym> address or the keyword <literal>0/32</literal> which represents the <acronym>IP</acronym> address assigned to <replaceable>IF</replaceable>.
In <application>IPF</application>, when a packet arrives at the firewall from the <acronym>LAN</acronym> with a public destination, it first passes through the outbound rules of the firewall ruleset. Then, the packet is passed to the <acronym>NAT</acronym> ruleset which is read from the top down, where the first matching rule wins. <application>IPF</application> tests each <acronym>NAT</acronym> rule against the packet's interface name and source <acronym>IP</acronym> address. When a packet's interface name matches a <acronym>NAT</acronym> rule, the packet's source <acronym>IP</acronym> address in the private <acronym>LAN</acronym> is checked to see if it falls within the <acronym>IP</acronym> address range specified in <replaceable>LAN_IP_RANGE</replaceable>. On a match, the packet has its source <acronym>IP</acronym> address rewritten with the public <acronym>IP</acronym> address specified by <replaceable>PUBLIC_ADDRESS</replaceable>. <application>IPF</application> posts an entry in its internal <acronym>NAT</acronym> table so that when the packet returns from the Internet, it can be mapped back to its original private <acronym>IP</acronym> address before being passed to the firewall rules for further processing.
For networks that have large numbers of internal systems or multiple subnets, the process of funneling every private <acronym>IP</acronym> address into a single public <acronym>IP</acronym> address becomes a resource problem. Two methods are available to relieve this issue.
The first method is to assign a range of ports to use as source ports. By adding the <literal>portmap</literal> keyword, <acronym>NAT</acronym> can be directed to only use source ports in the specified range:
map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp 20000:60000
Alternately, use the <literal>auto</literal> keyword which tells <acronym>NAT</acronym> to determine the ports that are available for use:
map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp auto
The second method is to use a pool of public addresses. This is useful when there are too many <acronym>LAN</acronym> addresses to fit into a single public address and a block of public <acronym>IP</acronym> addresses is available. These public addresses can be used as a pool from which <acronym>NAT</acronym> selects an <acronym>IP</acronym> address as a packet's address is mapped on its way out.
The range of public <acronym>IP</acronym> addresses can be specified using a netmask or <acronym>CIDR</acronym> notation. These two rules are equivalent:
map dc0 192.168.1.0/24 -&gt; 204.134.75.0/255.255.255.0
map dc0 192.168.1.0/24 -&gt; 204.134.75.0/24
A common practice is to have a publically accessible web server or mail server segregated to an internal network segment. The traffic from these servers still has to undergo <acronym>NAT</acronym>, but port redirection is needed to direct inbound traffic to the correct server. For example, to map a web server using the internal address <systemitem class="ipaddress">10.0.10.25</systemitem> to its public <acronym>IP</acronym> address of <systemitem class="ipaddress">20.20.20.5</systemitem>, use this rule:
rdr dc0 20.20.20.5/32 port 80 -&gt; 10.0.10.25 port 80
If it is the only web server, this rule would also work as it redirects all external <acronym>HTTP</acronym> requests to <literal>10.0.10.25</literal>:
rdr dc0 0.0.0.0/0 port 80 -&gt; 10.0.10.25 port 80
<application>IPF</application> has a built in <acronym>FTP</acronym> proxy which can be used with <acronym>NAT</acronym>. It monitors all outbound traffic for active or passive <acronym>FTP</acronym> connection requests and dynamically creates temporary filter rules containing the port number used by the <acronym>FTP</acronym> data channel. This eliminates the need to open large ranges of high order ports for <acronym>FTP</acronym> connections.
In this example, the first rule calls the proxy for outbound <acronym>FTP</acronym> traffic from the internal <acronym>LAN</acronym>. The second rule passes the <acronym>FTP</acronym> traffic from the firewall to the Internet, and the third rule handles all non-<acronym>FTP</acronym> traffic from the internal <acronym>LAN</acronym>:
map dc0 10.0.10.0/29 -&gt; 0/32 proxy port 21 ftp/tcp
map dc0 0.0.0.0/0 -&gt; 0/32 proxy port 21 ftp/tcp
map dc0 10.0.10.0/29 -&gt; 0/32
The <acronym>FTP</acronym> <literal>map</literal> rules go before the <acronym>NAT</acronym> rule so that when a packet matches an <acronym>FTP</acronym> rule, the <acronym>FTP</acronym> proxy creates temporary filter rules to let the <acronym>FTP</acronym> session packets pass and undergo <acronym>NAT</acronym>. All LAN packets that are not <acronym>FTP</acronym> will not match the <acronym>FTP</acronym> rules but will undergo <acronym>NAT</acronym> if they match the third rule.
Without the <acronym>FTP</acronym> proxy, the following firewall rules would instead be needed. Note that without the proxy, all ports above <literal>1024</literal> need to be allowed:
# Allow out LAN PC client FTP to public Internet
# Active and passive modes
pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state

# Allow out passive mode data channel high order port numbers
pass out quick on rl0 proto tcp from any to any port &gt; 1024 flags S keep state

# Active mode let data channel in from FTP server
pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state
Whenever the file containing the <acronym>NAT</acronym> rules is edited, run <command>ipnat</command> with <option>-CF</option> to delete the current <acronym>NAT</acronym> rules and flush the contents of the dynamic translation table. Include <option>-f</option> and specify the name of the <acronym>NAT</acronym> ruleset to load:
<prompt>#</prompt> <userinput>ipnat -CF -f /etc/ipnat.rules</userinput>
To display the <acronym>NAT</acronym> statistics:
<prompt>#</prompt> <userinput>ipnat -s</userinput>
To list the <acronym>NAT</acronym> table's current mappings:
<prompt>#</prompt> <userinput>ipnat -l</userinput>
To turn verbose mode on and display information relating to rule processing and active rules and table entries:
<prompt>#</prompt> <userinput>ipnat -v</userinput>
Viewing <application>IPF</application> Statistics
<primary><command>ipfstat</command></primary>
<primary><application>IPFILTER</application></primary> <secondary>statistics</secondary>

Loading…

No matching activity found.

Browse all component changes

Glossary

English Turkish (tr_TR)
firewall güvenlik duvarı FreeBSD Doc
proxy vekil sunucu FreeBSD Doc

Source information

Source string comment
(itstool) path: sect2/para
Source string location
book.translate.xml:63318
String age
9 months ago
Source string age
a year ago
Translation file
books/tr_TR/handbook.po, string 10386