Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 3 subscribers
  • Views 10457 views
  • Users 0 members are here
Options
Suggested
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

Difference between allowed dst IP and allowed dst network in FW rule

ThomasBrunko1

Hi,

I'm setting up an UTM-9 on an sg210 and I'm stumped by a really simple question:

    What is the difference between setting a single IP and setting a network range in the destination field of a firewall rule?

I'd say the latter rule matches each and every destination ip in the configured network, but that's not how the UTM-9 appears to beahve. My setup:

  • UTM-9 is connected with a single interface with ip/mask 192.168.1.2/24 to a switch.
  • Not sure if this is relevant, but the default gw is configured on an other interface with ip 192.168.100.1/24.
  • The only other connected host on the switch is my workstation, configured with ip 192.168.1.1/24
  • On the UTM-9 I start a listener on 192.168.1.2:110 (with nc -v -l 192.168.1.2  110)

As expected, trying to connect from my workstation to 192.168.1.2:110 fails and the firewall log shows that the connection was dropped by the default rule.

Now I add a firewall rule to allow traffic from 192.168.1.1 to 192.168.1.2 port 110: I can establish the connection, as expected.

Now I replace the target ip with the interface network 192.168.1.2/24 in the firewall rule and restart the 'nc' tool: I'm not able to connect. The firewall log shows the default drop rule dropped the connection.

Could someone please explain to me, why the last step doesn't work as I hoped it would?

Thanks.



This thread was automatically locked due to age.
  • 0

    Hi, Thomas, and welcome to the UTM Community!

    Please insert pictures of your Interface definitions.  Also of the Edits of the Firewall rule and the Network object, both with 'Advanced' opened.

    Cheers - Bob

  • 0 in reply to BAlfson

    Thanks for the fast reaction!

    In the meantime I had to make some changes, but the problem is still there:

    • UTM-9 has now 172.17.255.2/24. The Interface is called INET
    • My workstation now has 172.17.255.1/24.
    • The firewall rule is at the top (one disabled rule is above it).

    Here the interface definition:

    Here the network objects corresponding to my workstation:

    Workstation network object

    Here the network object for the firewall rule:

    Finally, the firewall rule:

    I've also tried to use the automatically generated network definition, which also doesn't work:

    Edit: Added POP3 definition.

  • 0 in reply to ThomasBrunko1

    None of the firewall rules you've described or showed us should have any effect. IPs in a given subnet communicate directly with each other - the traffic should not be seen by the UTM unless there's a configuration error - probably on the client.

    Please show a related block line from the Firewall log file.  Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.

    Cheers - Bob

  • 0 in reply to BAlfson

    Sure, they should communicate directly with each other. Otoh: There's a packet arriving on the interface of the firewall, sent by who knows who.This should be dropped if not explicitly allowed, right?

    Anyway, here're the log excerpts.

    • Packet gets accepted:
      2016:06:25-20:43:33 vpngate-2 ulogd[5762]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="12" initf="eth5" srcmac="00:14:22:xx:xx:xx" dstmac="00:1a:8c:yy:yy:yy" srcip="172.17.255.1" dstip="172.17.255.2" proto="6" length="60" tos="0x00" prec="0x00" ttl="64" srcport="60538" dstport="110" tcpflags="SYN"
    • Packet gets dropped:
      2016:06:25-20:45:09 vpngate-2 ulogd[5762]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth5" srcmac="00:14:22::xx:xx:xx" dstmac="00:1a:8c:yy:yy:yy" srcip="172.17.255.1" dstip="172.17.255.2" proto="6" length="60" tos="0x00" prec="0x00" ttl="64" srcport="60539" dstport="110" tcpflags="SYN"

    I've had a look at the iptables rules generated by my firewall rules:

    • When I use the IP in the dst field, the following rule is added:
      -A USR_INPUT -s 172.17.255.1/32 -d 172.17.255.2/32 -p tcp -m tcp --sport 1:65535 --dport 110 -m logmark --logmark 12  -j LOGACCEPT
    • When I use the network in the dst field:
      -A USR_FORWARD -s 172.17.255.1/32 -d 172.17.255.0/24 -p tcp -m tcp --sport 1:65535 --dport 110 -m logmark --logmark 12  -j LOGACCEPT

    The first looks like I'd expect it to look (except that USR_-prefix).

    I hope this helps,
    Thomas

  • 0 in reply to ThomasBrunko1

    If you check #2 in Rulz, you'll get the idea that user rules come after automatic rules, hence the USR_ prefix.

    For the issue at hand, consider #3 and #4.  In #4, you see that using "INET (Address)" in 'Destinations' causes the config daemon to create a rule that is placed on the USR_INPUT chain.  I would have expected the same to occur when using the "INET (Network)" object.

    Just out of curiosity, what happens if, instead of using the "INET (Network)" object,  you use a  Network object INET2 = 172.17.255.0/24 bound to the INET interface?  I would expect that that will create an iptables USR_INPUT rule.

    Since there's no need to write rules for allowing packets in an INPUT chain, I bet you may be the first person to have identified this anomaly.

    Cheers - Bob

  • 0 in reply to BAlfson

    ... sorry for the delay ...

    I've bound my the network definition to the INET interface:

    ... and the resulting rule is:

    -A USR_FORWARD -s 172.17.255.1/32 -d 172.17.255.0/24 -o eth5 -p tcp -m policy --dir out --pol none -m tcp --sport 1:65535 --dport 110 -m logmark --logmark 13  -j LOGACCEPT

  • 0 in reply to ThomasBrunko1

    Thanks, Thomas.  I'll get one of the Sophos folks to comment on whether this is intended behavior.

    Cheers - Bob