Problem with UDP traffic leaving ASA after it arrives over a VPN tunnel

[baskervi]

We have two ASA's running 8.0(3)6, with one set up as the EZVPN server and the other as the EZVPN client. The EZVPN server forwards the packets internally to a FWSM running an old version of firmware (2.3(2)) configured in our core switch. Between the EZVPN server and the FWSM there are a couple switches with trunks configured on them. There are no SVIs on any of the switches except for management.

All TCP traffic makes it round trip across the tunnel and to the hosts connected to the switch where the FWSM resides. However, only UCP/123 and 137 make it round trip. I've set up a packet capture on the EZVPN server, and I see all UDP packets arrive and appear to leave the firewall. However, I only see the two UDP packets actually arrive at the FWSM. The FWSM has an access list with "permit IP any any" and with static 1:1 NATs for the entire subnet. The servers are not running a firewall, and a "netstat -rn" has not extraneous routes. We get the same results for all hosts on the core switch over the VPN. We have no problems with any traffic between the various firewalled VLANs.

I'm at a loss. Does anyone have any thoughts? Thank you.

[Ramraj Sivagnanam Sivajanam]

Hi Bro

Perhaps, there's a/few devices that's sitting in between your EZVPN Server and FWSM that's dropping this traffic e.g. IPS? Do you have a complete physicall diagram between between your EZVPN Server and FWSM? It would be nice to see it, so that I can assist your further.

Assuming there 2 Cisco Access switches between your EZVPN Server and FWSM, something like this;

EZVPN Server --> Switch-A --> Switch-B --> Core Switch --> FWSM

As you've already mentioned, you can see the UDP packets leaving the INSIDE interface of the EZVPN Server heading towards the FWSM but FWSM sees very little. Lets place a PC with wireshark on Switch-A to verify if the UDP packets arrive in Switch-A. If yes, then do the same for Switch-B and so on, and so forth.

The bottom line here is to identify the product that's in between the EZVPN Server and FWSM, which is swallowing the UDP packets for dinner :-).

P/S: If you think my comments are helpful, please do rate them nicely :-)

[baskervi]

Thanks for the reply. I had all the equipment in our lab, so I blew away the old configuration and redid it. I didn't keep the old configuration and do a comparison, but I didn't have any problems with the second round. Sorry for not closing down this thread.

[nkarthikeyan]

Hi Basker,

There could be the possible reasons. check MTU settings from end to end.

Check if any speed / duplex mismatches on the switches/fwsm/asa interfaces.... CPU usage as well.

If possible check by connection a local host to the VPN server and try without VPN to FWSM.... preferably do a pathping from the host and check any drops.....

Let me check other possible ways as well.