2950 can only be accessed after initiating a ping from the switch first

[nnorthedge]

Hair pull out time. I have a 2950 behind a firewall, 501. I have teh default route set up with the firewall address. External to the firewall, I can ping the entire network, except the 2950, which I set up with an IP address assisgned to VLAN1. From the firewall I can ping the switch.

I have some one access the switch locally, either through telnet or console port and ping my address, external to the local network. The ping is successful. Now I can ping and telnet to the switch from my external location.

I manually added an arp entry for the firewall interface, but this doesn't help. Seems the access times out like an arop table entry. I don't know what is really transpiring here.

Any body have any ideas?

Norman

[steve.barlow]

The PIX can always ping the switch, even when you externally can't? If yes it's not arp (FYI, arp default timeout is 4 hours). If no, did it work when you add the static arp (ie before it times out)?

Can you debug icmp trace and/or debug packet ..... ? Show xlate/sh conn displays the icmp going through the PIX?

Steve

[nnorthedge]

Yes, the PIX can always ping the switch. Here is the sho xlate and conn. I have a ping running every 15 seconds at the moment.

pix501# sho xlate

1 in use, 4 most used

Global 192.168.6.2 Local 192.168.6.2

pix501# sho conn

0 in use, 20 most used

Here is the debug icmp trace output while the connection works.

5: Inbound ICMP echo request (len 56 id 62766 seq 320) 192.168.192.12 > 192.168.6.2 > 192.168.6.2

6: Outbound ICMP echo reply (len 56 id 62766 seq 320) 192.168.6.2 > 192.168.6.2 > 192.168.192.12

7: Inbound ICMP echo request (len 56 id 62766 seq 321) 192.168.192.12 > 192.168.6.2 > 192.168.6.2

8: Outbound ICMP echo reply (len 56 id 62766 seq 321) 192.168.6.2 > 192.168.6.2 > 192.168.192.12

9: Inbound ICMP echo request (len 56 id 62766 seq 322) 192.168.192.12 > 192.168.6.2 > 192.168.6.2

10: Outbound ICMP echo reply (len 56 id 62766 seq 322) 192.168.6.2 > 192.168.6.2 > 192.168.192.12

I'll do the debug again after the switch "times out"

Norman

[nnorthedge]

Thanks Steve. This made me realize what was going on. Even though I have NAT off (NAT 0), the xlate is still there. I assigned a static xlate to the switch address and now it works. That is twice the NAT has caught me. Even though it is not doing NAT, per se, the firewall is still doing NAT. So if the session is not up on the inside, there is no mapping for the firewall to get to the destination from the outside, even if it is the same IP address that I want.

Norman

[steve.barlow]

When you post the debug of the time outs, can you also post the VPN configs as well (VPN assumed based on the IP)? Could it be that the VPN tunnel can't be created for accessing the switch and only works when the tunnel is already up (just a thought)?

Steve

[nnorthedge]

Just got you latest. As this is an internal firewall, I am not using VPN, just trying to keep different departments separate. But I stll need access when troubleshooting.

Norman

[steve.barlow]

Please disregard my last post, not sure what I was thinking.