02-02-2007 08:05 PM - edited 02-21-2020 02:51 PM
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.
02-03-2007 09:15 AM
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
access-list
Please rate if this helped.
Regards,
Daniel
02-03-2007 03:21 PM
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.
02-04-2007 02:40 AM
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
02-04-2007 07:30 AM
02-04-2007 09:22 AM
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.
02-04-2007 10:16 AM
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
02-05-2007 06:33 PM
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!!
02-06-2007 07:12 AM
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
02-06-2007 07:32 AM
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
02-06-2007 08:11 AM
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
02-06-2007 07:27 AM
Gilbert I also checked for the command
same-security-traffic permit intra-interface
It is being applied.
02-08-2007 06:45 AM
could anyone please help me out.
02-08-2007 06:46 AM
02-08-2007 07:53 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide