Shulou(Shulou.com)06/02 Report--

Routin

Gateway

Gateway Settin

Gateway group

Static rout

Routing public IP

Routing protocol

Troubleshooting

One of the main functions of the firewall is to route communication. This chapter introduces several routing-related topics, including gateways, static routes, routing protocols, routing of public network IP addresses, and the display of routing information.

Gateway

Gateways are the key to routing; they are systems that can be reached through other networks. The type of gateway that most people are familiar with is the default gateway, which is a router that the system connects to the Internet or any other network, and it has no more specific route to reach. Gateways are also used for static routes, where other networks must be reached through a specific local router. In most ordinary networks, the gateway is always in the same subnet as one of the interfaces on the system. For example, if the IP address of the firewall is 192.168.22.5max 24, the gateway to another network must be within 192.168.22.x. One notable exception is point-to-point interfaces, such as those used in the PPP protocol, which usually have gateway IP addresses in another subnet because they are not used in the same way.

Gateway address series (IPv4 and IPv6)

When using routes and gateways, the functions and procedures of IPv4 and IPv6 addresses are the same, but all addresses for a given route must contain the same series of addresses. For example, IPv6 networks must be routed using IPv6 gateways / routers. Unable to create routes for IPv6 networks that use IPv4 gateway addresses. The same restrictions apply when using gateway groups; all gateways in the gateway group must have the same address family.

Management Gateway

Before a gateway can be used for any purpose, it must be added to the firewall configuration.

If the gateway will be used for an WAN type interface, you can add the gateway to the configuration page of the interface, or you can add the gateway manually and then select from the drop-down list of the interface.

Dynamic interface types, such as DHCP and PPPoE, receive an automatic gateway marked "dynamic" in the gateway list. The parameters of these gateways are adjusted the same as those of static gateways, but dynamic gateways may not be deleted.

Add or manage gateways:

Navigate to system > Route Management

Click the Gateway tab

Click add at the top or bottom of the list to create a new gateway

Click next to the entry for the existing gateway

Edit an existing gateway

Click next to the entry

Delete an existing gateway

Click to disable the active gateway

Click to enable disabled gateways

Gateway Settin

When you add or edit a gateway, a page is displayed that lists all the options for controlling the behavior of the gateway.

The only settings required are the interface, name, and gateway (IP address).

Interface

The interface that is reached through the gateway. For example, if this is the local gateway on the LAN subnet, select the LAN interface here.

Address series

IPv4 or IPv6, depending on the address type of this gateway.

Name

The name of the gateway referenced in the gateway list. It can only contain alphanumeric characters or underscores, but not spaces. For example, WANGW,GW_WAN and WANGATE are valid, but cannot be WANGW.

Gateway

IP address of the gateway. As mentioned earlier, this must be in a subnet that is directly configured on the selected interface.

Default gateway

When selected, the gateway is considered the default gateway for the system. This is used when there are no other more specific routes. A firewall can have an IPv4 default gateway and an IPv6 default gateway.

Disable gateway monitorin

By default, each gateway is ping once per second to monitor traffic delays and packet losses arriving at monitored IP addresses. The data is used for gateway status information display. If you do not want this monitoring for any reason, you can disable it by selecting disable gateway monitoring. Note that if the gateway status is not monitored, the multi-WAN will not work properly because it cannot detect the failure.

Monitor IP

This option configures the IP address used to determine the status of the gateway. By default, the system will give the ping gateway IP address. This is not always desirable, especially if the gateway IP address is local. In this case, it is more meaningful for the ping to be further upstream, such as an ISP DNS server or server on the Internet. Alternatively, when ISP is prone to upstream failures, ping hosts on the Internet are more accurately tested to determine whether the WAN is available, rather than testing the link itself. Some popular choices include Google public DNS servers or popular websites such as Google or Yahoo. If the IP address specified in this box is not directly connected, a static route is added to ensure that traffic to the IP address is monitored through expected gateway access. Each gateway must have a unique monitoring IP address.

Firewall-aware gateway status can be checked by visiting the system status > gateway or by using the gateway widget on the dashboard. If the gateway displays Online, the monitor IP address is successfully returning ping.

Coercive state

