MarkNethercott
asked on
Cisco 837 ADSL Router: Adding Routes to a LAN-to-LAN VPN tunnel
This is a conceptual/architectural question at the moment. I'm not sure 'how' I'm supposed to make this work before I get to the detail of 'what' I need to do.
I have a central Cisco 3030 VPN Concentrator with the internal interface attached to 10.7.30.0/24 this (LAN) is attached to one of 5 interfaces on a Cisco PIX 515E
nameif ethernet0 outside security0
nameif ethernet1 inside security100 10.7.4.0/24 - 10.7.4.1
nameif ethernet2 dmz security50 10.7.20.0/24 - 10.7.20.1
nameif ethernet3 vpn security85 10.7.30.0/24 - 10.7.30.1
nameif vlan201 ilo security90 10.7.1.0/24 - 10.7.1.1
The local client is 10.13.10.2 on the 10.13..0.0/16 network connected to a Cisco 837 ADSL router
The 837 has NAT established
Uses Route Map SDM_RMAP_1 that in turn uses access-list 101
access-list 101
deny ip 10.13.0.0 0.0.255.255 10.7.30.0 0.0.0255
permit ip 10.13.0.0 0.0.255.255 any
There is NO firewall configured on the 837
The VPN tunnel uses IPSec rule 100
access-list 100
permit ip 10.13.0.0 0.0.255.255 10.7.30.0 0.0.0.255
I have established a VPN tunnel between 10.13.0.0/16 and 10.7.30.0/24
I can ping 10.7.30.1 from the local client
From the VPN concentrator, I can ping a host on the 10.7.20.0/24 network (10.7.20.27), but I cannot ping 10.7.20.27 from the local client (10.13.10.2)
So my question in general terms is how do I get the 837 to route traffic to 10.7.20.0/24 through the VPN.
I thought (& have tried) that
a) I'd need to modify the NAT access-list (101) to deny traffic to 10.7.20.0/24 to stop it being NAT'd
b) I'd need to modify the IPSec rule to permit 10.7.20.0 traffic
I think I've missed a step because
i. a tracert on 10.7.20.27 shows it being routed out along the ADSL (external) circuit
ii. ping still fails
I have a central Cisco 3030 VPN Concentrator with the internal interface attached to 10.7.30.0/24 this (LAN) is attached to one of 5 interfaces on a Cisco PIX 515E
nameif ethernet0 outside security0
nameif ethernet1 inside security100 10.7.4.0/24 - 10.7.4.1
nameif ethernet2 dmz security50 10.7.20.0/24 - 10.7.20.1
nameif ethernet3 vpn security85 10.7.30.0/24 - 10.7.30.1
nameif vlan201 ilo security90 10.7.1.0/24 - 10.7.1.1
The local client is 10.13.10.2 on the 10.13..0.0/16 network connected to a Cisco 837 ADSL router
The 837 has NAT established
Uses Route Map SDM_RMAP_1 that in turn uses access-list 101
access-list 101
deny ip 10.13.0.0 0.0.255.255 10.7.30.0 0.0.0255
permit ip 10.13.0.0 0.0.255.255 any
There is NO firewall configured on the 837
The VPN tunnel uses IPSec rule 100
access-list 100
permit ip 10.13.0.0 0.0.255.255 10.7.30.0 0.0.0.255
I have established a VPN tunnel between 10.13.0.0/16 and 10.7.30.0/24
I can ping 10.7.30.1 from the local client
From the VPN concentrator, I can ping a host on the 10.7.20.0/24 network (10.7.20.27), but I cannot ping 10.7.20.27 from the local client (10.13.10.2)
So my question in general terms is how do I get the 837 to route traffic to 10.7.20.0/24 through the VPN.
I thought (& have tried) that
a) I'd need to modify the NAT access-list (101) to deny traffic to 10.7.20.0/24 to stop it being NAT'd
b) I'd need to modify the IPSec rule to permit 10.7.20.0 traffic
I think I've missed a step because
i. a tracert on 10.7.20.27 shows it being routed out along the ADSL (external) circuit
ii. ping still fails
ASKER
Thanks for the response.
I've tried that earlier (a) above), which didn't fix the issue, though I may need to add in some extra bits...
1. Do I need (or not need) to add the NAT acl modification to prevent 10.7.20 traffic?
2. Does the VPN tunnel definition at the concentrator need to allow traffic to 10.7.20.0 as well as 10.7.30.0 even though it's being routed across the 10.7.30 network?
I've tried that earlier (a) above), which didn't fix the issue, though I may need to add in some extra bits...
1. Do I need (or not need) to add the NAT acl modification to prevent 10.7.20 traffic?
2. Does the VPN tunnel definition at the concentrator need to allow traffic to 10.7.20.0 as well as 10.7.30.0 even though it's being routed across the 10.7.30 network?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
WIthout seeing your config, I don't know what your access list 100 is doing. You may want to sanitize and post your config.
Below is a sample configlet from my IPSEC lab setup. This config allows traffic from 192.168.1.0/24 destined for several networks to be encrypted. Access list 105 describes the "interesting" traffic. Interesting traffic is any source of 192.168.1.0/24 and any of the following destination networks: 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 192.168.2.0/24 and 192.168.3.0/24. Any traffic from 192.168.1.0/24 destined for any of the 5 networks will trigger the IPSEC negotiation.
!
crypto isakmp policy 100
hash md5
authentication pre-share
group 2
lifetime 2800
crypto isakmp key cisco address 192.168.2.2
!
crypto ipsec transform-set myset ah-md5-hmac esp-des esp-md5-hmac
!
crypto map mymap 100 ipsec-isakmp
set peer 192.168.2.2
set transform-set myset
set pfs group2
match address 105
!
interface Loopback0
no ip address
!
interface Ethernet0
ip address 192.168.1.5 255.255.255.0
!
interface Serial0
ip address 192.168.2.1 255.255.255.252
clockrate 56000
crypto map mymap
!
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0
ip route 10.1.1.0 255.255.255.0 Serial0
no ip http server
!
access-list 105 permit ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 10.1.2.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 10.1.3.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
Below is a sample configlet from my IPSEC lab setup. This config allows traffic from 192.168.1.0/24 destined for several networks to be encrypted. Access list 105 describes the "interesting" traffic. Interesting traffic is any source of 192.168.1.0/24 and any of the following destination networks: 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 192.168.2.0/24 and 192.168.3.0/24. Any traffic from 192.168.1.0/24 destined for any of the 5 networks will trigger the IPSEC negotiation.
!
crypto isakmp policy 100
hash md5
authentication pre-share
group 2
lifetime 2800
crypto isakmp key cisco address 192.168.2.2
!
crypto ipsec transform-set myset ah-md5-hmac esp-des esp-md5-hmac
!
crypto map mymap 100 ipsec-isakmp
set peer 192.168.2.2
set transform-set myset
set pfs group2
match address 105
!
interface Loopback0
no ip address
!
interface Ethernet0
ip address 192.168.1.5 255.255.255.0
!
interface Serial0
ip address 192.168.2.1 255.255.255.252
clockrate 56000
crypto map mymap
!
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0
ip route 10.1.1.0 255.255.255.0 Serial0
no ip http server
!
access-list 105 permit ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 10.1.2.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 10.1.3.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
The VPN tunnel uses IPSec rule 100
access-list 100
permit ip 10.13.0.0 0.0.255.255 10.7.30.0 0.0.0.255
permit ip 10.13.0.0 0.0.255.255 10.7.20.0 0.0.0.255 <===add this
Also make sure that your tunnel definition on the concentrator matches the remote end. A best practice is to mirror your crypto ACLs for each VPN tunnel.