Discussion in 'Cisco Small Business Routers and VPN Solutions' started by Aviator256, Jan 21, 2008.

  1. Aviator256

    Aviator256 LI Guru Member

    The firewall seems to be having issues (or maybe its me). Since the firewall has no effect on anything outside of the NAT boundary, I turned all of the ports inbound to an IP address (ghost) on my LAN that has nothing connected. Now I have the ability to LOG everything with my name on it. A poor mans sniffer. I thought all was good. Like most firewall programmers, I created a bunch of rules to allow accedd and deny access with all logging turned on. I created one general rule at the bottom of the ACL that is allow any source to any destination all protocols and log them with the identifier UNKNOWN. O.K. now I get to see everything. This seems to work well till I add rules above the general rule at the bottom. I have a total of 45 rules. All are turned on and are sent to the LOG. I have some repeating inbound UDP and TCP from some computers on high port numbers that repeat every few minutes. No big deal. But very useful for testing. One is perfect. It repeats every five minutes on a single port. Since my IP is not static, I figure it is someone elses problem that I inherited. Although the source port of this request is random (expected) and the destination port is fixed (local port), I wrote an ACL that is: ALLOW and LOG UDP 6477 ANY INTERFACE ANY SOURCE ANY DESTINATION. Easy enough. Of the 45 rules, this one is number 40 (priority). I process all of the allow rules first and the deny rules last (for speed). Within these two categories, I have the most specific first and the most general last. The only exception is the last rule (bucket rule) to allow and log all of the things not cought by the other rules. I noticed four things:

    The service specific rule does not log (allow or deny).
    When the rule is turned off, the "bucket" rule LOGS the incomming data.
    When the firewall is turned off, the ACLs still LOG.
    The only rules that LOG are "ANY" service rules.


    Is there a special method to write an ACL for incomming TCP/UDP traffic to a fixed destination/local port (service)?

    Is there an issue with the LOG function?

    Is there a plan for IPV6 functionality?

    If I get time in the future, I will run ETHEREAL on the ghost port.

    At this point, I think I will keep my software based firewalls running on my hosts.

    I alsi noticed that the firewall temporarly opens when you press the "save settings" button on the "basic firewall settings" page. This happens regardless of toggeling the radio buttons. I suggest this be corrected in the next firmware release. The correct method is to close the WAN interface prior to starting the shutdown. Then close the WAN interface again first thing when starting back up. After initialization is complete, wait a second, then turn on the WAN interface.

    Presently, the WAN interface comes up prior to the firewall. Not good.

    PS> I purchased the SSL Concentrator from the other company. It works great out of the box. Only took one day to program. I have not found any short comings with it.

    I simply rate them as I see them.

    Everything here has been consistantly exceeding my troubleshooting vs. usefullness ratio.

  2. Aviator256

    Aviator256 LI Guru Member


    I was able to mirror the WAN port and send Syslog Data to my host for capture with Wireshark. After filtering the broadcast and multicast traffic then correlating the syslog data with the network traffic in Wireshark, I was able to determine that the firewall is functioning, but not logging all of its actions. I have not been able to determine if there is some correlation between how an ACL is written and the lack of logging. Some rules LOG and some do not and there is little difference between the ones logging and the ones not logging (like a different WAN IP address only).

    I think some squirrels must have gotten into some of the code.

  3. Aviator256

    Aviator256 LI Guru Member

    I think I found the bug. The "log prefix" seems to be sensitive to key words. If I place "HTTPS" as the first word in the log prefix, the log will no longer appear in the syslog. Yet, the ACL is still functioning. If I replace the key word "HTTPS" with somthing like "SSL" it starts to log. Of course, it takes a few seconds after the change for the firewall to update before the change takes effect. My word of advice is to avoid using protocol keywords in the "log prefix". Although, I checked "HTTP" and it works fine. Maybe "HTTPS" is the only key word that does this. Also, take care to not modify a firewall setting before the previous modification has processed. Several times, I have had the entire ACL dropped. Rebooting did not restore it. Thankfully, I had been making backups of the router for each and every change (trust issue). The restore function works flawlessly.
  4. davidpw

    davidpw LI Guru Member

    very interesting observations - thanks.

    I have found that sometimes things seem to get confused and the rules do not work properly. One thing I tried that seems to help is to leave the thing alone for 15 secs after I APPLY any settings. May be related to your observation.

  5. Aviator256

    Aviator256 LI Guru Member

    I agree that it takes time for the firewall changes to update before they begin to reflect in the ACL LOG. 15 seconds seems about right. After trying some other "log prefix's", it seems to be more related to the length of the prefix in characters. There is a possibility that exceeding a certain character length causes the ACL to not send a message to the syslog. I still need to test this theory.
  6. Aviator256

    Aviator256 LI Guru Member


    Yep, I proved it. Anything over 14 characters in the "log prefix" will most likely cause the ACL to not to show up in the log (at all - no line - nothing) even if the "log" box is checked. Although, the ACL is still working. I suggest that Linksys either limit the field length so that the user can not type in over 14 characters or extend the database beyond 14 characters. Here is another item to add to the list for the next firmware release.

    In the mean time, I suggest that everyone use short "log prefix" entries to guarantee the entries show up in the log. Be assured that the ACLs are still working even if they are not showing up in the log. Where this is a big issue is when there is a DENY statement in the ACL and it is preventing web site access, etc. and there is no reason in the firewall log.

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice