UTM 9.703-3 IPFix stopped working

Hi Shaun and welcome to the UTM Community!

Do you see anything relevant in the Firewall log?

Cheers - Bob

Hi Bob,

Thanks for the welcome.

Good idea!

Please also note, other sensors are working fine from the PRTG box - eg snmp is picking up the appropriate stuff from the VM, linux health, memory, CPU, etc, and of course a normal ping.

Around lunchtime today (it 7:20pm now where I am), extracted the firewall logs, and looked at all the lines that had both 10.1.1.1 (the sophos) and 10.1.1.20, the prtg box.

saw source IP 1.20 and dest IP 1.1, port 5351 proto 17 being blocked alot, lines like below, every 42 minutes - an odd timing.

id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001"  srcip="10.1.1.20" dstip="10.1.1.1" proto="17" length="30" tos="0x00" prec="0x00" ttl="128" srcport="5351" dstport="5351"

So added a rule to allow UDP traffic from 10.1.1.20 to 10.1.1.1.  I think it was unrelated and there was another piece of software on that machine, so I stopped that as well.

The IPFIX sensor didn't start working, stopped and started both the firewall and PRTG.

Just did another extract -

I am now only seeing drops starting with this -> id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" 

And the details of the drops after this all look to me like failed SMB communications fails, which shouldn't matter.

srcip="10.1.1.20" dstip="10.1.1.1" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="51438" dstport="445" tcpflags="SYN" 

srcip="10.1.1.20" dstip="10.1.1.1" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="51441" dstport="139" tcpflags="SYN"

srcip="10.1.1.20" dstip="10.1.1.1" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="51543" dstport="135" tcpflags="SYN" 

Saw 3 like this, again pretty sure it's SMB related.

mark="0x3441" app="1089" srcmac="x" dstmac="x" srcip="10.1.1.20" dstip="10.1.1.1" proto="17" length="78" tos="0x00" prec="0x00" ttl="128" srcport="137" dstport="137" 

Any other ideas?

regards

Shaun

I guess that 10.1.1.1 is "Internal (Address)" - right, Shaun?  Why would your UTM be receiving NETBIOS requests from the PRTG server?

Cheers - Bob

Hi Bob,

Correct, 10.1.1.1 is the "Internal (Address)" of the Sophos box.

Don't know why, shouldn't be, just a standard win 10 box, with PRTG on it, it's not Windows server.

Disabled NetBIOS over TCP/IP on the PRTG box now, will see in a few hours how things change.

regards

Shaun

Noticed something important after all this ->

My notices of running out disk space were going to junk!

The data disk was at 100%.

Did the empty out procedure via putty ->

pg_archivecleanup /var/storage/pgsql92/data/pg_xlog 000000010000002C00000037

And got it back down to 50% free.

IPFix still not working after this.

Any ideas?

Usually, when you see a "60001" drop, it's because it was a response that took too long and the connection tracker has assumed that the conversation was finished.  Making a firewall rule to allow the traffic doesn't help the connection tracker know where to send the packet, so it just gets lost.

I asked about the NETBIOS requests because they could be an indication of a misconfiguration in the Win 10 box or the PRTG setup.  If you didn't make any changes there, then suspect the connection tracking issue I mentioned.  In any case, you can re-enable SMB on the Win 10 box.

What happens if you extend the relevant timeout?  As root at the command line:

cc set packetfilter timeouts ip_conntrack_udp_timeout 150

Cheers - Bob

Hi,

Reload from scratch, restore backup, this issue fixed.

regards,

Shaun

Hi,

Reload from scratch, restore backup, this issue fixed.

regards,

Shaun