When Mark Gateway is off is selected, the gateway is always considered closed even if ping is returned from the monitoring IP address. This is useful in situations where the WAN is running erratically and the gateway conversion causes interruptions. The gateway can be forced into the downtime state so that other gateways can be preferred until it is stable.

Description

An optional description of the gateway entry for reference. A short description of the gateway or interface it uses can be left blank.

Advanced option

You can change several parameters to control how gateways are monitored or handled in multi-WAN scenarios. Most users do not need to change these values. To access advanced options, click the Show Advanced options button. If any advanced options are set, this section expands automatically. For more information about using multiple WAN connections, see multiple WAN connections.

Specific gravity

When using multiple WAN, the specific gravity parameter adjusts the ratio used by the WAN if the two WAN have different amounts of bandwidth. For example, if WAN1 has 5Mbit / s and 10Mbit / s, then the weight of WAN1 is 1 and the weight of Wang 2 is 2. Then, one out of every three connections uses WAN and two uses WAN2. Using this method, you can make better use of the available bandwidth for allocation. You can choose a specific gravity from 1 to 30.

Data payload

To save bandwidth, by default, the dpinger daemon sends a ping with a payload size of 0 so that the ICMP echo request does not contain any data. However, in rare cases, CPE,ISP routers or intermediate hops may drop or reject ICMP packets without a payload. In these cases, set the payload size to greater than 0. Typically, 1 is large enough to satisfy the affected device.

Delay threshold

This field controls the amount of delay that this gateway considers normal. The value is expressed in milliseconds (ms). The value in the "From" field treats the gateway as the lower boundary of the warning state, but does not close. If the delay exceeds the value in the To field, it is considered closed and removed from the service. The correct values in these fields may vary depending on the type of connection used and the ISP or device between the firewall and the monitoring IP address. The default value is from 300 to 500.

These values may need to be adjusted in other common situations. For example, some DSL lines can operate properly even in higher latency, so increasing the To parameter to 700 or more can reduce the number of times the gateway is considered to be shut down, in fact, its operation is acceptable. Another example is connecting to a provider, such as he.net for IPv6, through a GIF tunnel. Due to the nature of the GIF tunnel and the load on the tunnel server, the tunnel works even though the latency is up to 900ms and is reported through the ICMP ping response.

Packet loss threshold

Similar to the delay threshold, the packet loss threshold controls the amount of packet loss that monitors the IP address and is then considered unavailable. The value is expressed as a percentage, 0 for lossless, and 100 for total loss. The value in the "From" field treats the gateway as the lower boundary of the warning state, but does not close. If the packet loss exceeds the value in the To field, it is considered closed and removed from the service. The correct values in these fields may vary depending on the type of connection used and the ISP or device between the firewall and the monitor IP address. The default value is from 10 to 20.

Like latency, connections may tend to lose a different number of packets and still operate in an available manner, especially when monitoring path loss of IP addresses or delaying ICMP to support other traffic. We have observed unusable connections and a small amount of loss, some of which are even available when showing a 45% loss. If a loss alert occurs on a functioning WAN gateway, enter higher values in the From and To fields until the line is well balanced.

Detection interval

The value in this field controls how often, in milliseconds, ping is sent to the monitoring IP address. The default value is ping twice per second (500ms). In some cases, such as connections that need to be monitored but have high data costs, even if there is a small ping every second, it will add up. This value can be safely increased as long as it is less than or equal to the alarm interval and does not violate the time limit listed below. Lower values ping more frequently and are more accurate, but consume more resources. At the expense of higher accuracy, higher values are insensitive to unstable behavior and consume less resources.

Packet loss interval

The time (in milliseconds) before the packet is considered lost. The default value is 2000 milliseconds (2 seconds). Must be greater than or equal to the high latency threshold.

If it is known that the line has a high wait time during normal operation, you can increase the value of the line to compensate.

Time period

Average amount of time (in milliseconds) of the result. The default value is 60000 (60 seconds, one minute). Longer time periods require more time for delay or loss to trigger alerts, but are not vulnerable to unstable behavior in Ping results.

The time period must be more than twice the sum of the detection interval and the loss interval, otherwise at least one probe may not be completed.

Alarm interval

The interval (in milliseconds) at which the daemon checks the alert condition. The default value is 1000 (1 second). The value must be greater than or equal to the probe interval because alerts cannot occur between probes.

