2

I'm trying to find a way to setup a bi-directional L2L IPSec tunnel, but with differing group-policy filter ACLs for both sides.

I have the following filter ACL setup, applied, and working on my tunnel-group:

access-list ACME_FILTER extended permit tcp host 10.0.0.254 host 192.168.0.20 eq 22
access-list ACME_FILTER extended permit icmp host 10.0.0.254 host 192.168.0.20

According to the docs, VPN filters are bi-directional, you always specify the remote host first (10.0.0.254), followed by the local host and (optionally) port number, as per the documentation.

However, I do not want the remote host to be able to access my local host's TCP port 22 (SSH) because there's no requirement to do so -- there's only a requirement for my host to access the remote host's SFTP server, not vice-versa. But since these filter ACLs are bidirectional, line 1 is also permitting the remote host to access my host's SSH Server.

The documentation I'm reading doesn't seem to clear to me if this is possible; help/clarification much appreciated.

gravyface
  • 13,957
  • 19
  • 68
  • 100

2 Answers2

1

Note that if a user at the remote end has privileged access they initiate a connection with a specific source port - including port 22. By doing that they can use this ACL to connect FROM port 22 on 10.0.0.254 to any port on 192.168.0.20.

This is almost certainly not your intention, but is an example of the type of security risk you are exposing yourself to with simple ACLs like these.

Tim Nicholas
  • 11
  • 1
  • That is why gravyface asked the question - can you suggest a better ACL that doesn't have that risk? – dunxd Sep 19 '12 at 14:21
  • True I guess, but gravyface only said "But since these filter ACLs are bidirectional, line 1 is also permitting the remote host to access my host's SSH Server." which doesn't note that it also provides access to his/her host's web server, mail server etc. Opening one port in one direction opens up all ports in the other direction (so long as they have the ability to select a source port). – Tim Nicholas Sep 21 '12 at 05:18
0

From my reading of the referenced document the ACL you currently have in place should be allowing the remote host to access your local host on port 22 but not your local host to access the remote host on port 22. According to the document the ACLs are stateful, so when a packet arrives from the remote host destined for tcp port 22 it matches the ACL and is permitted. Because it is stateful the return traffic is also permitted. When the local host tries to establish a connection to tcp port 22 on the remote host the source is a random high port on the local host which means it doesn't match the acl requirement of a packet to or from the localhost on port 22 so it should be dropped by the ACL. An ACL entry is only truly bi-directional if no tcp or udp port is specified. The ACL below should implement what you want to achieve:

access-list ACME_FILTER extended permit tcp host 10.0.0.254 eq 22 host 192.168.0.20
access-list ACME_FILTER extended permit icmp host 10.0.0.254 host 192.168.0.20

TimS
  • 2,166
  • 13
  • 8
  • I'm pretty sure I tried it this way and IIRC, the manual states that the order of encrypt acls is not important. – gravyface May 06 '11 at 11:54
  • I assume by order of the acls you mean order of the entrys in the ACE. The manual actually states that the remote side must be the first entry in the ACE no matter the direction. Since you are trying to access the remote host on port 22 the "host 10.0.0.254 eq 22" must be the first entry in the ACE. – TimS May 06 '11 at 16:53