Options

ACL trouble

GT-RobGT-Rob Member Posts: 1,090
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

Comments

  • Options
    nice343nice343 Member Posts: 391
    I would use in instead of out on that interface
    My daily blog about IT and tech stuff
    http://techintuition.com/
  • Options
    GT-RobGT-Rob Member Posts: 1,090
    I was thinking that, but don't I need that for NAT?
  • Options
    nice343nice343 Member Posts: 391
    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
    My daily blog about IT and tech stuff
    http://techintuition.com/
  • Options
    NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    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
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
  • Options
    rebelratrebelrat Member Posts: 34 ■■□□□□□□□□
    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.
    rebelrat :-)
  • Options
    bighornsheepbighornsheep Member Posts: 1,506
    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.
    Jack of all trades, master of none
  • Options
    NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    I only see one access list applied to the wan interface which is 101.
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
  • Options
    GT-RobGT-Rob Member Posts: 1,090
    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).
  • Options
    rebelratrebelrat Member Posts: 34 ■■□□□□□□□□
    Your nat inside source list is applied to the same interface e0/1 permitting all traffic. Could this cause an overlap?
    rebelrat :-)
  • Options
    GT-RobGT-Rob Member Posts: 1,090
    ^ I dont think so because if I block tcp any any and apply it to an interface, it cuts off my telnet, web etc.
  • Options
    NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    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..
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
  • Options
    bighornsheepbighornsheep Member Posts: 1,506
    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.
    Jack of all trades, master of none
  • Options
    rebelratrebelrat Member Posts: 34 ■■□□□□□□□□
    Try applying access list 101 as an outgoing access list on e0/0 with the established keyword.
    rebelrat :-)
  • Options
    bighornsheepbighornsheep Member Posts: 1,506
    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.
    Jack of all trades, master of none
  • Options
    GT-RobGT-Rob Member Posts: 1,090
    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
  • Options
    NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    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.
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
  • Options
    rebelratrebelrat Member Posts: 34 ■■□□□□□□□□
    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.
    rebelrat :-)
  • Options
    dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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.
    The only easy day was yesterday!
  • Options
    NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    Ya thats why I always sniff it just to be sure what the ports are doing before I beat my head over an ACL.
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
  • Options
    GT-RobGT-Rob Member Posts: 1,090
    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.
  • Options
    dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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"
    The only easy day was yesterday!
  • Options
    GT-RobGT-Rob Member Posts: 1,090
    ^ 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
  • Options
    GT-RobGT-Rob Member Posts: 1,090
    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!
  • Options
    NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    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.
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
Sign In or Register to comment.