This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Automatic Firewall rules option troubles

Hi.

I found an issue with the "Automatic firewall rules" in the Server load balancing section, and I suppose it might be happening in other areas as well. I contacted support about this and they just replied to me to add a new feature, which I will. But thought to put something more actively read here.

First thing, when I configured a load balancing rule and turned on the auto rule, it worked fine. But it does not log that specific traffic. (this is the feature to add.) So to try to do it myself, I created a FW rule for the same port and destination and enabled logging. SHOCKINGLY..  it does not allow the traffic! And I have no way of knowing what the auto rule does because I can't see it anywhere (another feature).

But that's not all....
After deleting the FW rule I put in, the traffic CONTINUED TO FAIL! yet without logging. So now I'm sitting with no FW rule and the load balancing rule with the auto FW rule option active with no traffic. Solution? I had to disable the auto-FW rule, save it, and then re-enable it.

I also tried performing the test by first disabling the auto-FW rule and then making my manual FW rule but still it did not allow the traffic.

What gives?


This thread was automatically locked due to age.
Parents
  • it does not allow the traffic! 

    This probably is because the rule is fashioned to allow traffic in a different chain (FORWARD instead of INPUT, for example).  Please show the block from the Firewall log when the manual rule is in place.

    Cheers - Bob
Reply
  • it does not allow the traffic! 

    This probably is because the rule is fashioned to allow traffic in a different chain (FORWARD instead of INPUT, for example).  Please show the block from the Firewall log when the manual rule is in place.

    Cheers - Bob
Children
  • Oh yeah.. hmm. well the log in the FW with either no FW rule or even the manual FW rule has this which is crazy because it should be matching the rule:

    Line 4120: 2012:04:11-16:35:39 173 ulogd[5641]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth1" outitf="eth0" srcmac="***x" dstmac="***x" srcip="xx.xx.xx.xx" dstip="10.0.20.90" proto="6" length="52" tos="0x00" prec="0x00" ttl="118" srcport="49373" dstport="443" tcpflags="SYN" 


    server load balancing with auto-fw-rule
     Chain LOGACCEPT (3 references)
    > LOGACCEPT  tcp  --  anywhere             173                 tcp spts:tcpmux:65535 dpt:https LOGMARK match 2


    Check this out. I repeated this a few times.

    First of all, while tailing the log in the web GUI, if you go and change the port for the User portal, the tail stops working; you have to re-launch it. I found that out because I thought that maybe my issue was because the User Portal was using also 443 and it was disabled and so somehow the router was just hiding it away. I left it as some other port so that it was not messing with me.. I still think that making this change somehow got the router to listen to my manual FW rules for port 443.

    But I noticed this interesting behavior:
    - turned off the load balancing config.
    - created FW rule for 443 to REJECT.
    - tested tcp ping and saw in the logs the rejections! great.
    - changed FW rule for 443 to DROP.
    - tested and saw the drops. Great.
    - changed FW rule for 443 to ACCEPT.
    - tested and saw the accepts! Still no response on client because nothing's listening on that port.
    - Now I go and enable the load balancing rule (with auto-fw disabled)
    - test tcp ping... and the log shows IT STARTS DROPPING!!!!?!??!?!?!?!?!?
    - turn off the load balancing config.
    - tested tcp and ACCEPTS again! SOB!
    - turned on again the load balancing but this time with auto-fw rule enabled.
    - tested tcp. Log shows nothing, but the tcp ping gets a response from the real servers behind it.

    This is a bug!