Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VPN Routing Question

Status
Not open for further replies.

slaquer

Technical User
Jul 29, 2008
11
US
I originally posted this over at the VPN forum, but did not receive much help so I am trying here.

Remote clinic - Cisco 831 router - 192.168.180.0 internal subnet

Local office - Cisco PIX firewall - 192.168.120.0, 192.168.140.0, 192.168.100.0, and 192.168.160.0 internal subnets

L2L IPSEC VPN tunnel works great, but the 192.168.180.0 users on the remote clinic can only communicate with the 192.168.100.0 subnet on the local site. All other traffic intended for the local site goes out the internet. It appears that the Crypto map is setup for the other subnets but it is not routing across the VPN.

Any help would appreciated.

Bulk of config for remote clinic below:


crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key DELETED address 70.182.XX.XXX
!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
description Tunnel to70.182.XX.XXX
set peer 70.182.XX.XXX
set transform-set ESP-3DES-SHA ESP-3DES-SHA1 SA2 SA3
match address 102
!
!
!
interface Ethernet0
description $ETH-LAN$
ip address 192.168.180.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Ethernet1
description $ETH-WAN$
ip address 98.190.XX.XXX 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
crypto map SDM_CMAP_1
!
ip classless
ip route 0.0.0.0 0.0.0.0 98.190.XX.XXX permanent
ip http server
ip http authentication local
ip http secure-server
ip nat inside source route-map SDM_RMAP_1 interface Ethernet1 overload
!
!
access-list 1 remark SDM_ACL Category=2
access-list 1 permit 192.168.180.0 0.0.0.255
access-list 100 remark SDM_ACL Category=4
access-list 100 remark IPSec Rule
access-list 100 permit ip 192.168.180.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 100 permit ip 192.168.180.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 100 permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
access-list 101 remark SDM_ACL Category=2
access-list 101 remark IPSec Rule
access-list 101 deny ip 192.168.180.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 192.168.180.0 0.0.0.255 any
access-list 102 remark SDM_ACL Category=4
access-list 102 remark IPSec Rule
access-list 102 permit ip 192.168.180.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 102 permit ip 192.168.180.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 102 permit ip 192.168.180.0 0.0.0.255 192.168.140.0 0.0.0.255
route-map SDM_RMAP_1 permit 1
match ip address 101
 
Your access-list 102 only permits communication to .100 and .140. Can you get to anything on the .140 subnet??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)
 
No I cannot. It tries to go out the internet.

thanks
 
Post a sh run from the PIX. Also, you are only permitting traffic to 172.16.0.0/24, 192.168.100.0/24 and 192.168.1.140/24, and here you say, "Local office - Cisco PIX firewall - 192.168.120.0, 192.168.140.0, 192.168.100.0, and 192.168.160.0 internal subnets"
I would try
ip route 192.168.1.140 255.255.255.0 98.190.XX.XXX
but that depends on the conduits in the PIX...

Burt
 
I will post the PIX config tomorrow AM. Even if the conduits on the PIX didn't allow for those other internal subnets to pass, wouldn't I see my attempts to those subnets from the remote site blocked at the firewall (and wouldn't I see those attempts try to go across the VPN and not the internet)?

I just hadn't added the other subnets yet a I was just trying to get the 140 subnet to cross. I figured once I got that to work, the others would be easy.

Thanks
 
Got it.
It's a stretch, but the PIX could be routing the traffic back out to the internet (?)
Another thing to try is maybe take out the statement for 100.0 and keep the 140.0, then see if you're able to get to 140.0
Might as well try the other subnets to see if there's just something freaky about 140.0...also, have you tried sniffing the line, or posting the results of a trace from remote to 140.0, and a trace from remote to 100.0...

Burt
 
You need to rewrite your nat rule so that you aren't nating traffic that is suppose to traverse the vpn
 
It already is, brian---

access-list 101 deny ip 192.168.180.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 192.168.180.0 0.0.0.255 any

I would write the first one as
access-list 101 deny ip any 192.168.100.0 0.0.0.255
along with the other two subnets, and

WAIT!
Oh, crap...I can't believe I missed that...

Brian hit it right on the head...

access-list 101 deny ip 192.168.180.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 101 deny ip 192.168.180.0 0.0.0.255 192.168.120.0 0.0.0.255
access-list 101 deny ip 192.168.180.0 0.0.0.255 192.168.160.0 0.0.0.255
access-list 101 deny ip 192.168.180.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 101 permit ip 192.168.180.0 0.0.0.255 any

That's why you were able to get to .100---the first line in the NAT ACL...

Burt

 
So, just point out how much of a moron I am (and for those who may run across this thread in the future), we are blocking that traffic from going out the internet with the 101 access-list, then permitting it to cross the VPN using 102. Correct?

This worked great by the way. Thanks a lot you guys.
 
No---you're blocking it from being NATted with 101, then permitting it with 102. Brian pointed out the thing that was right in front of us (which incidentally is where my wife hides things from me...right in front of me...)---101 was blocking the remote subnet going to .100 from being NATted, but that was it---all other traffic was NATted and therefore going out to the internet.

Burt
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top