cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1123
Views
0
Helpful
2
Replies

Really tight VPN ACL on ISR Routers

bobbycornetto
Level 1
Level 1

Hi Everyone,

I have an odd situation where I need to config site to site VPN with a very "tight" VPN ACL that allows access to a specific port and host at each end. I need to tunnel TCP traffic from site A encryption domain address 1.1.1.1 to site B address 2.2.2.2 port 2222. I also need to permit the site B host 2.2.2.2 to tunnel TCP to 1.1.1.1 on port 1111. I didn't think setting the tight ACL would be a big deal and I've done lots of site to site VPNs before. But I've always used very general crypto ACLs permitting IP to blocks of addresses. I can get half of the communication going, but not the other half. I believe my crypto ACLs should look like this:

Site A

access-list 101 permit tcp host 1.1.1.1 host 2.2.2.2 eq 2222

access-list 101 permit tcp host 1.1.1.1 eq 1111 host 2.2.2.2

Site B

access-list 101 permit tcp host 2.2.2.2 host 1.1.1.1 eq 1111

access-list 101 permit tcp host 2.2.2.2 eq 2222 host 1.1.1.1

Thanks for your help.

2 Replies 2

raga.fusionet
Level 4
Level 4

Bobby,

The crypto ACLs should be defined using a IP as protocol. It will create conflicts if you try to use TCP or UDP.

Now if you need to tight what comes in thru your tunnel, the best way to do this is using ACLs on the internal Interface.

For example on site A, asumming that the F0/1 is your private interface you could something like this to limit the traffic

access-list 150 permit permit tcp host 1.1.1.1 host 2.2.2.2 eq 2222

access-list 150 permit deny ip host 1.1.1.1 host 2.2.2.2

access-list 150 permit permit ip any any

access-list 160 permit permit tcp host 2.2.2.2 host 1.1.1.1 eq 1111

access-list 160 permit deny ip host 2.2.2.2 host 1.1.1.1

access-list 160 permit permit ip any any

int F 0/1

ip access-group 150 in

ip access-group 160 out

Your crypto acl should be

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2 eq.

In other words, the tunnel must be negotiated using IP as protocol, and then you can limit whatever enters/leaves the tunnel by applying an ACL to the private interface, which is the one the that sees the traffic unencrypted.

HTH.

Raga

Thanks Raga. It turns out my ACL using TCP/UDP worked fine. I don't have full control over the remote end of this connection and it was just an config problem at the other end.The problem I was having was due to "fat fingering" an ACL. Sorry.