You don't have a rule accepting HTTP (port 80). The log it uses is the internal MikroTik log that you can view via "/log print". The IP addresses in the rules are just stating to accept all traffic from those two networks. So basically you would want to think about where management requests coming _into_ your bandwidth manager are coming _from_. For instance, if your bandwidth manager is 192.168.0.1 and your workstation is 192.168.100.1, you will want to put an "action=accept" rule in for 192.168.100.0/24. That way your workstation can always get to the bandwidth manager, no matter what port/protocol you use (provided that it's an enabled service in the bandwidth manager. Obviously you can't connect to telnet if it's not enabled).
-- Adam Kennedy Network Engineer Omnicity, Inc. From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Forbes Mercy Sent: Sunday, September 05, 2010 2:52 PM To: WISPA General List; Butch Evans Subject: [WISPA] My fun (kidding) weekend on call Thanks for the comments Butch, this has been a busy on-call weekend with the bandwidth manager dropping twice (It actually shut the power off on the server) and several Mikrotik towers refusing to come back up until rebooted. To try to battle this I went to the WIKI for Mikrotik and entered this string: / ip firewall filter add chain=input connection-state=established comment="Accept established connections" add chain=input connection-state=related comment="Accept related connections" add chain=input connection-state=invalid action=drop comment="Drop invalid connections" add chain=input protocol=udp action=accept comment="UDP" disabled=no add chain=input protocol=icmp limit=50/5s,2 comment="Allow limited pings" add chain=input protocol=icmp action=drop comment="Drop excess pings" add chain=input protocol=tcp dst-port=22 comment="SSH for secure shell" add chain=input protocol=tcp dst-port=8291 comment="winbox" # End of Edit # add chain=input action=log log-prefix="DROP INPUT" comment="Log everything else" add chain=input action=drop comment="Drop everything else" Immediately after implementing this WhatsUp indicated: [cid:part1.07000105.02090002@wabroadband.com]<http://monitor.wabroadband.com/NmConsole/Workspace/DeviceStatus/DeviceStatus.asp?nDeviceID=177>bandwdith manager<http://monitor.wabroadband.com/NmConsole/Workspace/DeviceStatus/DeviceStatus.asp?nDeviceID=177> HTTP(Down at least 5 min) <http://monitor.wabroadband.com/NmConsole/Reports/Full/Device/ProblemAreas/RptStateChangeTimeline/RptStateChangeTimeline.asp?nDeviceID=177> So how can I protect my bandwidth manager and still monitor it at the same time? I guess I could disable HTTP monitor and do pings on the monitor software. Three more quick questions: 1) I didn't put in these lines because I wasn't sure what IP's to use, same problem when I installed PRTG I'm not sure what IP's I need to monitor within the system to watch: # Edit these rules to reflect your actual IP addresses! # add chain=input src-address=159.148.172.192/28 comment="From Mikrotikls network" add chain=input src-address=10.0.0.0/8 comment="From our private LAN" 2) The "add chain=input action=log log-prefix="DROP INPUT" comment="Log everything else"" command indicates there is a log that I can watch foul traffic, where do I find that log? 3) Is there more sets of examples for firewalls for my Mikrotik routers somewhere, I'm searching WIKI's right now. Thanks for the help, hope your weekend is going well, I already have logged 100 miles just chasing outages down in the last 12 hours. Forbes On 9/5/2010 10:39 AM, Butch Evans wrote: On Fri, 2010-09-03 at 14:15 -0700, Forbes Mercy wrote: I keep adding filters as traffic presents itself but help and training is very expensive and extraordinarily technical While I would disagree that training is "very expensive", I would have to agree that it is very technical in nature. My training sessions are normally under $300/day for students (not counting hotels/flights/etc.). On my backhauls when one Mikrotik goes down its not unusual for the foul traffic to permeate throughout (yes I'm bridged) the network and take down other Mikrotik's and often requires a drive to reboot then they work fine again, irritating, yes but still great equipment. Training would be especially good if you could learn something that would keep you from having to roll a truck even once every 2 weeks. It wouldn't take long to pay for that. Ubiquiti is a monster for power and throughput, it's menus are basic but filters entry options are slim and limited to IP rather than by protocol so some things sneak through that wouldn't with Mikrotik. This, unfortunately, is one "cost" of less expensive gear. FWIW, you have most of the same functionality available in both platforms, but it's just not in the GUI for UBNT. I promised an analogy so here goes, I feel from experience that Mikrotik is the Linux of equipment, you better know what you're doing when you buy it. UBNT is linux, too. :-) Ubiquiti is like Windows, pretty GUI driven, and simplified at a reasonable cost. You have access to iptables and more in the ssh/telnet interface with Ubiquiti.
-------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
