Issues with exchange replication over migrated vpn
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 188.8.131.52 –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.
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....
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.
The purpose of this document is to demonstrate how ISE authenticate / authorize a user that uses a smart card (PIN + Certificate) and password mechanism to login their system. This document describes the components used for this setup, configuration of IS...
For all versions of the Email Security Appliance (ESA) and Security Management Appliance (SMA), some Secure Sockets Link (SSL) certificates issued from the QuoVadis root certificate authority (CA) trust chain before 2021-03-31 cannot b...
Automation and programmability for networking and security are increasingly important topics. Every release since ISE 1.2 has included new REST API capabilities to better automate and integrate ISE with the rest of your network, appli...
The latest iteration (v2.3.4) of the Cisco Secure Firewall Migration Tool adds public beta support for S2S VPN migrations from ASA:
Policy-based (crypto map) Pre-Shared key authentication type VPN configuration to Firepower Management Center
Cisco Defense Orchestrator (CDO) is a cloud-based, multi-device manager that manages security products like Adaptive Security Appliance (ASA), Firepower Threat Defense next-generation firewall, and Meraki devices, to name a few.
We make improvement...