L04 - good for it PDF

Preview

Summary

good for it...

Description

Network address translation that and use it to implement source that in destination that for the traffic passing through FortiGate in this lesson you will learn about the topics shown on this line After completing the section you should be able to achieve the objective shown on this line by demonstrating competence in understanding how NAT and PAT work, and the available NAT configuration modes, you will have a good start for planning the implementation of NAT in your network. NAT is the process that enables a single device, such as a firewall or router, to act as an agent between the Internet, or public network, and a local, or private, network. NAT is usually implemented for one, or a combination, of the following reasons: 1. Improved security: The addresses behind the NAT device are virtually hidden. 2. Amplification of addresses: Hundreds of computers can use as few as one public IP address. 3. Internal address stability: The addresses can stay the same, even if Internet service providers (ISPS) change. PAT (NAT overload): Map multiple private IPv4 addresses to a single public IP address by using different source ports. NAT and PAT, also known as NAPT: translate internal, typically private, IP addresses to external, typically public or Internet, addresses. In FortiOS, NAT and traffic forwarding apply to the same firewall policy. However, diagnostics clearly show NAT and forwarding as separate actions. For outgoing connections: The NAT option in a central SNAT, IP pool, and central SNAT table can be used and is known as source NAT. For incoming connections: Virtual IPs (VIPS) and DNAT can be used and are known as destination NAT. NAT64 and NAT46 are the terms used to refer to the mechanism that allows IPV6 addressed hosts to communicate with IPV4 addressed hosts and the reverse. Without this mechanism, an IPV6 node on a network, such as a corporate LAN, would not be able to communicate with a website that was in an IPv4-only environment, and IPV4 environments would not be able to connect to IPV6 networks. NAT66 is NAT between two IPV6 networks.

Firewall policy NAT: Configure SNAT and DNAT for each firewall policy. Central NAT: Configure SNAT and DNAT per virtual domain. SNAT and DNAT configurations automatically apply to multiple firewall policies. according to the SNAT and DNAT rules that you specify as opposed to each firewall policy in firewall policy NAT.

SNAT rule is configured from central SNAT policy. DNAT is configured from DNAT and VIPs.

Both firewall policy NAT and central NAT produce the same results. Firewall policy NAT is suggested for deployment that include relatively few NAT IP addresses and where each NAT IP address would have separate policies and security profiles. Central NAT is suggested for more complex scenarios were multiple NAT IP addresses have identical policies and security profiles, or in next generation firewall (NGFW) policy mode, where the appropriate policy may not be determined at the first packet. 5/58

There are two ways to configure firewall policy SNAT: use the outgoing interface address use the dynamic IP pool The source NAT option uses the egress interface address when NAT is enabled on the firewall policy. this is many-to-one NAT. In other words PAT is used and connections are tracked using the original source address and source port combinations, as well as the allocated source port. This is the same behavior as the overload IP pool table, which you will also learn about. Optionally you may select a fix port, in which case the source port translation is disabled with a fixed port, if two or more connections require the same source port for a single IP address, only one connection can establish. In the example shown on the slide a firewall policy from internal to wan1 ( IP address 2030.113.10 ) is created and the user initiate traffic from source 10.10.10.10:1025 destined for 192.168.10.10:80. Because NAT is enabled on the firewall policy, the source IP address is translated to the egress interface IP with port translation.

IP pools are a mechanism that allows sessions leaving the Fortigate firewall to use NAT. an IP pool defines a single IP address or a range of IP addresses to be used as the source address for the duration of the session. These assigned addresses will be used instead of the IP address assigned to that Fortigate interface. IP pools are usually configured in the same range as the interface IP address. When you can figure the IP pools that will be used for NAT, there is a limitation that you must take into account. If the IP addresses in the IP pool are different from the IP addresses that are assigned to the interfaces. Communications based on those IP addresses may feel if the routing is not properly configured. For example. if the IP address assigned to an interface is 172.16.100.1/24, you cannot choose 10.10.10.1 to 10.10.10.50 for the IP pool unless appropriate routing is configured. There are four types of IP pools that can be configured on the Fortigate firewall: Overload, one-to-one fixed port range fourth block allocation. 13/58 If you use an AP pool the source address is translated to an address from that pool rather than the egress interface address the larger the number of address is in the pool the greater the number of connections that can be supported for example in an enterprise network were you require a greater number of connections or in a network were you want one subnet to use one specific public IP over another to restrict access based on source IP address the default IP pool is overload in the overload I people type a mini to one or many to a few relationship in Port translation is used in this example source IP 10.10.10.10 will be translated to an IP address from the IP pool 203.0.113.2 through 203.0.113.5.

