NimbostratusThe default behavior for disabled virtual servers is to send a RST to a SYN. If you are looking for a passive drop behavior, then a packet filter rule with the action set to "discard" would do the trick.
NimbostratusThanks. I created a Packet Filter rule to allow an internal subnet (First) and tried to create another rule (Last) to drop (Action: "discard") everything else where the instructions in the doc linked below say to "Enter Expression Text" with nothing in the text field, which apparently means everything (?), and I got the following error:
01070087:3: Packet filter rule '/Common/TestRule1': rule matches all traffic and action is not "continue"
Why should the rule be set to "continue" rather than "discard"?
NimbostratusSo I got it to accept 2 rules I put in where I had to add an actual expression to "Enter Expression Text" field, but I have not yet enabled packet filtering. The instructions on that page I linked basically just says to select that checkbox and that's it.
What I have so far, Jeff, and please correct me if this is wrong, but I have the following: Rule 1 (First): Allow ("Accept")the management networks (ie: ( src net 192.168.1.0/24 ) and ( dst net 0.0.0.0/0 )) on all vlans. Rule 2 (Last): Deny ("Discard") everything else (ie: ( src net 0.0.0.0/0) and ( dst net 0.0.0.0/0 )) on all vlans.
Will this accomplish what I'm looking for?
Anything that does not match the first rule should hit the second rule, which is basically the same as unhandled traffic. You can verify in the var/log/pktfilter file. Make sure you have console access when you test. There maybe variables that I am not aware of in your set up.
Easiest config would be to configure your accept rule, and on the Enable screen, set unhanded traffic to discard. That is the configuration I have tested.
NimbostratusIs packet filtering supposed to block management port access, also? I enabled packet filtering to only allow a single subnet and discard everything else, but tested it from a remote VPN connection (allowed by System -> Platform) and I was still able to get to and login into the BIG-IP management GUI. I check FW logs it surely was a different source address.
Not the actual management port, but management on self IPs. For management port access see this article: https://support.f5.com/csp/article/K13309 However, this does not simply drop the TCP SYN but delivers a 403. Management port should not be configured with an external routable IP but rather require VPN, or other internal access in order to reach it. Management port is simply not designed to be external facing.
NimbostratusOk thanks. So far, I have an 'Accept' rule which allows our internal subnets, and a 'Discard' rule for everything else:
( src net 192.168.0.0/16 )
Note, this has no destination entered into the expression, only a source subnet, which will be allowed in and out to anything internal and external. This rule-accepted traffic gets logged. I originally thought that to include "any" into a rule, it would have to use a subnet of 0.0.0.0/0, but this did not work properly.
And one to 'Discard' everything else (any traffic not defined in the 'Accept' rule, which is anything that does NOT have a source of 192.168.0.0/16) destined for a VIP in the 192.168.2.0/24 subnet:
( dst net 192.168.2.0/24 )
Note, this has no source entered into the expression, only a destination subnet. This rule-discarded traffic gets logged.
Lastly, the general settings are configured to discard any unhandled packets, but these do not get logged. This configuration of packet filtering is primarily to prevent any external sources from accessing or even knowing any of the VIPs exist, even when disabled. I created the 'Discard' rule just to enable the ability to log discarded traffic.
