Configuring Path Maximum Transmission Unit Discovery on Avaya Security Gateways - Issue 1.0

Transcription

1 Avaya Solution & Interoperability Test Lab Configuring Path Maximum Transmission Unit Discovery on Avaya Security Gateways - Issue 1.0 Abstract These Application Notes address the setup and configuration of Path Maximum Transmission Unit (MTU) Discovery on the Avaya Security Gateways. The Path MTU feature may be used for either clear traffic or encrypted (VPN) traffic. 1 of 12

2 1. Introduction Path MTU is used for dynamically discovering the maximum transmission unit (MTU) of an arbitrary Internet path. The Path MTU Discovery is defined in RFC The basic idea is that a source host initially assumes that the Path MTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the Don t Fragment (DF) bit set. If any of the datagrams are too large to be forwarded without fragmentation by some router along the path, that router will discard them and return ICMP Destination Unreachable messages with a code meaning "fragmentation needed and DF set". Upon receipt of such a message, the source host reduces its assumed Path MTU for the path. Avaya Security Gateways (SGs) support Path MTU discovery for both clear traffic and encrypted (VPN) traffic. These Application Notes demonstrate the steps required to configure the Path MTU in Avaya Security Gateways in an IP network environment. Figure 1 below shows the topology used for the verification. SG208 Private: Public: SG203 Private: Public: Avaya P Avaya SG /24 Extreme Alpine /24 Avaya SG /24 Cisco 3745 Site-to-Site VPN Tunnel PC PC Figure 1: Sample Site-to-Site VPN Configuration Notes: It has been assumed that a site-to-site VPN tunnel between the Avaya SG208 and the Avaya SG203 has been pre-configured and is working. For detailed VPN tunnel configuration, please refer to the Application Note entitled Site-to-Site VPN Configuration between Avaya SG208 Security Gateway, Enterasys XSR-1805 Security Router, and Cisco VPN 3000 Concentrator using AES-128, Perfect Forward Secrecy and Tunnel Persistence Issue 1.0 at 2 of 12

3 2. Equipment and Software Validated Table 2 lists the equipment and software validated for the sample configuration provided. Equipment Avaya P882 MultiService Switch Avaya SG208 Security Gateway Avaya SG203 Security Gateway Extreme Alpine 3808 Switch Cisco 3745 MultiService Router Software V6.0.0 VPNos v VPNos v V7.2.0 (B25) IOS 12.3.(4T) Table 2: Equipment and Software Validated 3. Configure Path MTU on Avaya SG203 Security Gateway This section describes the Path MTU configuration for the Avaya SG203 Security Gateway. Basic public and private interface administration is not covered. Please refer to the SG203 system documentation for details on interface administration. Since the configuration is identical for both the SG203 and the SG208, only the SG203 configuration is presented here. Table 1 shows the default Path MTU settings for Avaya Security Gateways. Security Gateway Path MTU DF Bit Other DF Bit Options SG5, SG5x OFF CLEAR COPY, SET available SG200, SG203, SG208 ON COPY No other options available Table 1: Default Path MTU Settings for Security Gateways 3.1. Enable Path MTU Discovery By default, the Path MTU is on and the DF Bit is set to COPY. If Path MTU discovery is on, it will enable the SG203 to dynamically figure out the minimum MTU of the packet path and, if possible, to inform the source host of the packet about it. The routers that support Path MTU will send an ICMP need-frag message to the source of the packet. Note that Path MTU will work differently in the following two scenarios. Scenario 1: Clear Traffic and NAT enabled In the case of Static or Port NAT, the SG will be seen as the source of the packet by outside routers (routers located on the public side). Hence they will send the ICMP need-frag message to the SG. The SG will generate or convert the ICMP message and send it to the real source host. Scenario 2: VPN Traffic When the SG is an endpoint for a VPN, the packets leaving the SG on the public interface will have the source set as the SG. When an intermediate router sends an ICMP need-frag message to the SG, the SG will find all VPNs matching the destination address and the 3 of 12

4 security protocol (ESP/AH) and update their MTU size. Therefore, when the next packet larger than this new Path MTU arrives at the SG from a private interface, the SG generates an ICMP need-frag message to the source host. This is the case with Tunnel NAT enabled or disabled. To configure Path MTU Discovery on the SG203, follow these steps: Establish an HTTP connection to the Security Gateway private interface. Log in using a valid login ID and password. Navigate to Configure Advanced Path MTU. Figure 2 shows that the default setting is on for the SG203. Figure 2: Path MTU ON Configuration Note: Path MTU timeout range is minutes. The default is 500 minutes Disable Path MTU Discovery When the Path MTU is turned off on the SG203, there are three settings available for the DF bit. Understanding the differences among these settings is important in order to implement Path MTU Discovery properly. 4 of 12

