cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
269
Views
0
Helpful
2
Replies

VPN3005 to PIX506e

sdvandeslunt
Level 1
Level 1

I've been banging my head against a desk all day over this one... and I know its gotta be something I just overlooked... I'm trying to set up a LAN-to-LAN connection between these two devices using pre-shared keys.

IKE = good

IPSec tunnel = online.

IP traffic from PIX to VPN3005 seems good...

IP Traffice from VPN3005 to PIX... nadda!

help! I noticed the private subnet we use "192.168.x.x" was in the same range as the private subnet on the PIX "192.168.40.x" so I did define a static route for that 192.168.40.0/24 subnet to "outside" on the VPN3005.

What else could I be missing?!? The "session list" on the VPN3005 shows the tunnel up but 0 bytes sent (about 30k and climbing on bytes recieved due to a "ping -t" I have running on a client machine on the PIX side)

The PIX has a DHCP address coming in the "outside" interface and assigns DHCP to its "inside"

The VPN3005 is static all the way around.

Any suggestions you have would be appreciated! Configs available on request!

-Scott

2 Replies 2

Fernando_Meza
Level 7
Level 7

Ok .. the tunnel is definetely up .. This seems to be a routing issue ... Double check that your lan which I suspect is behind the concetrator knows how to reach the LAN behind the PIX. What is the default gateway been used on the LAN behind the concetrator ..? You need to check the routes on this device.

Also .. are any of the two devices been NATed because if they are they need to be NAT traversal enabled.

On the PIX isakmp nat-traversal 20

on the concentrator Configuration | System | Tunneling Protocols | IPSec | LAN-to-LAN | Modify ans select IPsec NAT-T ... also you need to go to Configuration | System | Tunneling Protocols | IPSec | NAT Transparency ans tick Ipsec NAT-T

But again .. I am almost 100% sure it has to be a routing issue !!!

I hope it helps ... please rate it if does !!!

I agree that it has to be a routing issue. I'd go one step further and say it's more than likely a routing issue at the VPN3000.

How does the VPN3000 know when to send "interesting" traffic over the tunnel? the answer to that question is probably the answer I need. It seems like no traffic is being pushed over the tunnel and instead 192.168.40.x pings are being pushed to the internet directly...

I tried your suggestions but to no avail.

Thanks for anything you can tell me.

-Scott