[c-nsp] PIX IPSEC tunnel initiation (110001: No route to dst_addrfrom src_addr)...

[Tim Bulger]

In this particular case, it doesn't even attempt isakmp or IPSec
negotiations.. It seems to just drop the packets.  In fact, it attempts to
send the standard 3 pings, but the event only appears once in the log.  If I
remove the associated line from the access list, it will send the packet
source NAT'ed to the outside IP of the firewall (as expected).

-Tim

-----Original Message-----
From: Church, Chuck [mailto:cchurch at netcogov.com] 
Sent: Wednesday, July 13, 2005 9:20 PM
To: Tim Bulger; cisco-nsp
Subject: RE: [c-nsp] PIX IPSEC tunnel initiation (110001: No route to
dst_addrfrom src_addr)...

Does it try to bring up the tunnel when you do that, and possibly give you
that error message when the isakmp or IPSec fails? 


Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation 1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
cchurch at netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D


-----Original Message-----
From: Tim Bulger [mailto:timb at phreakocious.net]
Sent: Thursday, July 14, 2005 12:00 AM
To: Church, Chuck; 'cisco-nsp'
Subject: RE: [c-nsp] PIX IPSEC tunnel initiation (110001: No route to
dst_addrfrom src_addr)...

Pinging from the inside interface will source the packet from an IP address
that is included as a source in the 'match address' access list and bring
the tunnel up (this has always been my experience).  Pinging from the
outside interface results in it actually sending from the outside IP
unencrypted.  I have also tried things like 'route outside 172.28.8.0
255.255.255.0 default_gw' and got the same message.  6.2(4) had a switch
called 'sysopt route dnat' which had no noticeable effect in any
configuration.

Thanks!

http://phreakocious.net/brokenPIX.txt

-----Original Message-----
From: Church, Chuck [mailto:cchurch at netcogov.com]
Sent: Wednesday, July 13, 2005 8:39 PM
To: Tim Bulger; cisco-nsp
Subject: RE: [c-nsp] PIX IPSEC tunnel initiation (110001: No route to
dst_addrfrom src_addr)...

172.28.8.0/24 is a destination defined in the crypto map.  The crypto stuff
is all applied to the outside interface.  Trying to ping it via the inside
interface when no route is defined for it on the inside seems to be the
cause.  Try pinging it via the outside interface.  Then again, I'm not sure
if the locally-generated traffic will cause the IPSec tunnel to come up.



Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team 1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
cchurch at netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tim Bulger
Sent: Wednesday, July 13, 2005 10:47 PM
To: 'cisco-nsp'
Subject: [c-nsp] PIX IPSEC tunnel initiation (110001: No route to
dst_addrfrom src_addr)...

I have a truly strange problem with a PIX initiating an IPSEC tunnel.
The
error message that I get when I attempt to do a 'ping inside 172.28.8.1'
is
'110001: No route to 172.28.8.1 from 172.29.8.1'.  This is an extremely
straightforward configuration and was working yesterday, but stopped during
the process of experimenting to find the optimal 'isakmp keepalive'
value.
I don't have any complexity to my routing table or overlapping routes, and I
have a functional default gateway configured.  I have tried this on 6.2(4),
6.3(3), and 6.3(4).  I have stuck with 6.3(3) because with 6.3(4), I can
watch my free memory drop by about .5MB/sec until there is almost none left
and the device becomes unstable.

Sorry for the long winded email, but I don't have much hair left to tear
out. :)  Any help would be greatly appreciated.  
-Tim

Sanitized config follows: