Thank-you. That bug is exactly what happens to me; your hint increased my understanding of the problem, unfortunately, the bug solution do not solve it. Maybe it is drawed for lan-to-lan vpn. I run pix version 8.0.3 and I can write the command: "pix(config)#sysopt connection reclassify-vpn", but without effect.

What happen is: starting with all up and running (remote access vpn, gre tunnel and ospf), if the vpn drops, the local_gre machine continue to send gre pachets to the tunnel destination. Without vpn up, theese packets are erroneously translated out the outside interface by the pix and this continue also when the vpn return up. To work-around the problem, I stop theese pakets to time-out this wrong connection. Now, thanks to you, I learned also the command "pix#clear local-host" to drop the connection.

In my actual case I chosen another workaround: I added a static route to the pix to return back gre packets to inside. When the vpn is up, the pix assign the address to the remote ezvpn_client and ignore the static route.

I hope Cisco will extend the command "...reclassify-vpn" also to the remote access.

Bye. Efrem