PIX-515 to RVS4000 Site-Site VPN Issue

C

Captain Colonoscopy

2[H]4U
Joined
Feb 19, 2004
Messages
3,861
So, I have this client that needs to get a VPN tunnel established between their firm and another that they are partnering with on some project so they can share files or something. Client has a Cisco PIX515 and the partner firm has a Linksys RVS4000 firewall. I am pretty sure I have the tunnel setup on both sides correctly as the tunnel comes up but I can't pass any traffic over it from either direction. To make matters worse the partner firm has McCrappy Security Suite installed on all their desktops. So, if someone could take a look and see if they can spot something that I am missing that would be greatly appreciated.

Here are the pertinent portions of the Cisco PIX515 config:

access-list vpn permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list vpn permit ip 10.1.0.0 255.255.0.0 192.168.1.0 255.255.255.0
access-list vpn permit ip 10.1.0.0 255.255.0.0 10.254.1.0 255.255.255.0
access-list ipsec permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list split-tunnel permit ip 10.1.0.0 255.255.0.0 10.254.1.0 255.255.255.0
access-list outside_cryptomap_30 permit ip 10.1.0.0 255.255.0.0 192.168.1.0 255.255.255.0

nat (inside) 0 access-list vpn

crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac

crypto map vpnmap 30 ipsec-isakmp
crypto map vpnmap 30 match address outside_cryptomap_30
crypto map vpnmap 30 set peer 7x.20x.22x.11x
crypto map vpnmap 30 set transform-set 3DES-MD5

isakmp enable outside
isakmp key ******** address 7x.20x.22x.11x netmask 255.255.255.255 no-xauth no-config-mode
isakmp identity address
isakmp nat-traversal 20
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 28800
Click to expand...

Here is the configuration on the RVS4000 side of things:
rohrbachkdent.jpg
 
I think your in luck I actually have this same set up. I am connected to 2 seperate PIX's one is a 515. I will have to check when I get home though. I know I am using SHA1

One Question though is the 192.168.1/24 subnet the local subnet of the RVS4000?

You can try pinging from one of the routers to the other side and see if you can hit a PC that way. Then you will know if its MCAfee
 
jratzo said:
I think your in luck I actually have this same set up. I am connected to 2 seperate PIX's one is a 515. I will have to check when I get home though. I know I am using SHA1

One Question though is the 192.168.1/24 subnet the local subnet of the RVS4000?

You can try pinging from one of the routers to the other side and see if you can hit a PC that way. Then you will know if its MCAfee
Click to expand...

I might try switching to SHA1 and see what happens.

I've been trying to ping from the pix and the rvs and neither one can ping anything on the other side of the tunnel.


Here are some debugs from the PIX when I connect the tunnel from the RVS side:

crypto_isakmp_process_block:src:7x.20x.22x.11x, dest:6x.13x.8x.5x spt:500 dpt:500
OAK_QM exchange
oakley_process_quick_mode:
OAK_QM_IDLE
ISAKMP (0): processing SA payload. message ID = 2121037977

ISAKMP : Checking IPSec proposal 0

ISAKMP: transform 0, ESP_3DES
ISAKMP: attributes in transform:
ISAKMP: encaps is 1
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 28800
ISAKMP: authenticator is HMAC-MD5
ISAKMP (0): atts are acceptable.IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 6x.13x.8x.5x, src= 7x.20x.22x.11x,
dest_proxy= 10.1.0.0/255.255.0.0/0/0 (type=4),
src_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4

ISAKMP (0): processing NONCE payload. message ID = 2121037977

ISAKMP (0): processing ID payload. message ID = 2121037977
ISAKMP (0): ID_IPV4_ADDR_SUBNET src 192.168.1.0/255.255.255.0 prot 0 port 0
ISAKMP (0): processing ID payload. message ID = 2121037977
ISAKMP (0): ID_IPV4_ADDR_SUBNET dst 10.1.0.0/255.255.0.0 prot 0 port 0IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0xd2224831(3525462065) for SA
from 7x.20x.22x.11x to 6x.13x.8x.5x for prot 3

return status is IKMP_NO_ERROR
crypto_isakmp_process_block:src:7x.20x.22x.11x, dest:6x.13x.8x.5x spt:500 dpt:500
OAK_QM exchange
oakley_process_quick_mode:
OAK_QM_AUTH_AWAIT
ISAKMP (0): Creating IPSec SAs
inbound SA from 7x.20x.22x.11x to 6x.13x.8x.5x (proxy 192.168.1.0 to 10.1.0.0)
has spi 3525462065 and conn_id 7 and flags 4
lifetime of 28800 seconds
outbound SA from 6x.13x.8x.5x to 7x.20x.22x.11x (proxy 10.1.0.0 to 192.168.1.0)
has spi 2142594013 and conn_id 8 and flags 4
lifetime of 28800 secondsIPSEC(key_engine): got a queue event...
IPSEC(initialize_sas): ,
(key eng. msg.) dest= 6x.13x.8x.5x, src= 7x.20x.22x.11x,
dest_proxy= 10.1.0.0/255.255.0.0/0/0 (type=4),
src_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 28800s and 0kb,
spi= 0xd2224831(3525462065), conn_id= 7, keysize= 0, flags= 0x4
IPSEC(initialize_sas): ,
(key eng. msg.) src= 6x.13x.8x.5x, dest= 7x.20x.22x.11x,
src_proxy= 10.1.0.0/255.255.0.0/0/0 (type=4),
dest_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 28800s and 0kb,
spi= 0x7fb563dd(2142594013), conn_id= 8, keysize= 0, flags= 0x4
IPSEC(add_sa): peer asks for new SAs -- expire current in 30 sec.,
(sa) sa_dest= 6x.13x.8x.5x, sa_prot= 50,
sa_spi= 0x293254cb(691164363),
sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 3,
(identity) local= 6x.13x.8x.5x, remote= 7x.20x.22x.11x,
local_proxy= 10.1.0.0/255.255.0.0/0/0 (type=4),
remote_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4)
IPSEC(add_sa): peer asks for new SAs -- expire current in 30 sec.,
(sa) sa_dest= 7x.20x.22x.11x, sa_prot= 50,
sa_spi= 0x7fb563dc(2142594012),
sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 4,
(identity) local= 6x.13x.8x.5x, remote= 7x.20x.22x.11x,
local_proxy= 10.1.0.0/255.255.0.0/0/0 (type=4),
remote_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4)

return status is IKMP_NO_ERROR
Click to expand...
 
Nice, was just about to check out my settings. My MTU is set to auto.

Glad you got it working
 
Yeah, me too. After I got the tunnel working I had the displeasure of setting up their McAfee software firewall to allow the traffic to the hosts on the remote end. Farking McAfee.
 
You must log in or register to reply here.
Back
Top