cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
927
Views
15
Helpful
18
Replies

vpn client and site to site tunnel

amit
Level 1
Level 1

We have a site to site tunnel between a PIX 515e and sonicwall. The remote users can connect to the pix and access the LAN. I need to configure the routing on the PIX so that VPN users can access the LAN on the Sonicwall side too. Please let me know how I can achieve this.

18 Replies 18

5220
Level 4
Level 4

Hi,

If you have the remote clients subnet as a part of the PIX LAN subnet, and LAN to LAN is already working, no change is needed.

If it is different then you need to add the follwing:

Extend the LAN-to-LAN crypto ACLs no PIX and sonicwall to contain the remote client's subnet to sonicwall LAN traffic.

For the same traffic, add NAT 0 ACL statement.

Add the routing for the new subnet on the sonicwall to point to the PIX.

PIX changes:

access-list permit ip

access-list permit ip

Please rate if this helped.

Regards,

Daniel

Daniel,

Thanks for the info. I have attached the config part where it specifies this. I think I had this in place but it doesnt work. The sonicwall ip address is 65.*.216.0. The vpn clients are on 10.10.12.0 pool which I want to access the 65.*.216.0 side of lan too.

Please let me know what I am missing.

Hi,

The Split tunneling settings will not tunnel the traffic from 10.10.12.0 to 65.172.2160.0.

Instead of:

access-list mediacy_splitTunnelAcl standard permit 10.10.10.0 255.255.255.0

access-list mediacy_splitTunnelAcl standard permit 10.10.12.0 255.255.255

You can put:

access-list mediacy_splitTunnelAcl extended permit ip 10.10.12.0 255.255.255.0 10.10.10.0 255.255.255.0

access-list mediacy_splitTunnelAcl extended permit ip 10.10.12.0 255.255.255.0 65.172.216.0 255.255.255.0

This should solve your problem.

If you don't use split-tunneling and you consider it a security breach, you can disable it:

group-policy mediacy internal

group-policy mediacy attributes

split-tunnel-policy tunnelall

Please rate if this helped.

Regards,

Daniel

Daniel,

I chenged the access list to an extended access list but no luck still. I cannot get the lan on sonicwall side.

Here is the config. I am using access-list 101 for the split tunneling now.

See the attached config.

Thanks for all you input till now. I am rating your replies.

Daniel,

There is another problem now. When VPN users connect to the LAN they cannot get on to the internet. They can access the LAN but not connect to the internet. I think it has something to do with split tunneling.

Daniel,

I have solved the problem where user couldnt go to the internet. I am still using access-list 101 that I sent you in the config file before but I still cannot connect to the Sonicwall side. Please let me know if there is something wrong I am doing.

Thanks

ggilbert
Cisco Employee
Cisco Employee

Amit,

You access-list 101 is in-correct.

I presume that your internal network is 10.10.10.0/24 right?

If that is the case, then your ACL should be.

access-l 101 per ip 10.10.10.0 255.255.255.0 10.10.12.0 255.255.255.0

access-l 101 per ip 65.172.216.0 255.255.255.0 10.10.12.0 255.255.255.0

After applying the changes, let me know

a. If you are able to access the internal network on the PIX firewall from your VPN clients.

b. If you are able to access the remote site networks on the sonic wall side.

Things to check:

see if the command "same-security-intra-interface" is applied on your device.

Then send me the output of

"sh cry ipsec sa peer x.x.x.1" & "sh cry ipsec sa peer y.y.y.1"

where x.x.x.1 is the outside (routable) IP address of the VPN client & y.y.y.1 is the outside IP address of the sonicwall.

Thanks

Gilbert

Rate it, if this helps!!

Gilbert,

I changed the access-list but still no change. VPN clients can access the LAN but not remote site ( Sonicwall LAN). Here is the

output of sh cry for 10.10.12.1 (vpn Client)

There are no ipsec sas for peer 10.10.12.1

output for sh cry y.y.y.1 (sonicwall side)

Result of the command: "sh cry ipsec sa peer 65.172.216.11"

peer address: 65.172.216.11

Crypto map tag: partner-map, seq num: 30, local addr: 208.51.131.98

access-list outside_cryptomap_30 permit ip 10.10.10.0 255.255.255.0 65.172.216.0 255.255.255.0

local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (65.172.216.0/255.255.255.0/0/0)

current_peer: 65.172.216.11

#pkts encaps: 151878, #pkts encrypt: 151878, #pkts digest: 151878

#pkts decaps: 325046, #pkts decrypt: 325046, #pkts verify: 325046

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 151878, #pkts comp failed: 0, #pkts decomp failed: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: 208.51.131.98, remote crypto endpt.: 65.172.216.11

path mtu 1500, ipsec overhead 60, media mtu 1500

current outbound spi: 8ACEEF90

inbound esp sas:

spi: 0x871A9A87 (2266667655)

transform: esp-3des esp-md5-hmac

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 1963, crypto-map: partner-map

sa timing: remaining key lifetime (kB/sec): (4271094/15334)

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0x8ACEEF90 (2328817552)

transform: esp-3des esp-md5-hmac

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 1963, crypto-map: partner-map

sa timing: remaining key lifetime (kB/sec): (4274050/15334)

IV size: 8 bytes

replay detection support: Y

ggilbert
Cisco Employee
Cisco Employee

Amit,

"sh cry ipsec sa peer 10.10.12.1" is not the right command.

The right command should be "sh cry ipsec sa per x.x.x.x" where x.x.x.x is the "Public" IP address of the client.

Seems like the second SA is not created from the ASA to the sonic wall.

Kindly send the above request output. We can move from there.

Thanks

gilbert

Gilbert this is the result of the command

peer address: 72.205.25.144

Crypto map tag: cisco, seq num: 20, local addr: 208.51.131.98

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (10.10.12.30/255.255.255.255/0/0)

current_peer: 72.205.25.144, username: amit

dynamic allocated peer ip: 10.10.12.30

#pkts encaps: 264, #pkts encrypt: 264, #pkts digest: 264

#pkts decaps: 243, #pkts decrypt: 243, #pkts verify: 243

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 264, #pkts comp failed: 0, #pkts decomp failed: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: 208.51.131.98/4500, remote crypto endpt.: 72.205.25.144/4500

path mtu 1500, ipsec overhead 68, media mtu 1500

current outbound spi: FB278730

inbound esp sas:

spi: 0x790BC7FA (2030815226)

transform: esp-des esp-md5-hmac

in use settings ={RA, Tunnel, NAT-T-Encaps, }

slot: 0, conn_id: 2035, crypto-map: cisco

sa timing: remaining key lifetime (sec): 23889

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0xFB278730 (4213671728)

transform: esp-des esp-md5-hmac

in use settings ={RA, Tunnel, NAT-T-Encaps, }

slot: 0, conn_id: 2035, crypto-map: cisco

sa timing: remaining key lifetime (sec): 23889

IV size: 8 bytes

replay detection support: Y

Gilbert I also checked for the command

same-security-traffic permit intra-interface

It is being applied.

could anyone please help me out.

ggilbert
Cisco Employee
Cisco Employee

send me an email ggilbert@cisco.com

I will help you out.

Thanks

gilbert

I will help you out. Looking at the output you sent, it seems like there is only one ipsec session that has been created for the VPN clients.

So, I need to know if the ACL pushed to the VPN client is done properly.

Can you check on the VPN client if the "secured NEtwork" tab has those two networks that ought to be there.

Thanks

Gilbert

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: