How do I permit specific ports on l2l vpn?

Unanswered Question
Apr 9th, 2010

I'm trying to build a LAN-2-LAN ipsec vpn.  I know I need an acl to specify interesting traffic, but every acl example I can find just uses the blanket "permit ip".  I'm wanting to build a vpn based on specific tcp/udp ports.  If I build the acl using specific tcp/udp ports, do I have to include any protocols or ports for the vpn tunnel itself?  Does someone have an example of a vpn acl that specifies ports?  Thanks!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Generally speaking I personally use source/destionation IP subnets.  However if you want to lock it down evern further it's an option - but can be tricky when trying to troubleshoot.

An alternative would be to use source/destination IP subnets - if you feel the need to "filter" once the VPN is fully established, then an acl on the inside interface is a soltution.

But to assist you, if I wanted to say connect to a remote site using ping/RDP/Telnet/DNS then my VPN acl would be:-

crypto map L2L-VPN  1 match address my-restrcited-vpn

access-list my-restrcited-vpn extended permit icmp 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0 any
access-list my-restrcited-vpn extended permit tcp 10.0.0.0 255.0.0.0  10.0.0.0 255.0.0.0 eq 23
access-list my-restrcited-vpn extended permit tcp 10.0.0.0 255.0.0.0  10.0.0.0 255.0.0.0 eq 3389

access-list my-restrcited-vpn extended permit udp 10.0.0.0 255.0.0.0  10.0.0.0 255.0.0.0 eq 53

HTH>

Andrew.

bubaconk85 Fri, 08/13/2010 - 09:19

Hi Did you ever get this to work?  I have tried both Interesting traffic ACLs and ACLs on the inside interface with no luck.  I need to block access to all but specific ports for PCI compliance.  Any suggestions?

bubaconk85 Fri, 08/13/2010 - 11:31

Thank you I have been trying to figure this out for a year.  Worked like a charm!  The one thing that drove me crazy after applying the policy was I had to clear the sa out of the FW.  After making changes to the access clear the SA with CLEAR CRYPTO IPSEC SA PEER xxx.xxx.xxx.xxx.

Thanks

Collin Clark Fri, 08/13/2010 - 11:33

Glad to hear it's working and thanks for posting the tip on clearing the SA.

jkeeffe Fri, 08/13/2010 - 13:00

I tried this back in pre-8.2x days and didn't like the way the ACE logic was defined - where the remote host had to be the first entry in the ACE.

For instance, if I wanted only telnet traffic from local host A to remote host B to bring the tunnel up, the ACE had to be written with remote Host B in the first entry. However, if for another lan-2-lan VPN config I wanted FTP from remote host B to local host A to be the interesting traffic that brought the tunnel up, still remote host B was the first entry in the ACE.  Bothe ACE's had remote host B in the first entry, but in only the second ACE did remote host B initiate the traffic. With this wierd way Cisco wrote the code, one can never tell by the ACE entry which way the intended traffic was going.

So I held off rolling out a couple of ASA-5540s to replace our aging 3030 concentrators. I was told by Cisco a couple of years ago that the entire VPN code in the ASA OS was being re-written, and one of the changes was going to be to the ACE logic, where the source IP would be the first entry in the ACE, not the remote IP. This would match up to all other ACL logic that Cisco uses.

Do you know if this has been done in either 8.2.3, or now the newest 8.3.2?  Or is it still required to put the remote host IP in the first entry of an ACE?  Again, this is for the vpn-filter logic only that I am concerned with.

Thanks in advance for answering.

Actions

This Discussion