From: "Massimo S." <ecs-isp@2rosenthals.com>
Reply-To: ml@ecomstation.it
Subject: Re: [eCS-ISP] help about an Injoy FW rule
To: eCS ISP Mailing List <ecs-isp@2rosenthals.com>
References: <list-9311737@2rosenthals.com>
Organization: eComStation dot it
Message-ID: <27eb39ab-e184-bb06-0ce3-e4cc103b535f@ecomstation.it>
Date: Sun, 17 Mar 2024 19:50:37 +0100
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; it-IT; rv:1.7.13) Gecko/20060424
 Thunderbird/1.0.8 Mnenhy/0.7.4.0
MIME-Version: 1.0
In-Reply-To: <list-9311737@2rosenthals.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: it-IT
Content-Transfer-Encoding: 7bit



Il 16/03/2024 20:40, Steven Levine ha scritto:
> In <list-9310913@2rosenthals.com>, on 03/16/24
>     at 11:35 AM, "Massimo S." <ecs-isp@2rosenthals.com> said:
> 
> Hi Massimo,
> 
>> this is a very old post nov. 2022
> 
> That's for sure. :-)
> 
>> i created the rule (using FW gui), reloaded the fw rules, all ok at the
>> reboot of the firewall server (early in the morning i scheduled a reboot)
>> Injoy stop completely to work and the firewall "close" all communications
>> so that you can't connect anymore with the remote console to fix the
>> issue
> 
> Oops.
> 
>> i repeat that i created the rule using FW gui, so there can't be an space
>> or a bad char in firerule.cnf
> 
> This is irrelevant.  The GUI cannot totally prevent you from creating
> rules that will not work.
> 
>> Injoy don't show any error in firewall.log
> 
> In my experience, firewall.log is good at detecting and reporting syntax
> errors, but it's not as good at detecting and reporting semantic errros.
> 
>> while i get in activity.log
>> this:
> 
>> Fatal: failed to send packet (32799 - 0)
> 
> This is from
> 
> gateway\fxio.c:429
>     rc = FX_Ether_Send(hPipe, packet, len, &ulBytes, pppoe);
>     if (rc)
>        syslog(TRACE_FATAL, "failed to send packet (%d - %d)", rc, ulBytes);
> 
> and
> 
>    #define ERROR_LONGLOCK                  32799
> 
> This implies that fxwrap.sys is stuck for some as yet unknown reason and
> this cause the underlying DosWrite to fail with ERROR_LONGLOCK.
> 
>> that's a mistery to me
>> any idea?
> 
> Did the failure presist when you forced a reboot?

the firewall in that condition do not reach the internet so each 30 minutes
the fault daemon gives a reboot

> How did you recover from the failure?

i have a 2 minutes delay at boot before gateway.exe is being started
this let me connect to the remote fw server rename gateway.exe so that
it do not start and recover firerule.cnf from the bkup

> Did you forget to include a copy of the problematic rule in your message?

assist_rem_srv6_in	
		Destination-Port = "55000",
		Source = "1.2.3.4",
		Destination = "My_IP",
		Rule-Action = Portmap,
		Mapping-Dest-IP = "192.168.1.8",
		Mapping-Dest-Port = 3389

assist_rem_srv6_out	Rule-Status = Disabled
		Source-Port = "3389",
		Source = "192.168.1.8",
		Rule-Action = Portmap,
		Mapping-Dest-Port = 65488

ext_m_in	
		Destination-Port = "55000",
		Source = "1.2.3.5",
		Source-Netmask = 255.255.255.254,
		Destination = "My_IP",
		Rule-Action = Portmap,
		Mapping-Dest-IP = "192.168.1.8",
		Mapping-Dest-Port = 3389

ext_m_out	
		Source-Port = "3389",
		Source = "192.168.1.8",
		Rule-Action = Portmap,
		Mapping-Dest-Port = 55000

i guess the issue that create problems is the one "assist_rem_srv6_in"


> Have you checked if the recently announced ijfw 4.2.3 release has any
> effect on his failure?

still not

massimo