Use non-local gateways

Use of non-local gateways through interface-specific routing options allows the gateway IP address to exist outside the interface subnet in a non-standard configuration. Some providers have taken this measure in order to reduce the supply of IPV4 addresses and not to put gateways on each customer subnet. Do not activate this option unless required by the upstream vendor.

Gateway group

Gateway groups define gateway groups for failover or load balancing. Gateway groups can also be used as interface values for service failover in some areas of GUI, such as Open***,IPsec and dynamic DNS.

For information about setting up these features, see multiple WAN connections.

Static rout

Static routes must be used when a host or network is reachable through a router other than the default gateway. PfSense knows that it is directly connected to its network and follows the instructions in the routing table to reach all other networks. In a network where the internal router is connected to other internal subnets, a static route must be defined for that network to reach. Routers passing through these other networks must first be added as gateways.

Static routes are set on the system > Route Management, static routes tab.

Manage static rout

Add routes:

Navigate to the system > Route Management, static routing tab

Click to add a static route

Fill in the following configuration:

Destination network: specifies the network and subnet mask that can be reached using this route.

Gateway: defines the router that is reached through this network.

Disable: sets whether static routes are not used.

Description: enter descriptive text for administrator's reference

Click Save

Click to apply changes

Manage an existing static route:

Navigate to the system > Route Management, static routing tab

Click to edit the static route to the right of the existing entry

Click to delete the static route to the right of the existing entry

Click to disable the static route to the right of the existing entry

Click to enable the static route to the right of the existing entry

Click to apply changes

Examples of static route settings

The following figure shows the network topology:

Static rout

Since the 192.168.2.0 Universe 24 network in the static route above is not on the interface directly connected to the pfSense, you need to use a static route so that the firewall knows how to reach the network. As mentioned earlier, gateways must be defined before adding static routes.

Static route configuration

Firewall rule adjustments may also be required. If you use custom LAN rules, you must allow network access through a static route on the LAN.

Firewall rules that bypass traffic on the same interface

In many cases, when static routes are used, communication ends asymmetrically. This means that traffic will travel along different paths in one direction rather than in the opposite direction. As shown in the following figure:

Asymmetric routing

Traffic from PC1 to PC2 will pass through pfSense because it is the default gateway for PC1, but traffic in the opposite direction will go directly from the router to PC1. Because pfSense is a stateful firewall, it must see the traffic of the entire connection in order to filter the traffic correctly. In this case of asymmetric routing, any stateful firewall discards legitimate traffic because it cannot remain normal without traffic being seen in both directions. This usually only affects TCP, because other protocols do not have a formal connection handshake firewall that can be recognized for stateful tracking.

In asymmetric routing scenarios, there is an option to prevent legitimate traffic from being dropped. This option adds firewall rules that allow a looser set of rule options and state handling to define all traffic between networks defined in static routes. To activate this option:

Click system > Advanced Settings

Click the Firewall / NAT tab

Check firewall rules that bypass traffic on the same interface

Click Save

Alternatively, you can manually add firewall rules to allow similar traffic. Two rules are required, one on the interface tab where traffic enters (for example, LAN), and the other on the floating tab:

Navigate to Firewall > Rule Policy

Click the tab of the interface into which traffic will enter (such as LAN)

Click to add a new rule at the top of the list

Make the following settings:

Protocol: Sloppy source address: local system uses static route address (such as LAN Net) destination address: network TCP ID on the other end of the route: set to any identity (under advanced options) status type: select Sloppy status (under advanced options) Click Save

Click the floating tab

Click to add a new rule at the top of the list

Make the following settings:

Interface: interface of traffic source (such as LAN) direction: Out protocol: TCP source address: local system uses static route address (such as LAN Net) destination address: network TCP identity on the other end of the route: set to any identity (under advanced options) status type: select Sloppy status (under advanced options) Click Save

If other traffic from other sources or destinations appears blocked in the firewall log in the TCP flag, such as "TCP:SA" or "TCP:PA", you can adjust or copy the rules to match the traffic.

Be careful

If you need to filter traffic between static route subnets, it must be done on the router, not on the firewall, because the firewall is not on the network, which can effectively control the traffic.

Routing public IP address

54 people read

This section describes the routing of public IP addresses that are assigned to internal interfaces in a single firewall deployment.

IP allocation

ISP needs to assign at least two public IP subnets. One for the WAN of the firewall and the other for the internal interface. This is usually a / 30 subnet of WAN, and a second subnet is assigned to the inside interface. The WAN and internal IP assignments are shown in the following figure.

WAN IP range 198.51.100.64/30IP address assignment 198.51.100.65ISP Router (pfSense default Gateway) 198.51.100.66pfSense WAN Interface IP address Internal IP range 192.0.2.128/29IP address assignment 192.0.2.129pfSense OPT1 Interface 192.0.131192.2.132192.0.2.133192.0.2.134 Interface configuration

First configure the WAN and OPT interfaces. If necessary, the LAN interface can also be used for public IP addresses. In this example, LAN is the private IP subnet and OPT1 is the public IP subnet.

WAN interface configuration

Add IP addresses and gateways accordingly. This is shown in the following figure.

OPT1 interface configuration

Now that OPT1 is enabled, you can choose to change its name and configure the IP address and subnet mask. This is shown in the following figure.

Configure NAT

When using public IP addresses on the inside interface, intercom must be translated to the default setting of WAN IP.

Navigate to Firewall > NAT

Click the Outbound tab

Select Hybrid Outbound NAT rule generation (select mixed outbound NAT rule generation)

Click Save

Click to add the new rule to the top of the list using the following settings:

Do not NAT: checked so that NAT will be disabled Interface:WANProtocol:AnySource: enter the local public network IP subnet in the network, 192.0.2.128/29Destination:Any click Save

This overrides the default automatic rule that translates all traffic leaving the WAN interface from the local interface to WAN IP addresses. Traffic from the OPT1 network 192.0.2.128tick 29 is not translated because manually added rules exclude it from the NAT. This configuration maintains the automatic behavior of other internal interfaces so that the benefits of auto-outbound NAT rules are not lost. The following figure shows this configuration.

If you use public IP addresses on all local interfaces, set Disable Outbound NAT (disable outbound NAT) instead of using Hybrid mode (mixed mode).

Firewall rule configuration

NAT and IP address configuration is now complete. Firewall rules need to be added to allow outbound and inbound traffic. The following figure shows a DMZ-like configuration in which all traffic destined for the LAN subnet is denied, allowing DNS and ping to the OPT1 interface IP address, and allowing HTTP outbound.

To allow traffic from the Internet to reach the public IP address on the inside interface, use the public IP address as the target to add a rule on the WAN. Figure the WAN firewall rule shows a rule that allows HTTP to 192.0.2.130, which is one of the public IP addresses on the inside interface.

Be careful

Without NAT, traffic will flow from LAN to this public subnet. If you do not need this behavior, adjust the LAN Firewall and NAT rules accordingly. In addition, policy routes may need to be bypassed to allow LAN to the interface.

Routing protocol

PfSense currently supports three routing protocols:

RIP (routing Information Protocol)

BGP (Border Gateway Protocol)

OSPF (Open shortest path first)

This section describes these in detail and assumes that knowledge of routing protocols is a prerequisite. An in-depth discussion of routing protocols is beyond the scope of this book.

RIP

RIP is part of the routing plug-in. To install it:

Navigate to system > plug-in Management

Click on the available plug-ins

Find routed in the list

Click on the right to install routed

Click to confirm

Wait for the installation to complete

Navigate to system Services > RIP

Configure RIP:

Check the Enable RIP box

Select the Interfaces RIP that will listen for and send routing updates

Select RIP version

If RIPv2 is in use and requires a network password, enter RIPv2 password.

Click Save

RIP starts immediately and starts sending and receiving routing updates on the specified interface.

BGP

To use the OpenBGPD plug-in for OpenBSD, you must first install it:

Navigate to system > plug-in Management

Click on the available plug-ins

Find OpenBGPD in the list

Click on the right to install OpenBGPD

Click to confirm

Wait for the installation to complete

Navigate to system Services > OpenBGPD

BGP is a complex beast, and a detailed description of it is beyond the scope of this book. For those who know BGP, configuring OpenBGPD on pfSense is straightforward. In developing this plug-in, we relied on O'Reilly 's BGP book and recommended it to anyone who wanted to deploy BGP.

The general configuration form of the OpenBGPD plug-in is:

