vpn client and site to site tunnel

Unanswered Question
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Daniel Voicu Sat, 02/03/2007 - 09:15

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 Voicu Sun, 02/04/2007 - 02:40

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

ggilbert Mon, 02/05/2007 - 18:33

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 Tue, 02/06/2007 - 07:32

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

ggilbert Thu, 02/08/2007 - 07:53

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

ggilbert Thu, 02/08/2007 - 07:58

Also, I looked into your group-policy posted previously -

It seems that you have configured for tunnel all.

So, all the traffic will be sent through the tunnel.

If that is the case, then the "sh cry ipsec sa" that you sent is correct. (You are not doing split tunneling).

Let me look at the config of the Lan to Lan tunnel now.

ggilbert Thu, 02/08/2007 - 08:25

Amit -

Thanks for responding and your patience.

A - If you want to the clients to access the internet when they are connected through the VPN client, then you have something configured wrong on the ASA.

If you look at the group-policy to which these clients will be connecting, the split-tunnel list you configured 101, is not applied.

B - After the VPN clients are connected, please click on the lock icon - check the statistics and you will see the secured routes.

Thanks

Gilbert

ggilbert Mon, 02/12/2007 - 06:11

Amit,

So you checked with the sonic wall for the ACL's that needs to be encrypted and everything is working now.

Cheers

Gilbert

Rate it, if these posts helped.

Actions

This Discussion