5 1. Copy DF bit from the source packet With this configuration, all VPN traffic leaving the SG203 will have the same DF bit setting, as the original packet and the SG will not honor the ICMP need-frag messages. 2. Set DF bit With this configuration, the SG203 will set the DF bit to do not fragment the packet as the packets leave the SG Clear DF bit When the DF bit is set to CLEAR, the SG203 will not honor any ICMP messages coming to the SG. The SG will clear the DF bit for all VPN packets leaving the SG. Follow the steps below to turn off the Path MTU Discovery and configure different DF bit settings on the SG203. Configure the SG203 to Copy DF bit from the source packet. Click Off for Path MTU Discovery. Select one of the DF bit settings in Figure 3. Click Save. Figure 3: Path MTU OFF and DF bit Set to Copy Configuration 5 of 12

6 Note: Once the Save button is clicked, the SG will generate a warning message as shown in Figure 4. Click Close in Figure 4. Figure 4: SG203 Warning Message Click OK from Figure 5 to save the configuration. Figure 5: Save Configuration 6 of 12

7 3.3. Configure the SG203 Interface MTU Size The MTU size for SG203 interfaces can be set in the range of bytes. The following example shows how to configure the SG public interface MTU to 1000 bytes. Navigate to Configure Networks. Highlight Interfaces under the Properties panel. Highlight Ethernet 1 (public) and click Modify... as shown in Figure 6. Figure 6: Configure Interface 7 of 12

8 Click Media Settings as shown in Figure 7. Figure 7: Configure Media Setting for Interface Type 1000 in the MTU field as shown in Figure 8 and click OK. Figure 8: Configure Media Setting for Interface (Continued) 8 of 12

9 Click Save as shown in Figure 9. Figure 9: Save Interface Configuration 4. Verification Steps The following steps can be used to validate the configuration. Set Path MTU to ON and the MTU size to 1000 bytes for the SG public interface. Launch a ping from PC 1 with a packet size of Verify that the pings are successful and the SG fragments the packets. Set Path MTU to OFF and the DF bit to COPY. Launch pings from PC 1 to the Cisco 3745 router interface ( ) with a packet size of 1500 bytes and DF bit Set (flag f means to set the DF bit) Verify that the pings failed (SG dropped the packets) and the PC 1 received ICMP message Packet needs to be fragmented but DF set from the 9 of 12

10 SG. The capture below is the output from the PC 1. Note that the IP address is the IP address of the SG208 private interface. C:\> ping f -l 1500 Pinging with 1000 bytes of data: Reply from : Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for : Packets: Sent = 4, Received = 1, Lost = 3 (75% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Set the MTU size to 800 bytes in both private and public interfaces of the SG208. Launch a ping with packet size 1500 bytes from the Cisco 3745 router to the Avaya P882 Switch. Verify that the SG203 fragments the packets. The protocol analyzer trace, shown below, captured from the private side of the SG208 showed that the ICMP packet was fragmented. The lines in bold showed the packet fragmentation. Record #6 (From Node to Hub) Captured on at 14:03: Length = 814 Runtime Frame# ETHER Header ETHER: Destination: D-E ETHER: Source: A1-00-CD-96 ETHER: Protocol: IP ETHER: FCS: 0238FCF IP Header IP: Version = 4 IP: Header length = 20 IP: Differentiated Services (DS) Field = 0x00 IP: DS Codepoint = Default PHB (0) IP: Unused IP: Packet length = 796 IP: Id = c4 IP: Fragmentation Info = 0x2000 IP: IP: Don't Fragment Bit = FALSE More Fragments Bit = TRUE IP: Fragment offset = 0 IP: Time to live = 253 IP: Protocol = ICMP (1) IP: Header checksum = 666E (Verified 666E) IP: Source address = IP: Destination address = of 12

11 Record #7 (From Node to Hub) Captured on at 14:03: Length = 742 Runtime Frame# ETHER Header ETHER: Destination: D-E ETHER: Source: A1-00-CD-96 ETHER: Protocol: IP ETHER: FCS: D92A5A0C IP Header IP: Version = 4 IP: Header length = 20 IP: Differentiated Services (DS) Field = 0x00 IP: DS Codepoint = Default PHB (0) IP: Unused IP: Packet length = 724 IP: Id = c4 IP: Fragmentation Info = 0x0061 IP: Don't Fragment Bit = FALSE IP: More Fragments Bit = FALSE IP: Fragment offset = 776 IP: Time to live = 253 IP: Protocol = ICMP (1) IP: Header checksum = 8655 (Verified 8655) IP: Source address = IP: Destination address = Note that the Record #6 is the first part of the original packet and the Record #7 is the second half after fragmentation. 5. Conclusion Avaya Security Gateways support the Path MTU Discovery protocol for both clear and encrypted (VPN) traffic. The SGs interoperated with Extreme network devices that support the Path MTU Discovery protocol. The steps described in these Application Notes can be generalized for most configurations. 11 of 12

12 Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by and are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. The information provided in these Application Notes is subject to change without notice. The configurations, technical data, and recommendations provided in these Application Notes are believed to be accurate and dependable, but are presented without express or implied warranty. Users are responsible for their application of any products specified in these Application Notes. Please any questions or comments pertaining to these Application Notes along with the full title name and filename, located in the lower right corner, directly to the Avaya Solution & Interoperability Test Lab at 12 of 12