Trying to configure a 827 to act as a remote endpoint for a VPN to a PIX 515. The IPSec & ISAKMP sa's will come up just fine, however, the problem is to pass traffic to and from clients on the 827 ethernet-network. What is really interesting is that there is no problem to communicate when sending a ping from the router to the network behind the PIX.
When trying to send a ping from a client behind the 827, the packet wont even show up in the counters for the crypto engine. When trying to ping the same client from the PIX lan, the packet will increase the crypto engine counter but there will be no response. From my point of view it seems that there is a *huge* data-loss between the crypto engine and the interface. I've tried to decrease the MTU but that didn't help. The access-list is configured for the entire network, and not a single host.
I'm on my way to open a TAC-case for this, however, it would be interesting to see if anyone of you have seen this problem before.
If you don't even see the packet from the local host make it to the crypto engine of the 827 router, it may not even be getting to that router in the first place. It looks like your local network is 192.168.15.0/24, and you're trying to route packets to the PIX which has a 192.168.0.0/16 network.
Are you sure the default gateway on the local host is set correctly (should be the 827 router's inside interface)? Are you sure its subnet mask is set correctly, make sure it doesn't have a 16-bit mask on it cause then it's going to think the remote network is local and will just be ARP'ing for that remote address?
Does it work from any other local PC behind the 827? It really just sounds like a routing issue on the network behind the 827.
The local network is 192.168.15.0/24 and the remote network is 192.168.1.0/24, however, for scalability reasons in this kind of solutions I have a policy of excluding any packets from the local network to any private network that might need to be reached from the remote site ... Access-list 130 was only for the NAT process.
On interface BVI1, I've applied the crypto map and in the crypto map it says 'match address 120', access-list 120 permits ip with source of 192.168.15.0/24 and destination of 192.168.1.0/24.
I'm very sure that the default gateway and subnetmask etc is correct since the packets will show up on debug when the router just booted, before it has got the chance to initialize the tunnel, but when the tunnel has been established the packets just disappears from 'debug ip packet', that's what -really- confuses me.
Since the BVI1 has a dynamically assigned address, when the router just booted if you enter 'debug ip packet' it will discard the packets as unroutable (of course, it has not got either the public ip address nor the default gateway yet) and when the packet is routable, i receive a debug message for the ip packet stating something like crypto engine not ready, unfortunally, I'm not on site at the moment, so I don't remember the exact message. When the tunnel has been established, I don''t receive any other debugs for that session ... :(
Tried with another PC as well, same problem. That was one of my first toughts, since the machine that was doing the continusly pings has been out of production for a while, it could have been that one that was causing the problems, however, the problems persisted with other clients.
Perhaps I should mention that extremly few packets (like 10 out 1000) gets trough. I've tried with higher timeouts, smaller packet size, and so on, without any difference.
Pings TO the remote network does not work either, however, when trying to send a ping from the HQ LAN to the remote network, the counter in the crypto engine increases, but there is no action from debug ip packet in that direction either... :(
Both the 827 and the PIX has been rebooted, of course.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...