ACL trouble

So I am having trouble blocking a certain MMORPG at work here....

According to the website of the game, it uses TCP port 3724 (WoW). What am I doing wrong here? I have tried applying the ACL to both the in and out interface without any luck. Eth0/1 is WAN by the way.

interface Ethernet0/0
ip address 192.168.0.1 255.255.255.0
ip nat inside
full-duplex
!
interface Ethernet0/1
ip address dhcp
ip access-group 101 out
ip nat outside
full-duplex
!
ip default-gateway 192.168.0.1
ip nat inside source list 1 interface Ethernet0/1 overload
ip http server
ip classless
!
!
access-list 1 permit any
access-list 101 deny tcp any any eq 3724
access-list 101 permit ip any any

end

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

nice343

I would use in instead of out on that interface

GT-Rob

I was thinking that, but don't I need that for NAT?

nice343

GT-Rob wrote:

I was thinking that, but don't I need that for NAT?

yes you do. I forgot to read you whole config If e0/1 is not filtering the traffic then apply it to e0/0 and see what happens. Or the port number might be wrong

Netstudent

Is that the port the game server listens on or is that the source port for the game? My only thought would be that maybe the website's port list is bogus or the game server is listening on something different. Do you have wireshark? Can you load the game with it running to verify the port numbers? Or maybe Netstat -a

rebelrat

Looks like access list 1 (standard IP) overrules access list 101 (extended IP). Only one access list per protocol per interface per direction. So only access list 1 is applied.

bighornsheep

Try changing the direction to in on e0/1 (WAN) and put established at the end, like the following:

access-list 101 deny tcp any any eq 3724 established

That will block all the return traffic from the game coming in from WAN.

Netstudent

I only see one access list applied to the wan interface which is 101.

GT-Rob

K well I have changed ACL 1 to

access-list 1 permit 192.168.0.0 0.0.0.255

as that is my range of IPs anyway.

I got the port number off of pretty much every site I google regarding the game and ports.

off of blizzard..."World of Warcraft & Burning Crusade use TCP port number 3724 to play"

My next step was to start looking at packets on the wire but we have a fair bit of traffic going on (about 50 workstations downloading images, updates, etc constantly).

rebelrat

Your nat inside source list is applied to the same interface e0/1 permitting all traffic. Could this cause an overlap?

GT-Rob

^ I dont think so because if I block tcp any any and apply it to an interface, it cuts off my telnet, web etc.

Netstudent

I believe the nat statement only calls on access-list 1 for translations, not for permitting or denying packets and/or port numbers through the interface..

bighornsheep

have you tried putting the established keyword at the end like I suggested? (and change the direction to in)

I believe if you applying the ACL in the 'out' direction, the port # would have changed already from your NAT overloading.

rebelrat

Try applying access list 101 as an outgoing access list on e0/0 with the established keyword.

bighornsheep

rebelrat wrote:

Try applying access list 101 as an outgoing access list on e0/0 with the established keyword.

I dont think that will work unless the game is hosted in the local network, if the game is joining to blizarrd, it is the return (established) traffic coming in, if you filter on the inside local interface again you will run into the problem that the port is translated.

GT-Rob

This is how we are looking now. Still no go.

The only thing I can think of now is that they are using a different port.

!
interface Ethernet0/0
ip address 192.168.0.1 255.255.255.0
ip nat inside
full-duplex
!
interface Ethernet0/1
ip address dhcp
ip access-group 102 in
ip nat outside
full-duplex
!
ip default-gateway 192.168.0.1
ip nat inside source list 2 interface Ethernet0/1 overload
ip http server
ip classless
!
!
access-list 1 permit any
access-list 2 permit 192.168.0.0 0.0.0.255
access-list 101 deny tcp any any eq 3724
access-list 101 permit ip any any
access-list 102 deny tcp any any eq 3724 established
access-list 102 permit ip any any

Netstudent

Since the packet is now coming in, the source port will be 3724, not destination. try putting that port number on the source parameter. That is if the game server is listening on 3724.

rebelrat

bighornsheep wrote:

rebelrat wrote:

Try applying access list 101 as an outgoing access list on e0/0 with the established keyword.

I dont think that will work unless the game is hosted in the local network, if the game is joining to blizarrd, it is the return (established) traffic coming in, if you filter on the inside local interface again you will run into the problem that the port is translated.

You are absolutely correct. Forgot the PAT mechanism.

dtlokee

There would be nothing wrong with the config the OP has posted, except WoW uses TCP 3724 on the CLIENT side, not the server side.

change you ACL to:

deny tcp any 3724 any

Also it uses TCP 6112 for the downloader, and UDP 3724 for the built in voice communications.

EDIT: Netstudent beat me to it.

Netstudent

Ya thats why I always sniff it just to be sure what the ports are doing before I beat my head over an ACL.

GT-Rob

haha k well here it is now. This is my first time using ACLs in a production environment so please forgive me (its not even my job).

interface Ethernet0/1
ip address dhcp
ip access-group 101 in
ip access-group 101 out
ip nat outside

access-list 101 deny tcp any eq 3724 any
access-list 101 permit ip any any

I'm not worried with the downloader/voice chat, as if they can't log on then I doubt they would be using it.

dtlokee

Netstudent wrote:

Ya thats why I always sniff it just to be sure what the ports are doing before I beat my head over an ACL.

I just google'd the problem, but wireshark works too (I don't play WoW so I have noting to go sniff).

I would suggest that you verify the port numbers in use before assuming the ones you have are corresct (maybe look for another source of information) before assuming there is a problem with the logic and randomly guessing at a solution of "move it to another interface" or "adding established to the end"

GT-Rob

^ well luckily we are non-profit and the network isn't very 'mission critical' that I can get away with playing around with it.

So far it looks like I MAY have denied them from logging in to the game servers, time will tell for sure

GT-Rob

well still not luck lol. I think I am going to give up and let my boss grow some balls and just tell them to stop playing.

Thanks for all the help in this thread though, it is nice knowing I have a place to go to when I am stuck!

Netstudent

YOu know you could always do a nslookup on the site they are going to and deny the packets via IP of the web address instead of worrying about port numbers and PAT. Just deny all users from getting through the inside ethernet interface with an "any" as the source and the WEBsite or gameserver's IP as the destination. Put the ACL as in so the routing process is never even used. Just like you would do in a firewall. Thats what I would have done. Don;t give up just because you can't get it right.