Use remote AS to configure groups on the Group tab

Configure one or more neighbors as members of a defined group on the Neighbors tab

Configure local AS and network advertisements as needed on the Settings tab

OSPF

There is an OSPF plug-in in pfsense that uses the Quagga routing daemon. To install it:

Navigate to system > plug-in Management

Click on the available plug-ins

Find Quagga_OSPF in the list

Click on the right to install Quagga_OSPF

Click to confirm

Wait for the installation to complete

Navigate to system Services > Quagga OSPF

OSPF is also a rather complex routing protocol, though not as complex as BGP. The details of configuring OSPFD are beyond the scope of this book, but the configuration options found in GUI will be familiar to those who are used to OSPF.

The general configuration form of the Quagga OSPF plug-in is:

Add interfaces as needed, mark the local interface subnet as passive, and use other OSPF routers as active objects.

Configure general settings such as router ID and area ID as needed.

Troubleshooting

When diagnosing traffic problems, first check the routes known to pfSense.

View rout

There are two ways to view routes: through WebGUI and from the command line.

To view routes in WebGUI, navigate to system Diagnostics > routes, as shown in the following figure.

The command line output is similar to the output in WebGUI:

# netstat-rWnRouting tablesInternet:Destination Gateway Flags Use Mtu Netif Expiredefault 198.51.100.1 UGS 1822 1500 igb110.2.0.0/24 link#2 U 0 1500 igb010.2.0.1 link#2 UHS 0 16384 lo0127. 0.0.1 link#11 UH 204 16384 lo0198.51.100.0/24 link#3 U 1181 1500 igb1198.51.100.1 00:08:a2:09:95:b6 UHS 2789 1500 igb1198.51.100.2 link#3 UHS 0 16384 lo0

The columns displayed on these pages represent the various properties of the route and will be explained later in this section.

Destination (destination)

This column contains the target host or network. The default route for the system is displayed as default. Otherwise, the hosts are listed by IP address, and the network lists the IP address and CIDR subnet mask.

Gateway (Gateway)

A gateway is a packet router through which it is sent to a specific destination. If this column shows a link, such as link#1, the network is directly accessible through that interface and does not require a special route. If a host can see an MAC address, it is a locally reachable host with an entry in the ARP table, and the packet is sent directly there.

Flags (Flag)

There are many flags, all of which are described in the netstat (1) man page of FreeBSD, as shown in the following table:

Routing table flags and meanings represent character flags meaning 1RTF_PROTO1 protocol specific routing flags # 12RTF_PROTO2 protocol specific routing flags # 23RTF_PROTO3 protocol specific routing flags # 3BRTF_BLACKHOLE discards packets during update bRTF_BROADCAST represents broadcast address DRTF_DYNAMIC dynamically creates GRTF_GATEWAY destinations through redirection requires intermediary forwarding HRTF_HOST host input (otherwise network) LRTF_LLINFO link Valid protocol for address translation MRTF_MODIFIED dynamically modifies (by redirect) RRTF_REJECT hosts or networks cannot access SRTF_STATIC manually add URTF_UP available routes XRTF_XRESOLVE external daemons convert protocols to linked addresses

For example, a route marked UGS is an available route, the packet is sent through the listed gateway, and it is a static route.

Refs

This column calculates the number of currently active uses for a given route.

Use

The total number of packets sent through this route. This helps determine whether the route is actually used because it will continue to increase as packets take advantage of the route.

Netif

The network interface used for this route.

Expire

For dynamic entries, this field is displayed until this route expires until it is no longer in use.

Use trace rout

Traceroute is a very useful tool for testing and verifying routing and multi-WAN functionality. It shows each "hop" in the path of a packet from one end to the other, as well as the delay encountered when it reaches that intermediate point. On pfSense, you can perform a trace route by navigating to system Diagnostics > tracking routes or by using traceroute on the command line. On Windows, the program name is tracert.

Each IP packet contains a time to Live (TTL) value. When a router passes a packet, it decrements the TTL by 1. When the router receives a packet with TTL 1 and the destination is not a locally connected network, the router returns the ICMP error message "out of lifetime" and discards the packet. This is to limit the impact of routing loops, otherwise it will cause each packet to loop indefinitely.

