Site-to-site VPN - access to WAN subnets.

Unanswered Question
Jul 7th, 2010

I have a small remote site connected via site-to-site VPN with a PIX 501 to our main office ASA 5520.  Traffic from the remote site to the main office subnet, dmz subnet, and a small directly connected subnet passes just fine, however the remote site cannot pass traffic to any of the other sites/subnets on our WAN.

I've added one of the WAN subnets to the ACL on the PIX for the crypto map, as well as the ASA's crypto map and NAT exemptions, but still can't pass traffic to the WAN subnet.

This is the pertinent PIX config at the remote site:

access-list 101 permit ip 172.16.68.0 255.255.252.0 172.16.128.0 255.255.252.0 (main office)
access-list 101 permit ip 172.16.68.0 255.255.252.0 10.10.10.0 255.255.255.0  (dmz)
access-list 101 permit ip 172.16.68.0 255.255.252.0 172.16.132.0 255.255.252.0 (directly connected site to main office - wifi bridge)
access-list 101 permit ip 172.16.68.0 255.255.252.0 172.16.104.0 255.255.252.0 (the WAN subnet I'm trying to access)

crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac
crypto map outside_map 20 ipsec-isakmp
crypto map outside_map 20 match address 101
crypto map outside_map 20 set peer main.office.asa.ip
crypto map outside_map 20 set transform-set esp-3des-sha
crypto map outside_map interface outside
isakmp enable outside
isakmp key ******** address main.office.asa.ip netmask 255.255.255.255
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400

This is the pertinent ASA information:

crypto map outside_map 20 match address outside_1_cryptomap
crypto map outside_map 20 set peer remote.site.ip
crypto map outside_map 20 set transform-set esp-3des-sha
crypto map outside_map interface outside

access-list outside_1_cryptomap extended permit ip 172.16.128.0 255.255.252.0 172.16.68.0 255.255.252.0
access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0
access-list outside_1_cryptomap extended permit ip 172.16.132.0 255.255.252.0 172.16.68.0 255.255.252.0
access-list outside_1_cryptomap extended permit ip 172.16.104.0 255.255.252.0 172.16.68.0 255.255.252.0

nat (inside) 0 access-list inside_nat0_outbound

access-list inside_nat0_outbound extended permit ip 172.16.128.0 255.255.252.0 172.16.68.0 255.255.252.0
access-list inside_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0
access-list inside_nat0_outbound extended permit ip 172.16.132.0 255.255.252.0 172.16.68.0 255.255.252.0

access-list inside_nat0_outbound extended permit ip 172.16.104.0 255.255.252.0 172.16.68.0 255.255.252.0

As I said, traffic from 172.16.128.0, 172.16.132.0, and 10.10.10.0 can all pass to the remote site, but traffic from 172.16.104.1 cannot.

Any assistance is greatly appreciated.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
rcoote5902_2 Wed, 07/07/2010 - 11:25

Ha I found it.  One of our WAN provider's edge devices was advertising an old route for the 172.16.68.0 subnet (it used to be connected via wireless bridge as well).

Someone give me 5 points.

Actions

This Discussion

Related Content