I apologize if this is a dumb question but I'm just getting my feet wet with CISCO routers and am stuck on a a particular issue. On a lab router, 2 interfaces:
FA0 - 10.0.3.1
Ethernet0 - 10.0.1.111
My lab is sitting on 3.x network and need to route it out Eth0 interface. I just want to isolate my lab from the rest of the network allowing lab connectivity to internet while restricting trafffic to lab to only DNS, SMTP, FTP
The following is my config which is not working:
ip address 10.0.1.111 255.255.255.0
ip address 10.0.3.1 255.255.255.0
no ip address
no ip address
ip route 0.0.0.0 0.0.0.0 FastEthernet0
no ip http server
access-list 100 permit udp any 10.0.3.0 0.0.0.255 eq domain
access-list 100 permit tcp any 10.0.3.0 0.0.0.255 eq smtp
access-list 100 permit tcp any 10.0.3.0 0.0.0.255 eq ftp
access-list 100 permit tcp any any
access-list 100 permit udp any any
access-list 113 permit tcp any 10.0.1.0 0.0.0.255 eq domain
access-list 113 permit tcp any 10.0.1.0 0.0.0.255 eq ftp
access-list 113 permit tcp any 10.0.1.0 0.0.0.255 eq smtp
access-list 113 permit tcp any any
access-list 113 permit udp any any
Any help would be greatly appreciated.
Looks like you need to apply your access-lists to an interface, using either the "ip access-group xxx in" or "ip access-group yyy out" commands. The "xxx" and "yyy" are the names or numbers of your access-lists.
The direction of traffic flow they're being applied to is either coming "in"to the router on that interface, or going "out" of the router on that interface. You can have one and only one active "in" ACL, and one and only one active "out" ACL, per interface. (That's two active ACLs total per interface, one "in"bound and the other "out"bound.)
Which addresses are source addresses and which ones are destination addresses is determined by how the ACLs are applied to an interface. For example, if you apply "ip access-group 100 in" to your interface Ethernet0, then the first "any" in those commands is the source, which is literally any IP address. The "10.0.3.0 0.0.0.255" is your destination, which would be all the possible IP addresses on the LAN connected to your interface FastEthernet0.
And the "eq domain", "eq smtp", or "eq ftp" would further specify which services hosted by servers on your LAN you are permitting the Internet access to. (If these servers were on the Internet side, and your clients are on the LAN side, then these "eq" parameters belong after the first "any".)
The last two lines in each of your access-lists is permitting any and all TCP and UDP traffic. So all the ACLs are really restricting is the ability to ping devices, etc. via ICMP. (This denial is part of the implicit deny ip any any assumed to be at the end of each ACL.) They are passing everything else no matter which way they're applied, inbound or outbound.
Not sure which way/direction you're trying to restrict the traffic flow, but you may have to change the order of some of the ACL parameters on each line to get it to work the way you want it to. Also, you may have to issue some explicit "deny" instead of "permit" commands, if you're looking to block something from coming into or going out of your router.
Also, since the static default route on your router sends traffic out the FastEthernet0 interface, make sure that any devices on that LAN either use this router as their default gateway, or they use another router on that LAN that knows how to reach your Lab network on the Ethernet0. (Looks like your RIPv2 dynamic routing protocol should take care of that, if the router(s) on the FastEthernet0 side are also doing RIPv2.) Otherwise, you won't be able to access servers or the Internet on the FastEthernet side from the Lab network.
Hope this helps.
This was a big help. Thanks.
Now I've come across another problem. On our LAN is a firewall....10.0.l.42. I can get into my lab from the LAN side 10.0.1.x with a static route on the firewall.
Problem is, I cannot get at ANY clients on the 10.0.1.x network from LAB (10.0.3.x) if the LAN clients are using the firewall (10.0.1.42) as their gateway.
If I change the LAN clients gateway to that of a 2nd router on the 1.x network (router ip is 10.0.1.6) then everything works fine. This has got me really scratching my head.
If I have all of this correct, clients on the 3.x network are using my lab router as gateway 10.0.3.1. Why then can't they get to a box on the 1.x network if those boxes are using 10.0.1.42 (firewall) as gateway. Wouldn't routing from LAB 3.x to LAN 1.x depend on router and not gateway of destination host?
This is happening because PIX dosent do ICMP redirects where as router does.
In simple words, what I mean is, when the Hosts in LAN 1.x send packets to 1.42 ( PIX ) with destination belonging to 3.X network, PIX knows that the next hop is actually a router in the local LAN and dosent do anything aobut it.
Where as when the default gateway is 1.6 (Router), and hosts send a packet to it, the router knows that the next hop for 3.x is in the local lan and sends a ICMP REDIRECT packet telling the host to send the packet to 10.0.1.111 for traffic to 3.X network.
You can verify this by giving the following debug command on the 1.6 router.
'debug ip icmp',
make sure you give 'terminal monitor' command if you are using telnet, and then when you try to access anything in 3.1 you should see icmp redirects sent from this router.
So there is nothing wrong with the configuration, its jsut the way PIX works, it wont hair-pin the traffic.
Thanks Aslam - but this is what I have difficulty understanding. 1.x to 3.x is fine with a static route in place on the firewall: It's a Sonicwall BTW
destination network : 10.0.3.0
gateway 10.0.1.111 (fa0 on the router)
The problem lies on the way back. If client in 3.x attempts to initiate FTP connection with server in 1.x. Doesn't work. If client first pings server, connection is fine.
This seems to be a router problem No? the route back from 3.x to 1.x is handled by the router correct?
Is there a workaround? 1.x servers need to go out firewall (10.0.1.42) rather than router (10.0.1.6)
Thanks again for your explination
Just for more clarification, lets assume the following and see the traffic flow.
Client: 10.0.3.10/24 DG - 10.0.3.1
FTP Srvr: 10.0.1.10/24 DG - 10.0.1.42
FW - Has route 10.0.3.0 --> 10.0.1.111
So now client wants to talk to the FTP Server.
1. It notices that destination is not local, hence it needs to go to default gateway 10.0.3.1.
2. Router knows that its a directly connected interface and forwards the packet onto the 10.0.1.X network destined towards 10.0.1.42.
3. Now server needs to send a reply packet back to client. It notices that Destination is not local and send the packet to the FW.
4. Now FW needs to send this packet to the 10.0.1.111
-- And this is where I think the problem is ... the FW is not sending it back. I am not sure how Sonic works. But I assume that is the problem.
5. Assuming that Sonic does send it to the router, the router should not have any problem sending the packet back to the Client. ( As it is proved when you set the DG on 1.x to router 1.6).
When you say that 1.x to 3.x is fine, did u try pinging one of the client PCs directly from the Server PC ? Try this clear all the ARP entries on the Server, Router and Client and then try to ping from server to client.
Try the same from Client to Server ( after clearing all entries ).
Finally, do a 'DEBUG IP PACKET DETAIL' on the router and see how the packets are flowing and whether you are receiving any packet back. This should show you the flow clearly, if there is a heavy utilization of the router, make the debug more specific using Access list. Along with this you can capture packet on the FTP server ( and see if its getting the request and replying to it .. i am pretty sure its doing that). I am not sure how the debug on Sonic works but if it can show some packet details That would be great.
Try this and let me know how it goes.
And as a final workaround, I am not sure what you are using the 10.0.1.6 router for ... byt you can have all 1.x machine point to 10.0.1.6 (router), and on the router configure a default route to the Sonic. That way the router will be able to direct 3.x traffic to the lab router and all other desitnations that the router dosent know about will be directed to the sonic.
This makes sense now. I did packet captures yesterday and notice that each ftp request, firewall dropped icmp packet 10.0.1.x destined for 10.0.3.x network. I could not figure out why the icmp packet and your explination clears that up. Is there a workaround.
I cannot get the firewall in no way shape or form to allow this icmp packet through.
The easiest way to get this to work is as I said ealier, have all 1.x machine point to 10.0.1.6 (router) as default gateway and on the router configure a default route to the Sonic. That way the router will be able to direct 3.x traffic to the lab router and all other desitnations that the router dosent know about will be directed to the sonic.