On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com> wrote:> > I think you need to use tcpdump and turn up firewall debugging.sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200401/d5366a6b/attachment.html>
On 2/04/2020 5:28 AM, Mark Boyce wrote:> On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com > <mailto:gdt at lexort.com>> wrote: >> >> I think you need to use tcpdump and turn up firewall debugging. > > sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) > > MarkOr the stateful entry still exists when the table entry is updated. Does your script also issue a command to kill existing states from that host after it has updated the table, e.g. pfctl -k 45.143.220.235 Larry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200402/039916cd/attachment.html>
On 2020-04-01 16:39, Larry Moore wrote:> Or the stateful entry still exists when the table entry is updated. > > Does your script also issue a command to kill existing states from that > host after it has updated the table, e.g. pfctl -k 45.143.220.235Yes, as I said in my OP that's the actual command that I used. -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com
On 2020-04-01 16:28, Mark Boyce wrote:> On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com > <mailto:gdt at lexort.com>> wrote: >> >> I think you need to use tcpdump and turn up firewall debugging. > > sngrep is your friend …My bet is UDP vs TCP on firewall rules :-)block drop in log quick on bge0 from <AUTOBLOCK> to any block drop out log quick on bge0 from any to <AUTOBLOCK> Am I misunderstanding pf? I thought that that would block TCP, UDP, ICMP and anything else trying to get through. Since I started looking at this closer I did find that only some connections have this problem. Most get blocked as soon as the IP is passed to the AUTOBLOCK table. -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com
On 2/04/2020 5:39 AM, Larry Moore wrote:> On 2/04/2020 5:28 AM, Mark Boyce wrote: >> On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com >> <mailto:gdt at lexort.com>> wrote: >>> >>> I think you need to use tcpdump and turn up firewall debugging. >> >> sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) >> >> Mark > > Or the stateful entry still exists when the table entry is updated. > > Does your script also issue a command to kill existing states from > that host after it has updated the table, e.g. pfctl -k 45.143.220.235 > > Larry. >Hmm, missed that in your original post. Could 'pfctl -K' be of help, I would suggest either removing 'quick' from your 'pass' rule or placing that line after the 'block' rules. Larry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200402/3ef3e9b9/attachment.html>
On 2/04/2020 6:35 AM, D'Arcy Cain wrote:> On 2020-04-01 16:28, Mark Boyce wrote: >> On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com >> <mailto:gdt at lexort.com>> wrote: >>> I think you need to use tcpdump and turn up firewall debugging. >> sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) > block drop in log quick on bge0 from <AUTOBLOCK> to any > block drop out log quick on bge0 from any to <AUTOBLOCK> > > Am I misunderstanding pf? I thought that that would block TCP, UDP, > ICMP and anything else trying to get through. > > Since I started looking at this closer I did find that only some > connections have this problem. Most get blocked as soon as the IP is > passed to the AUTOBLOCK table.I suspect you have a good understanding of pf. Have you included in your script running 'pfctl -k <ip_address>' to kill any states that may exists after you update your <AUTOBLOCK> table? In pf, like IP Filter, the last matching rule wins. What can't be determined from the information provided is whether any connections that have been established from networks you have listed in the table <FRIENDS>, also appear in the <AUTOBLOCK> table. Removing the 'quick' parameter from the rule for <FRIENDS> will allow packets to fall through to the next rules. Alternatively, moving the 'pass' rule to below your 'block' rules will allow any connections originating from networks listed in your <FRIENDS> table and also exists in the <AUTOBLOCK> table, will be blocked. Larry.