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

Lots of 60001 drops

I've currently got a BT Home Hub providing routing on 192.168.1.x, I've connected my Sophos UTM to a LAN port, which in turn is providing routing/firewall on 192.168.2.x. I know this causes double NAT and I've not had any problems using the internet, but in the firewall logs, I'm seeing hundreds of these drops everyday:

2017:01:20-00:00:23 utm ulogd[5185]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="18:62:2c:70:xx:xx" dstmac="94:18:82:38:xx:xx" srcip="192.168.1.254" dstip="224.0.0.1" proto="2" length="36" tos="0x00" prec="0xc0" ttl="1" 2017:01:20-00:00:23 utm ulogd[5185]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="18:62:2c:70:xx:xx" dstmac="94:18:82:38:xx:xx" srcip="192.168.1.254" dstip="224.0.0.1" proto="2" length="36" tos="0x00" prec="0xc0" ttl="1"

And while this might not be a problem, I don't think I've setup my DNAT properly and currently have this as setup as the only rule:

Any help or advice would be much appreciated!



This thread was automatically locked due to age.
Parents
  • Hi Bob and Richard,

    I managed to setup a rule to drop packets without logging them.

    I've come across another problem, having had looked at the logs.

    2017:01:23-00:19:20 utm ulogd[4873]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="18:62:2c:70:xx:xx" dstmac="94:18:82:38:xx:xx" srcip="65.20.0.43" dstip="192.168.1.100" proto="6" length="40" tos="0x00" prec="0x00" ttl="248" srcport="993" dstport="46048" tcpflags="ACK RST"

    2017:01:23-00:29:14 utm ulogd[4873]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="88:63:df:9e:xx:xx" dstmac="94:18:82:38:xx:xx" srcip="192.168.1.64" dstip="192.168.1.100" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="4242" dstport="63096" tcpflags="RST"

    2017:01:23-00:33:24 utm ulogd[4873]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="18:62:2c:70:xx:xx" dstmac="94:18:82:38:xx:xx" srcip="65.20.0.43" dstip="192.168.1.100" proto="6" length="40" tos="0x00" prec="0x00" ttl="248" srcport="993" dstport="51278" tcpflags="ACK RST"

    2017:01:23-00:49:28 utm ulogd[4873]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="18:62:2c:70:xx:xx" dstmac="94:18:82:38:xx:xx" srcip="65.20.0.43" dstip="192.168.1.100" proto="6" length="40" tos="0x00" prec="0x00" ttl="248" srcport="993" dstport="52704" tcpflags="ACK RST"

    I don't know how these are getting into the network, since my Home Hub firewall is active and there is no port forwarding to my UTM enabled. Recently, I've also been having problems with BBC iPlayer videos not working, which is definitely something to do with the UTM, since I didn't have this problem before. There are also connections from devices on the Home Hub on 192.168.1.x being dropped (192.168.1.100 is the UTM). All ports are open outbound (I know this is bad security practice, but opening up ports for the applications I use would be quite tiresome), so still think there is something with my double NAT setup.

     

    Thanks,

    Arjun

  • Hi Arjun,

    The source IP in your log extract "65.20.0.43", resolves to "mail.btinternet.bt.lon5.cpcloud.co.uk". Do you use any e-mail clients which aren't web-based, to access your e-mail?

    Regards,

    Richard

  • Hi Richard,

    Yes, I do use that mail server but not any problems with it recently.

    Still can't get iPlayer to work, and non of the IP's in the firewall log seem to correlate to any BBC servers.

    Thanks,
    Arjun 
Reply Children
No Data