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

Why doesn't override a cloned accept-rule its original drop-rule?

I made a simple drop-rule (realy barebone, for sake of simplicity):

Source zones: LAN
Source networks and devices: ANY
Destination zones: WAN
Destination networks: one FQDN host (its actually the address of a VPN-server)
Services: any

If I enable the rule, then my cisco vpn client can't connect to the vpn anymore, which proofs the rule is working.

Then I cloned that rule, changed 'drop' into 'allowed' mode and put it in the order of rules at the very top.
(Neither scanning nor web- or appfilters are applied)

Oddly enough, despite having the allow-rule enabled, I couldn't connect to the vpn! I would have assumed the allow-rule to cancel the drop-rule completely.
When checking with policy tester, connecting to vpn is marked as allowed.

What's happening here? How can I achieve a complete override?
(Just in case, if you wonder "what the heck is he doing with such a sensless setup?": in the end, the allow-rule will have traffic shaping enabled)

SFOS 17.5.12 MR-12

This thread was automatically locked due to age.

Parents

0 FormerMember over 5 years ago

Hi Sacha Roland,

I would suggest to check the Log Viewer and see if the traffic really go through the correct firewall rule -

Another thing you can test is to change the FQDN host to the IP address of the VPN server and see if it works.
Cancel
Vote Up 0 Vote Down

Cancel
0 Sacha Roland over 5 years ago in reply to FormerMember

Thank you. In the log viewer, I saw incomming connections that were blocked. If I change destination and source zones to "any" the allow rule works.
Cancel
Vote Up 0 Vote Down

Cancel
0 Sacha Roland over 5 years ago in reply to Sacha Roland

But after all, I still don't understand, why there's no mirror-symmetrical relationship between drop-rule and allow-rule. Why has "drop" more impact than "allow"?
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 5 years ago in reply to Sacha Roland

Could be old connections of conntrack still hitting the old rule.

Conntrack tracks the connection for some time, if your client still tries the same ports, the old conntrack entry will be used.

Re do the process, use conntrack -F to flush all conntrack entries (will act like reboot for the firewall and terminate all connections!) and redo the test.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 LuCar Toni over 5 years ago in reply to Sacha Roland

Could be old connections of conntrack still hitting the old rule.

Conntrack tracks the connection for some time, if your client still tries the same ports, the old conntrack entry will be used.

Re do the process, use conntrack -F to flush all conntrack entries (will act like reboot for the firewall and terminate all connections!) and redo the test.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data