Cannot drop traffic from Site-to-Site VPN using ACL

[pingduck]

I am running Classic IOS 15.7(3)M with Site-to-Site VPN

interface Tunnel1
 ip address negotiated
 tunnel source GigabitEthernet0
 tunnel mode ipsec ipv4
 tunnel destination <my peer IP>
 tunnel path-mtu-discovery
 tunnel protection ipsec profile default
end
!
crypto ikev2 authorization policy default
 route set interface
 route set access-list MYIPS
crypto ikev2 profile Flex_IKEv2
 match identity remote key-id <remote-peer-id>
 identity local email <my-identity>
 authentication remote pre-share
 authentication local pre-share
 keyring local Flex_key
 aaa authorization group psk list default default

There are certain device on my network that I want to block access. So I created an ACL

ip access-list extended anySSH
 deny   tcp any any eq 22
  permit ip any any

interface GigabitEthernet5
 ip address 192.168.3.1 255.255.255.0
 ip access-group anySSH out
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
 ipv6 enable
end

The ACL works if I try to access from other connected ports. However, it does not work on traffic from Site-to-Site VPN. In fact, I tried applying the ACL to Tunnel1 and it still allows access. Tried both inbound and outbound. Tried even an ACL with just "deny ip any any". No difference. Am I doing something wrong?

[Sheraz.Salim]

what does it show you

show crypto session

[pingduck]

#show crypto session
Crypto session current status

Interface: Tunnel1
Profile: Flex_IKEv2
Session status: UP-ACTIVE     
Peer: <my-peer-ip> port 4500 
  Session ID: 1 
  IKEv2 SA: local <my-wan-ip>/4500 remote <my-peer-ip>/4500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map

[Sheraz.Salim]

also show crypto ipsec sa detail

[pingduck]

show crypto ipsec sa detail

interface: Tunnel1

    Crypto map tag: Tunnel1-head-0, local addr <my-wan-ip>

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

   current_peer <my-peer-ip> port 4500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 2076, #pkts encrypt: 2076, #pkts digest: 2076

    #pkts decaps: 1451, #pkts decrypt: 1451, #pkts verify: 1451

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0

    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0

    #pkts invalid prot (recv) 0, #pkts verify failed: 0

    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0

    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0

    ##pkts replay failed (rcv): 0

    #pkts tagged (send): 0, #pkts untagged (rcv): 0

    #pkts not tagged (send): 0, #pkts not untagged (rcv): 0

    #pkts internal err (send): 0, #pkts internal err (recv) 0

     local crypto endpt.: <my-wan-ip>, remote crypto endpt.: <my-peer-ip>

     plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb Cellular0

     current outbound spi: 0x5B27E9B7(1529342391)

     PFS (Y/N): N, DH group: none

     inbound esp sas:

      spi: 0x88BAF7BA(2293954490)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel UDP-Encaps, }

        conn id: 2002, flow_id: Onboard VPN:2, sibling_flags 80000040, crypto map: Tunnel1-head-0

        sa timing: remaining key lifetime (k/sec): (4256842/1402)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

      spi: 0x5B27E9B7(1529342391)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel UDP-Encaps, }

        conn id: 2001, flow_id: Onboard VPN:1, sibling_flags 80000040, crypto map: Tunnel1-head-0

        sa timing: remaining key lifetime (k/sec): (4256584/1402)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

[Sheraz.Salim]

crypto ikev2 authorization policy default
 subnet-acl anySSH
 route set interface
 route set access-list MYIPS

[Rob Ingram]

The subnet-acl command is obsolete. The equilvent is now "route set access-list 110" which is used to push static routes to a flexvpn client, not control access through the device.

[Rob Ingram]

Hi,
You would apply the ACL outbound on the tunnel interface, this would filter transit traffic but not traffic originating from the router itself.

HTH

[pingduck]

As I mentioned earlier, I tried applying ACL both in-bound and out-bound on the Tunnel. Even an ACL to deny ip any any. It does not work. It is as if VPN traffic is immune to ACLs.

[Rob Ingram]

And how have you been testing? From traffic sourced on the router or with transit traffic?
I've tested and confirmed this works as I expect.

[pingduck]

I tested from both VPN peer another local network device. The latter works as expected. Traffic gets blocked but no blocking happening with traffic sourced from VPN peer.

[Rob Ingram]

As I said in my initial response "this would filter transit traffic but not traffic originating from the router itself". 

This reference states:- "An access list can control traffic arriving at a device or leaving a device, but not traffic originating at a device."

I would imagine a ZBFW when using the self zone could possibly filter the outbound traffic if so desired.

[pingduck]

"the device" stated refers to the router with the ACL configured.

I tested from VPN peer, so it should be considered transit traffic. I know output ACL does not work on traffic originated from router, e.g. ping. But this is not what I am trying here. If VPN traffic terminated by a router is considered router generated traffic then essentially ACL cannot block anything coming from VPN. With VPN so widely used, this can't possibly be true?

[Rob Ingram]

I am not saying all VPN traffic terminated by a router is considered router generated traffic. I am saying if you generate traffic from the router itself, as in control/mgmt plane traffic - ping, ssh, telnet, dynamic routing protocol etc this would not be filtered by an ACL on that router's interface. If a PC connected to the LAN sends traffic over the VPN tunnel this is transit traffic, which is filtered by the outbound ACL.

You can filter inbound on the other VPN peer, which would filter the transit traffic and traffic originated by the other router.