topic Re: Applying an ACL to a route-based IPsec VPN tunnel in Network Security

Applying an ACL to a route-based IPsec VPN tunnel

ABaker94985 — Wed, 13 Sep 2023 20:51:57 GMT

We have a route-based VPN configured to a vendor, and I attempted to apply an access list to the tunnel interface. All traffic was blocked. I've not been able to find documentation on how to apply and ACL for this type of VPN, but this isn't working. Our side only needs to query the vendor's server via SQL:

access-list VENDOR_IN extended permit tcp host 10.2.3.231 10.110.0.0 255.255.0.0 eq 1433
access-list VENDOR_OUT extended permit ip 10.110.0.0 255.255.0.0 host 10.2.3.231

access-group VENDOR_IN in interface vti-interface_100
access-group VENDOR_OUT out interface vti-interface_100

Thanks

Re: Applying an ACL to a route-based IPsec VPN tunnel

balaji.bandi — Wed, 13 Sep 2023 21:02:33 GMT

what device is this ? ASA or router ?

Re: Applying an ACL to a route-based IPsec VPN tunnel

ABaker94985 — Wed, 13 Sep 2023 21:04:24 GMT

My bad. It's an ASA.

Re: Applying an ACL to a route-based IPsec VPN tunnel

Marius Gunnerud — Wed, 13 Sep 2023 21:29:19 GMT

You should only need access rules for incoming traffic on the VTI interface (as long as you are not bypassing access list for VPN connections.) Traffic in the outbound direction should be filtered on the ingress interface where that is actually entering the ASA.

That being said, if 10.2.3.231 is the remote side and you are querying the remote side using SQL, then the SQL port should be part of the source.

access-list VENDOR_IN extended permit tcp host 10.2.3.231 eq 1433 10.110.0.0 255.255.0.0

Re: Applying an ACL to a route-based IPsec VPN tunnel

ABaker94985 — Thu, 14 Sep 2023 12:40:21 GMT

Marius, I appreciate your info, but the ACL example just isn't making sense to me. Just to set things straight, 10.2.3.231 is our source, and it's reaching across the tunnel to a host in 10.100.0.0/16 on the SQL port. Installing an ACL with 1433 as the source port seems to me that you're making an ACL for a stateless firewall. I don't want anything coming back from the vendor that's initiated from his end, hence a "deny ip any any" from 10.110.0.0/16 to 10.2.3.231, which is to be applied on the VTI interface. Also, based on what I'm understanding, since the SQL query will be initiated from our end, and that ACL will be applied on the Ethernet interface, correct?

You've brought up some ideas in my head about VTI interfaces. My concept of traffic flow through these needs to be shored up. I'm just not grasping inbound and outbound flows with respect to the inside interface of the firewall.

Thanks for your time.

Re: Applying an ACL to a route-based IPsec VPN tunnel

ABaker94985 — Thu, 14 Sep 2023 13:12:08 GMT

I'm beginning to understand the concept here, so thanks for your patience. You have to think of the ACLs applied to VTI interfaces differently from a normal interface, so I'm probably OK with the ACL now. I'll have to think about this some more.

We also have "no sysopt connection permit-vpn" configured, and there is no entry in the OUTSIDE ACL for traffic from the vendor to come into our network. Does that mean no traffic can be initiated from the vendor, as is the case with policy-based VPNs? I wasn't sure if the "no sysopt" command also worked with route-based tunnels, and that was the main reason for trying to apply an ACL on the VTI interface.

Re: Applying an ACL to a route-based IPsec VPN tunnel

MHM Cisco World — Thu, 14 Sep 2023 13:15:09 GMT

Route based VPN for ASA and you want filter for traffic pass.

That work I think you need only to apply acl to tunnel interface ""nameif"" of route based VPN not to tunnel source.

And also you need no sysop permit vpn

Re: Applying an ACL to a route-based IPsec VPN tunnel

MHM Cisco World — Thu, 14 Sep 2023 16:24:19 GMT

You are so welcome

MHM