I have just changed our network over to a VLAN environment so that I can route traffic from our boarding houses and protect the rest of our network from the student's personal computers using ACLs. I am, of course, having trouble. My ACL is below, with access for various protocols to various servers (10.1.1.13 for example is the domain controller/DNS/DHCP and 10.1.1.2 is our gateway; 10.1.1.45 is where the students keep their files). The problem is it doesn't work (except for DHCP). If I add:
permit tcp any any established
on the end, then it does work, but boarders can get to locations that they should not be able to. Can someone point out what I am doing wrong?
There are at least 2 pieces of information that would be crucial to understanding this and to giving you a good answer which we do not have yet. First would be a description of the environment and the topology. It would appear that you have a VLAN/subnet at 10.1.1.x but it is not clear what kind of hosts are on it - and what hosts are on other VLAN/subnets. (where are the students and where is administration?) It would also be crucial to know whether this access list was applied inbound or outbound.
I sense some disconnect in the structure of the access list which puzzles me. The first section of the access list is permitting traffic from any source (generally understood as outside addresses) to specific hosts on specific ports. This would generally be applied outbound on the interface to which these hosts were connected. But the last part of the access list is permitting tcp established to these same hosts. The tcp established is permitting responses to sessions established by these hosts and is generally done in access lists that are inbound on outward facing interfaces. This combination confuses me and I hope that you can clarify this for us.
Embarrassing. The last part of the ACL is just me thrashing around trying to find something that would work.
Topology. The boarders are inside our network but need some access to the internet through our proxy server (10.1.1.2), and also access to some of the school network resources, such as their files (10.1.1.45 and 10.1.1.9), email (10.1.1.5), intranet server (10.1.1.28). They also need to be able to authenticate on the domain to reach these resources, though none of their personal computers is a domain member (hence to the domain controller/dns at 10.1.1.13).
All the servers are on one VLAN (10.1.0.0 255.255.0.0), the boarders are on a separate VLAN (192.168.1.0 255.255.255.0). Routing is done using a Catalyst 3550. There is a VLAN for the switches (10.2.0.0) and three VLANs for our three campuses. I have put the ACL on the OUT side of the boarder VLAN (intending that it should block them from getting out of their VLAN to most places in the school).
So, we want to allow all boarder machines to access limited hosts on limited ports in the school network, plus the internet via the proxy server.
It is the only ACL on the switch at the moment.
The VLANs are declared below (the 10.1.1.20 helper address is to allow Remote Installation Services to get an IP address during PXE boot):
Vladimir makes an important observation about an aspect of access lists that many people find a bit confusing. Assignment of the access-group as in or out is from the perspective of the router/switch interface. So if the access list is written with any as the source address and with 10.1.1.x as the destination then this would be the Boarders sending to the servers and it would be input on the Boarder interface.
Having said that, I believe that we also need to talk about the structure of the access list. The list that you posted has permits for access to certain servers on certain ports (which at present I will assume is the right servers and the right ports) and then a bunch of permit tcp established. I suggest that you remove the lines with tcp established.
Then we need to consider what the access list should be doing as compared to what it is doing. I believe that your access list needs to do these things:
- it should permit access to particular servers in the 10.1.0.0/16 subnet (which it does).
- it should deny access to any other devices in the 10.1.0.0/16 subnet.
- if the Boarders should have access to any other resources inside your network (10.2, 10.3, 10.4, or 40.5) then you need similar logic for these. If not then you need an deny for 10.0.0.0/8.
- it should permit ip any any to grant access to everything else (to get to the Internet.
Revise the access list. If there are still problems with it then post the revised access list.
Thanks everyone for your suggestions. I think my fatal error was attaching the ACL to the out side of the vlan interface rather than the inside. I moved it, removed all the "tcp established" references and made some other tweaks. It seems to be working now (although there is still a slight delay of about 20 seconds before the windows authentication form pops up when students try to log onto a 10.1.0.0 subnet server - and I had to open port 80 to those servers otherwise authentication would take a few minutes to appear; I don't understand why port 80 should be necessary):
ip address 192.168.3.1 255.255.255.0
ip access-group BOARDERS in
ip helper-address 10.1.1.13
ip access-list extended BOARDERS
permit tcp any host 10.1.1.2 eq 8080
permit tcp any host 10.1.1.3 eq www
permit tcp any host 10.1.1.9 eq 445
permit tcp any host 10.1.1.45 eq 445
permit tcp any host 10.1.1.28 eq www
permit udp any any eq bootpc
permit udp any any eq bootps
permit udp any any eq domain
permit tcp any any eq domain
permit icmp any host 10.1.1.13 echo
permit tcp any host 10.1.1.45 eq www
permit tcp any host 10.1.1.9 eq www
permit tcp any host 10.1.1.5 eq www
permit tcp any host 10.1.1.5 eq 443
Rick, I haven't experimented yet with your suggestion to deny access to 10.0.0.0/8 and permit ip any any, but will do so.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...