This is quite puzzling. Am I correct in remembering from various posts that you had this problem using a router at the site for the vpn and then replaced that router with a Fortigate and still had exactly the same symptom? If two different platforms at the site had the same issue it would sort of point toward the issue being at the other end.   But now you have tested using an ASA for the other end and still have the same issue. Seems unlikely that if the problem were on the original remote peer that you would create the same issue on your ASA.   Is my memory of the various steps and their outcome accurate?   When you were testing with your ASA did you do any show crypto IPSec sa on either or both sides? If so could you post those outputs?   Would you post the output of show access-list from your router?   HTH   Rick ... View more

In general a single company would have a single public AS. If you have more than 1 site there are several ways to deal with the situation. One option is to have separate IP address blocks for each site and to have each site advertise only its IP address block. This works well but it provides no redundancy. Another option would be to provide some connection between sites. This might be some type of private connection, might be some service like MPLS, or might be some type of tunnel connection. In this alternative each site can advertise all IP address blocks used by all sites, with some type of prepending to prefer certain address blocks at certain sites. This alternative works and does provide some redundancy in the event that the main Internet connection at a site might fail.   HTH   Rick ... View more

It is interesting that in your test using your ASA that it is successful with other sites and has the same kind of issue with the problem site. In this testing you have the ASA configured like the firewall at the remote side? And do you have a device connected to the ASA which uses the IP address of the remote server?   HTH   Rick ... View more

Thanks for confirming that you have been testing with ping to other devices on your subnet from the server. Am I correct in understanding that these ping tests failed? It makes me wonder about the possibility that the problem may be on the other end.   HTH   Rick ... View more

Sorry to hear that the new hardware did not solve the problem. Interesting that it is still the same symptoms. That sort of fits with our observation that your router config seemed to be ok. And with the fact that there was two way traffic on the vpn.    Am I correct in understanding that this site to site vpn is to carry traffic to a printer at your site? I am wondering if there might be some issue with the setup of the printer that causes it to be incompatible with the server? Could you have the server send some type of traffic to some other device in your network and see if that works better?   HTH   Rick ... View more

Please post the details of the configuration of the devices at 172.17.192.130 and 140. I am especially interested in what is their default gateway.   HTH   Rick ... View more

I hope it does work better with the Fortigate. Please let us know the outcome.   HTH   Rick ... View more

The basic definition of interface reset is Number of times an interface is completely reset. This may occur if packets that are queued for transmission were not sent within several seconds. The drops probably are related to congestion on the interface. And my guess is that the interface congestion may have caused some packets to not be transmitted in time and these may be your interface resets.   HTH   Rick ... View more

You have asked that I explain in more detail. So let me start by reviewing the issue and my proposed way to address it. You have a server in your network that is running some old software that needs to be moved to a new physical location. But that software requires that it still have its original address in the new location. The network/original subnet will continue to operate in your network after the server is moved, so just moving the entire network/subnet can not be done. The solution is to create a new small subnet at the new location that uses some of the addresses from the original network/subnet. You really only need 2 valid addresses in the new subnet (the original address for the server and an address for the router interface). Depending on the addresses used it might be sufficient to use a /30 subnet which would give you exactly two useable addresses. If the server address is really something that has 100 in the last octet than a /30 will not do because 100 would be the subnet address. In that case you would need a /29 subnet. You would configure the router address (perhaps as 192.168.0.99) as a secondary address so that this interface will support two subnets. The router would advertise both subnets to the rest of the network. The result is that the server is reachable from all devices in the network and continues to use its original address. Note that one impact of this approach is that any devices in the original network/subnet that have addresses in the new subnet will no longer be reachable.   My original suggestion had included using static address translation to make the server address reachable. As I wrote this explanation I realized that the address translation is not needed. All that we need is to have a small subnet at the new physical location that uses a few addresses from the original network/subnet.     In thinking about how to test this I realize that we do not know whether your network uses a dynamic routing protocol or uses static addresses. A dynamic routing protocol makes it easier and I will assume that this is what you do and I will describe testing using dynamic routing. 1) using router1 configure an interface for the original network perhaps 192.168.0.0 255.255.255.0 2) on router1 configure an interface that will connect to router2 with an IP address. 3) on router1 configure a dynamic routing protocol that processes these two interfaces. 4) on router2 configure an interface that connects to router1 with an IP address that is in the same subnet. 5) on router2 configure an interface for another network/subnet (perhaps 192.168.10.0 255.255.255.0) 6) on router2 configure on that interface a secondary address perhaps 192.168.0.96 255.255.255.248 7) on router2 configure the same dynamic routing protocol used on router1 and have it process the three subnets (the subnet used for connection, the primary subnet, and the secondary subnet). 8) you will need at least one more network/subnet to represent other users in your network who need to access the server. You might use another router for this or you might use additional subnets of either or both of router1 and router2.   When you want to put this into production it is really quite easy. 1) on the router interface at the new location configure the new secondary address. 2) make sure that the dynamic routing protocol on that router advertises the new subnet. 3) move the server.   In reviewing this I realize that I am making an assumption that needs to be verified. I am assuming that the old software must keep the original address but that the software would allow you to change the gateway address that the server uses.   HTH   Rick ... View more

I have read back through the complete discussion and notice something unexpected in an early post showing the arp table L3_SW_1 #sh ip arp Protocol  Address          Age (min)  Hardware Addr   Type   Interface Internet  10.170.124.121          -   b8be.bf9e.3b42  ARPA   Vlan30 Internet  10.170.124.122         22   0025.90ca.1f62  ARPA   Vlan30 Internet  172.17.192.8          160   0026.b981.a277  ARPA   Vlan50 Internet  172.17.192.9            0   0026.b981.a26f  ARPA   Vlan50   I would expect to see an entry for the switch interface in vlan 50 and I would expect to see entries for the 192.168 link. Can you post a fresh output of show ip arp and see if this is consistent? Does the config of either switch do anything about arp - like change the arp timeout value?   HTH   Rick ... View more

I am still trying to understand what is causing the one way success L3_SW_2#ping 172.17.192.8 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.17.192.8, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms L3_SW_1#ping 172.17.192.130 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.17.192.130, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)   Would you do a traceroute from SW2 to 172.17.192.8 and post the output?   HTH   Rick ... View more

Thanks for the additional information. No obvious issues found. Can you post the output of show ip route (rather than just the eigrp generated routes)?   You mention that there are 3 hosts on the subnet which all show this issue. Are these the only devices in that subnet? Are there any other connected devices in that subnet and if so do they all show the issue or do some of them work ok?   HTH   Rick ... View more