In the one to one pool type and internal IP address is Matt with an X ternal address on a first come first served basis there is a single mapping of an internal address to an extra address mappings are not fixed and if there are no more addresses available a connection will be refused also in 1 to 1 Pat is not required in the example on the slide you can see the same source port is shown for both the ingress and egress address. For the overload and one to one a few pool times we do not need to defined the internal IP range for the fixed port range type of IP pool we can define both internal IP range and external IP range since each external IP address and the number of available port numbers is a specific number if the number of internal IP addresses is also determined we can calculate the port range for each address translation combination so we call this type fixed port range this type of IP pool is a type of port address translation pat the fixed port range allows fixed mapping of the internal start IP or internal end IP range to the external start IP or external in dopey range the example on the slide shows a fixed port range IP pool the internal address range 10.0.1.0 do 10.0.1.11 maps to the external address range 10.200 that one.7 to 10.200 that one that ate IP cool type port block allocation is also a type of path that gives users a more flexible way to

control the way external IP‘s and ports are allocated users need to define block size and block per user and X ternal IP range black size means how many quarts each block contains block per user means how many blocks each host or internal IP can use the two seal outputs shown on the slide illustrate the behavior difference between the port block allocation IP pool time and the default overload I people take using each ping a rogue client generates mini sent packets per second in the first example the port block allocation type limits the client to 64 connections for that IP pool other users will not be impacted by the road client in the second example the overload type in poses no limits end of the road client uses many more connections in the session table other users will be impacted fourth block allocation time up. Is configurable on the 48 CLI. VIPs are dinette objects for sessions matching a VIP the destination address is translated usually a public Internet address is translated to a service private network address VIPs are selected in the firewall policies destinations feel the default VIP type is static Nat this is a one to one mapping which applies for incoming and outgoing connections that is an outgoing policy with net enabled would use the VIP address instead of the egress interface address however this behavior can be overridden using an IP pool the static net VIP can be restricted to forward only certain ports for example connections to the external IP on port 8080 map to the internal IP on port 80 on the COI you can select the net type as load balance and server load balance plane in load balancing distributes connections from an external IP address to multiple internal addresses server load balancing builds on that mechanism using a virtual server and real servers improvise session persistence and server availability check mechanisms VIPs should be rideable to the external facing ingress interface 40 OS response to our request for VIP and IP pull objects or responses are configurable. In this example source IP address 192.168.10.10 is trying to access the destination IP address 203.0.113.22 over port TCP 80 connections to the VIP 203.0.113.22 are not added to the internal host 10.10.10.10 because this is a static net all netted outgoing connections from 10.10.10.10 will use VIP address 2:03.0.113.22 in the packets IP source field and not the egress interface IP address 2:03.0.113.10. Pic

By the fault central net is disabled and can only be enabled on the CLI after central net is enabled these two options are available to be configured on the GUI central Oechsner dinette and virtual IP‘s what happens if you try to enable central net but there are still IP pool or VIPs configured and firewall policies to seal I will not allow this and will present a message referencing the firewall policy ID with the VIP or I people you must remove VIP or I people references from existing firewall policies in order to enable central net central SNET is mandatory for the new NGFW mode in policy-based this means SNET behaves only according to the net settings found by clicking policy and objects central SNET .

You can have more granular control based on source and destinations interfaces in the central SNET policy over traffic passing through firewall policies you can now to find matching criteria in the central SNET policy based on source interface destination interface source address destination address protocol source port starting in 40 iOS 6 auto a matching central SNET policy is mandatory for all firewall policies if there is no matching SNET policy no net will be apply in session will be created using original source IP address if the central SNET policy criteria matches the traffic based on multiple firewall policies the central Internet policy will be applied to those firewall policies similar to firewall policies a central SNET policy is processed from top to bottom and if it matches phone source address in source port or translated based on that central SNAT policy.

Pic traditionally VIPs were selected in the firewall policy as the destination address you can configure Tina and VIPs for Deena as soon as a VIP is configured automatically creates a rule in the kernel to allow the neck to occur no additional configuration is required do you lose the granularity of being able to define a firewall policy for a specific VIP and services no you don’t if you have several went to internal policies and multiple VIPs and you want to allow specific services for specific VIPs you can defined each firewall policy with the destination address of the mapped IP of the VIP and select the appropriate services to allow or deny nope they have both central SNET and central Dina VIP are configured the outgoing internal to win traffic will source net based on the Matchington no net will be applied on outgoing traffic. On this life HDNet and VIP rule is created to map external IP address 203.0.113.22 two internal IP address 10.10.10.10 as soon as the VIP is created a rule is created in the kernel to allow Deena to occur the firewall policy from when one to internal is created with the destination address all or map IP address range 10.10.10.10 of the VIP the source of the address 192.168.10.10 is trying to access the destination IP address 203.0.113.22 over port TCP 80 connections to the VIP 203.0.113.22 or net it to the internal host 10.10.10.10 without any additional configuration. You can disable central net on the COI by running set central net disable under the config system settings what happens to firewall policies that are using central SNET and Deena rules if central net is disable for new firewall sessions the incoming to outgoing firewall policies will no longer perform S net you must manually edit firewall policies to enable net and select appropriate IP pull addresses which were previously tied to the central SNET policy egress to ingress firewall policies that use the net and VIP will no longer perform dinner in Central that the destination address on the firewall policy is simply an address object not an actual VIP without it central net hook into the Dina table the address object will cause a forward policy check failure the traffic will be denied policy ID zero you must edit the egress to ingress firewall policies and select VIP as the destination address.