Traceroute uses this TTL to map paths to specific network destinations. It starts by sending the first packet with a TTL of 1. The first router (usually the default gateway) will send back an ICMP timeout lifetime error. The time between sending a packet and receiving an ICMP error is the time displayed, listed with the IP address that sent the error and its reverse DNS, if any. After sending three packets with TTL 1 and showing their response time, it increases the TTL to 2 and sends three packets, noticing the same information for the second hop. Traceroute increments the TTL and repeats the process until the specified destination is reached or the maximum number of hops is exceeded.

The functions of Traceroute are slightly different on Windows and Unix-like operating systems (BSD,Linux,Mac OS Xrem Unix, etc.). Windows uses ICMP echo request packets (ping), while Unix-like systems use UDP packets by default. ICMP and UDP are layer 4 protocols, and traceroute is completed at layer 3, so the protocols used are largely irrelevant except when considering policy routing configuration. The Traceroute from the Windows client will allow ICMP echo requests to be routed according to which rule, while the Unix-like client will route according to the rule that matches the UDP port being used.

In this example, traceroute is used to view the routes for www.google.com:

# traceroute traceroute: Warning: www.google.com has multiple addresses Using 74.125.95.99 traceroute to www.l.google.com (74.125.95.99), 64 hops max 40 byte packets 1 core (172.17.23.1) 1.450 ms 1.901 ms 2.213 ms 2 172.17.25.21 (172.17.25.21) 4.852 ms 3.698 ms 3.120 ms 3 bb1-g4-0-2.ipltin.ameritech.net (151.164.42.156) 3.275 ms 3.210 ms 3.215 ms 4 151.164.93.49 (151.164.93.49) 8.791 ms 8.593 ms 8 .891 ms 5 74.125.48.117 (74.125.48.117) 8.460 ms 39.941 ms 8.551 ms 6 209.85.254.120 (209.85.254.120) 10.376 ms 8.904 ms 8.765 ms 7 209.85.241.22 (209.85.241.22) 19.479 ms 20.058 ms 19.550 ms 8 209.85.241.29 (209.85.241.29) 20.547 ms 19.761 ms 209.85.241.27 (209.85.241.27) 20.131 ms 9 209.85.240.49 (209.85.240.49) 30.184 ms 72.14.239.189 (72.14.239.189) 21.337 ms 21.756 ms10 iw-in-f99.google.com (74.125.95.99) 19.793 ms 19.665 ms 20.603 ms

The output results show that it takes 10 hops to get there, and the delay of each hop generally increases.

Be careful

When taking advantage of policy routing, such as multiple WAN, the firewall itself may not appear as a 1 "hop" in traceroute. When using policy routing, pf does not reduce TTL when forwarding packets, so traceroute cannot detect it as an intermediate router.

Routing and V-P-N

Depending on the v-p-n used, the route may not appear in the remote table. Instead of using the routing table, IPsec uses IPsec Security Policy Database (SPD) entries for internal processing in the kernel. Static routes never cause traffic to connect through IPsec. Open*** uses the system routing table, so there is an entry for networks accessible through Openv-p-n tunnels, as shown in the following example:

# netstat-rWnRouting tablesInternet:Destination Gateway Flags Use Mtu Netif Expiredefault 198.51.100.1 UGS 92421 1500 em010.6.0.0/16 10.6.203.1 UGS 0 1500 o***c210.6.203.0/24 10.6.203.2 UGS 0 1500 o***c210.6.203.1 link#9 UH 0 1500 o***c210.6.203.2 link#9 UHS 0 16384 lo010.7.0.0/24 link#2 U 1260771 1500 em110.7.0.1 link#2 UHS 0 16384 lo0127.0.0.1 link#7 UH 866 16384 lo0198.51.100.0/24 link#1 U 1251477 1500 em0198.51.100.7 link#1 UHS 0 16384 lo0

The Openv-p-n interface is 10.6.203.2, the gateway is 10.6.203.1, and the interface is o***c2. In this example, the network that can be accessed using Openv-p-n is 10.6.0.0 Universe 16.

For IPsec, because the IPsec tunnel itself does not have an IP address, tracking routes is not as useful as routing settings such as Openv-p-n. When the route trace is run to the destination through IPsec, the hop timeout as an IPsec tunnel is displayed.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.