Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Access-lists applied on inbound VPN connection

I am trying to setup some internal security access lists, we have a multi site VPN network, Terminal services is the primary traffic that travels on the VPN network.

ACL 102 applies to a one of the crypto maps

access-list 100 permit ip 10.1.5.0 255.255.255.0 10.1.6.0 255.255.255.0

access-list 102 permit ip 10.1.5.0 255.255.255.0 10.1.6.0 255.255.255.0

We need to allow the traffic only to domain logins and terminal services only.

I have tried this with no luck, the remote clients loose the ability to auth against the domain controller.

access-list 102 permit ip host 10.1.5.20 10.1.6.0 255.255.255.0

(domain controller also DNS and WINS)

access-list 102 permit ip host 10.1.5.21 10.1.6.0 255.255.255.0

(secondary domain controller also DNS and WINS)

access-list 102 permit ip host 10.1.5.22 10.1.6.0 255.255.255.0

(terminal server 1)

access-list 102 permit ip host 10.1.5.23 10.1.6.0 255.255.255.0

(terminal server 2)

access-list 102 permit ip host 10.1.5.24 10.1.6.0 255.255.255.0

(terminal server 3)

If I implement these access-lists after they have logged on it it works fine, but once they log off and attempt to relog on, they are blocked. This leads me to believe there is more to the domain logins then meets the eye.

Does anyone have any suggestions for me? Has anyone experienced this problem?

Thanks in advance!

Gregg

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Access-lists applied on inbound VPN connection

The domain logon might require broadcasts. This will probably be in the form of directed broadcasts i.e. 10.1.5.255. These broadcasts will pass your first list, but be blocked by the second access-list. To come around this, you could use ip helper adresses on the 10.1.6.0 net. You could also add the following line to list 102:

access-list 102 permit ip host 10.1.5.255 10.1.6.0 255.255.255.0.

Another thing to consider is simplifying your ACL 102. Smaller access-lists give better performance. In the given situation, the seperate lines for IP adresses 10.1.5.20 up to 10.1.5.23 can be replaced by a oneliner: access-list 102 permit ip 10.1.5.20 255.255.255.252. Taking this one step further you could even create a oneline access-list for all hosts when you move the third terminal server to the 16-19 range.

3 REPLIES

Re: Access-lists applied on inbound VPN connection

The domain logon might require broadcasts. This will probably be in the form of directed broadcasts i.e. 10.1.5.255. These broadcasts will pass your first list, but be blocked by the second access-list. To come around this, you could use ip helper adresses on the 10.1.6.0 net. You could also add the following line to list 102:

access-list 102 permit ip host 10.1.5.255 10.1.6.0 255.255.255.0.

Another thing to consider is simplifying your ACL 102. Smaller access-lists give better performance. In the given situation, the seperate lines for IP adresses 10.1.5.20 up to 10.1.5.23 can be replaced by a oneliner: access-list 102 permit ip 10.1.5.20 255.255.255.252. Taking this one step further you could even create a oneline access-list for all hosts when you move the third terminal server to the 16-19 range.

New Member

Re: Access-lists applied on inbound VPN connection

Thank you for the response!

I will give that broadcast address a try

Gregg

New Member

Re: Access-lists applied on inbound VPN connection

unfortunately adding the broadcast address did not work.

just for testing I added every server into a access-list

no access-list 210 permit ip host 10.1.5.19 10.1.6.0 255.255.255.0

(MS load balancing IP)

no access-list 210 permit ip host 10.1.5.20 10.1.6.0 255.255.255.0

(domain controller also DNS and WINS)

no access-list 210 permit ip host 10.1.5.21 10.1.6.0 255.255.255.0

(secondary domain controller also DNS and WINS)

no access-list 210 permit ip host 10.1.5.22 10.1.6.0 255.255.255.0

Terminal Server 1

no access-list 210 permit ip host 10.1.5.23 10.1.6.0 255.255.255.0

Terminal Server 2

no access-list 210 permit ip host 10.1.5.24 10.1.6.0 255.255.255.0

Terminal Server 3

no access-list 210 permit ip host 10.1.5.255 10.1.6.0 255.255.255.0

With this I could not authenticate against the domain controller, after further investigation with a sniffer (and using show crypto ipsec sa) I found that for every line in the access-list that creates a individual vpn tunnel.

This was the problem as our MS load balancing IP was forwarding traffic to a terminal server and the traffic cannot traverse across these individual tunnels.

If I were to do a show crypto ipsec sa, you can see each individual outbound spi for each ip address defined in a access-list.

So Using your idea of adding a network block (I should have thought of this), I created an access-list that covers all of the servers that access are needed to, but does not cover the DHCP range of our network (ie each persons PC) This method creates one tunnel and works like a charm!

access-list 210 permit ip 10.1.5.0 255.255.255.224 10.1.6.0 255.255.255.0

Covers ip addresses 1-30 but denies access to the dhcp range for our workstations.

Thanks for the tip!

Gregg

120
Views
0
Helpful
3
Replies