Announcement

Collapse
No announcement yet.

VPN traffic selection not working after access-list change.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • VPN traffic selection not working after access-list change.

    VPN traffic selection not working after access-list change.

    Local device: Cisco ASA 5505
    Remote Device: Cisco ASA 5520

    Local subnets: 10.100.1.0/24 (inside)
    10.100.2.0/24 (DMZ, currently not used)
    10.100.3.0/24 (VPN users, currently not used but will be used in future)

    Remote subnets: 10.10.208.0/22 (inside)
    10.10.200.0/22 (DMZ)

    Local external address: 203.XXX.YYY.ZZZ (Static IP on a DSL connection, usng PPPoE)
    Next hop on our external connection: 203.55.231.88

    Remote external address: 204.AAA.BBB.CCC


    We want this tunnel to route all traffic between the local subnets and the remote subnets. Initial config was with the ADSM VPN

    wizard, with subsequent editing done by hand. In the local config we have:


    crypto map outside_map0 1 match address outside_cryptomap_1
    crypto map outside_map0 1 set peer clientname_endpoint
    crypto map outside_map0 1 set transform-set clientname_trans
    crypto map outside_map0 65535 ipsec-isakmp dynamic outside_dyn_map0
    crypto map outside_map0 interface outside

    tunnel-group 204.AAA.BBB.CCC type ipsec-l2l
    tunnel-group 204.AAA.BBB.CCC ipsec-attributes
    pre-shared-key redacted




    Previously the outside_cryptomap_1 rule was
    access-list outside_cryptomap_1 extended permit ip 10.100.1.0 255.255.255.0 10.10.208.0 255.255.252.0
    Which behaved as expected.

    This was changed to
    access-list outside_cryptomap_1 extended permit ip 10.100.0.0 255.255.0.0 10.10.0.0 255.255.0.0
    and the corresponding change made at the remote end. Our local device was then restarted; the remote device was not restarted as other services depend on their ASA.


    The problem we have is after changing the outside_cryptomap_1 rule to the broader 10.100.*.* <-> 10.10.*.* at both ends the VPN tunnel

    only picks up packets going to the remote 10.10.208.0 network, not to the remote 10.10.200.0 network.


    [[email protected] ~]# ping -c 4 10.10.208.1
    PING 10.10.208.1 (10.10.208.1) 56(84) bytes of data.
    64 bytes from 10.10.208.1: icmp_seq=0 ttl=128 time=299 ms
    64 bytes from 10.10.208.1: icmp_seq=1 ttl=128 time=288 ms
    64 bytes from 10.10.208.1: icmp_seq=2 ttl=128 time=313 ms
    64 bytes from 10.10.208.1: icmp_seq=3 ttl=128 time=286 ms

    --- 10.10.208.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 286.187/296.976/313.899/10.912 ms, pipe 2

    [[email protected] ~]# ping -c 4 10.10.200.138
    PING 10.10.200.138 (10.10.200.13 56(84) bytes of data.
    From 203.55.231.88 icmp_seq=0 Packet filtered
    From 203.55.231.88 icmp_seq=1 Packet filtered
    From 203.55.231.88 icmp_seq=2 Packet filtered
    From 203.55.231.88 icmp_seq=3 Packet filtered

    --- 10.10.200.138 ping statistics ---
    4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3003ms
    , pipe 2


    Looking at the logs the ASA shows the same information; pings to 10.10.200.138 are being sent over the external connection, and the

    peer router is rejecting them (the ISP has presumably configured their network to stop people sending out packets to private IP

    ranges)
    Pings to 10.10.208.1 are sent through the VPN tunnel, and work correctly.

    The same behavior is seen using traffic other than pings (such as http)


    The tunnel itself comes up fine, and traffic to 10.10.208.0/22 continues to work so the only problem seems to be the traffic selection rule not picking up traffic destined for 10.10.200.0/22 (which would be a sub-set of traffic destined for 10.10.0.0/16). Is there something else that needs to be done after editing the access-list outside_cryptomap_1 to control what traffic goes through the VPN tunnel? Is there an issue when the subnet used in the tunnel inculdes multiple subnets at the remote site?

  • #2
    Re: VPN traffic selection not working after access-list change.

    Do you have a different acl for the no nat?
    cheers
    Andy

    Please read this before you post:


    Quis custodiet ipsos custodes?

    Comment


    • #3
      Re: VPN traffic selection not working after access-list change.

      Originally posted by AndyJG247 View Post
      Do you have a different acl for the no nat?
      Thank you very much, that was the problem.

      access-list outside_nat0_outbound extended permit ip object-group internal_networks object-group internal_networks

      The internal_networks object-group was missing the remote DMZ; once added the traffic goes over the tunnel.

      The lesson here is that NAT trumps VPN when choosing where to send traffic.

      Comment


      • #4
        Re: VPN traffic selection not working after access-list change.

        Glad you got it sorted, thanks for posting back.
        cheers
        Andy

        Please read this before you post:


        Quis custodiet ipsos custodes?

        Comment

        Working...
        X