Issues with exchange replication over migrated vpn

[James Murray Curtis]

Hi, We are carrying out a project at work, which migrating from a ASA5505 and Zywall Dual Wan setup to a ASA5510 Active/Standby setup with 2 WANS. Each ASA has the following connections: • Ether0 Trunk for internal Vlans (each Lan is on a subinterface ) • Ether1 Unused • Ether2 Trunk for WANS (each wan is on a subinterface) • Ether 3 statefull Failover Link Between ASA’s • Mgmt port Un used We have two ISP’s Primary ISP1 Cable modem with fixed IP (100 down 4 up) and ISP2 DSL again with fixed IP (20 down and 2 up). We have the necessary Vlan configurations on our switches to permit this WAN/LAN setup. We have performed the following tests that proved successful: • Internet connection test on both ISP’s • Bringing up VPN’s that were on ASA5505 There was an issue with the migrated VPN from the Zywall to the ASA5510. This is what we noticed: • VPN comes up we can ping internal hosts on the other end of the VPN, we can RDP to hosts on the other end of the VPN…. • A queue building up on the mail server (Exchange2003) on the other end that relays all email via the VPN from the internet to our email server (Exchange 2003). • The remote office can RDP to and ping our mail server This eventually caused us to perform a rollback. After the rollback we performed a trace on the Email server, the frames have the DF bit set to 1 from the relayed email from one Exchange to another. I am not quite sure what is causing this, I have read about MTU setting and DFbit issues. But I can’t seem to understand why this should be giving us a problem considering the following: • We have a similar setup between the remote office ASA’s and the USA office ASA’s, and we have access to the configuration. The crypto configuration apart from peer IP’s and Crypto ACL… is the same. • Our Zywall that will be replaced is speaking to an ASA5510 on the other end on the tunnel (the remote office as mentioned above). Again configuration pretty much the same. We then double checked the MTU’s configured on the WAN links, and they are as they were before. For the cable modem ISP1 1500, and 1492 for the DSL connection for ISP2. We performed a bench mark test doing a ping to 8.8.8.8 –f –l 1272 and noticed this was the maximum MTU we could reach on the DSL connection for ISP2. We also tried to play around with the setting on the ASA (as previously mentioned its 1492) but it makes no difference.

[nkarthikeyan]

Can you try adding the command in crypto configs of your firewall....

crypto ipsec df-bit clear <interface>

can you do that and see if that helps....

3. PIX/ASA 7.x - Clear Don't Fragment (DF) or handling large files or packets.

   You are still unable to properly access the Internet, large files, or applications through the tunnel because it gives this MTU size-error message:

   PMTU-D packet 1440 bytes greater than effective mtu 1434,
    dest_addr=10.70.25.1, src_addr=10.10.97.55, prot=TCP
   

   In order to resolve this, be sure to clear the DF bit from the outside interface of the device. Configure the DF-bit policy for IPSec packets with the crypto ipsec df-bit command in global configuration mode.

   pix(config)# crypto ipsec df-bit clear-df outside
   

   The DF bit with IPSec tunnels feature lets you specify whether the security appliance can clear, set, or copy the Don't Fragment (DF) bit from the encapsulated header. The DF bit within the IP header determines whether a device is allowed to fragment a packet.

   Use the crypto ipsec df-bit command in global configuration mode to configure the security appliance to specify the DF bit in an encapsulated header.

   When you encapsulate tunnel mode IPSec traffic, use the clear-df setting for the DF bit. This setting lets the device send packets larger than the available MTU size. Also this setting is appropriate if you do not know the available MTU size.

Note: If you still experience fragmentation issues and dropped packets, optionally, you can manually adjust the MTU size with the ip mtu tunnel interface command. In this case, the router fragments the packet before it protects it. This command can be used in conjunction with PMTUD and/or TCP MSS.

Regards

Karthik