Some application layer protocols are not fully independent of the lower layers such as the network or transport layers the address is may be repeated in the application layer for example if the session helper detects a pattern like this it may change the application headers or create the required secondary connections a good example of this is an application that has both a control channel and a data or media channel such as FTP firewalls will typically allow the control channel and rely on the session helpers to handle the dynamic data or media transmission connections with more advanced application tracking and control is required a LG can be used the void profile is an example of an LG in the example shown on the slide the media recipient address in the sip STP payload is modify to reflect the translated IP address notice out because where will policies or state for a pinhole is opened to allow reply traffic even though you have not explicitly created a firewall policy to allow incoming traffic this concept is used with some other protocols such as net T4 IP sec.

You can view the sessions page on the gooey but the COI provides more information regarding sessions in the session table I will performance of connections for each session and the maximum number of connections or indicated by the session table however if you’re 48 contain processors design to accelerate processing without loading the CPU the session table information may not be completely accurate because the session table reflects what is known to and processed by the CPU. Each session on 40 gate can idle for a finite time which is defined by TTL with the 48 to text a session is idol after sometime of inactivity and TTL is reached the session is deleted from the session table because the session table has a finite amount of RAM that it can use on 40 gate adjusting the session TTL can improve performance there are global default timers session state timers and timers configurable and firewall objects.

The diagnosis session command tree provides options to filter clear or show the list of sessions you can also list brief information about sessions by running the get system session list command before looking at the session table 1st build a filter to look at our test connection you can filter on DST 10 that 200 that one that 254 and D port 80.

In the example shown on the slide you can see the session TTL which reflects how long 40 gauge can go without receiving any packets for the session until it will remove the session from his table here you can see the routing and net actions that apply to the traffic the firewall policy ID is also tracked the Proto state for TCP is taken from its state machine which you’ll learn about in this lesson.

Earlier in this lesson you learned that the session table contains a number that indicates the connections to current TCP state these are the states of the TCP state machine they are singledigit values but Proto state is always shown as two digit this is because 40 gate is a state for

firewall and keeps track of the original direction client site state and the reply direction serverside state if there are too many connections in the sin state for long periods of time this indicates a sin flood which you can mitigate with DOS policies this table and flow graph correlate the second digit value with the different TCP session states for example when the 40 gate receives the Sunpass the second digit is two it goes to three once the Sinach is received. After the three-way handshake the state value changes to one with a session is close by both size 48 keeps it in the session table for a few seconds more to allow any out of order packets that could arrive after the fin egg packet this is the state value five. BP is a message oriented stateless protocol it doesn’t inherently require confirmed by directional connections like TCP so there’s no connection state however 48 session table does use the Proto state equal field to track the unidirectional UDP as state zero and the bidirectional UDP as State won 140 gate received the first packet it creates the entry and sets the state 20 if the destination replace FortiGate updates the state flag to one for the remainder of the conversation notably I CMP such as peeing and trace route have no protocol state and I will always show Proto state equals 00.

That port exhaustion occurs 140 gate is unable to allocate ports for performing that on new sessions because there are no available ports when that or exhaustion occurs 48 informs the administrator by displaying the log shown on the slide with a severity of critical to address network exhaustion you must take one of the following actions create an IP pool that has more than one external IP tied to it so it load balances across them reduce the number of sessions that require net to receive important logs like this one you must make sure the necessary logging is an able on the 40 get doing click login report log settings to check that the default setting login to disk or memory is activated. That or exhaustion is also highlighted by arise in the clash counter from the diagnose system session stat command you can use the diagnose firewall IP pool all list command which will list all of the configured net IP pools with their net IP range and type the diagnose firewall IP pool all stats shows the stats for all of the IP pools the stance command provide the following data and information that sessions per IP pool total TCP sessions per IP pool total UDP sessions per IP pool total others non-TCP add non-UDP sessions per IP pool optionally you can filter the output for specific IP pool by using the name of IP pool. Services option has been added to VIP objects when services in Port forward our configured only a single map porch can be configured however multiple external ports can be Matt to that single internal poured this configuration was made possible to allow for complex scenarios were multiple sources of traffic are using multiple services to connect to a single computer while requiring a combination of source and destination that and not requiring numerous VIPs to be bundled into VIP groups VIPs with different services are considered non-overlapping.

Use the following best practices when implementing Nat avoid the miss configuration of an IP pool range double check to start and end IP’s of each IP pool ensure that the IP pool does not overlap with the dress is assigned to 40 get interfaces or to any host on directly connected networks if you have internal and X ternal users accessing the same servers use split DNS to offer an internal IP to internal users so that they don’t have ...