Guest User!

You are not Sophos Staff.

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

firewall dropping bootp packets in uplink balalanced utm9 [9.413-4] environment

hi all,

i'm new to utm9.  been using it for a couple of weeks, and have gotten myself to a pretty good spot mostly due to the awesome history of forum interaction related to issues i've encountered.  i've run into a problem that i can't quite clear up, however, so i'd appreciate your input.  (noting of course that this is likely not a "problem" so much as a configuration issue) :)

firewall is logging the following entries repeatedly:

2017:05:07-00:05:59 mrclean ulogd[558]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth2" srcmac="" srcip="10.10.2.104" dstip="10.10.2.1" proto="17" length="328" tos="0x00" prec="0x00" ttl="64" srcport="68" dstport="67" 



...where 10.10.2.104 is the (dynamic) IP of my failover WAN, and 10.10.2.1 is the default gateway of the same failover WAN.

other pertinent information is as follows:
- external WAN is up and running at <ISP_IP>/23, main internal interface is good to go at 10.10.1.1/24
- failover WAN is up and running at 10.10.2.104/24, with this address being served by DHCP on secondary WAN (note: this is a dd-wrt router configured in client mode)
- uplink balancing is setup between external WAN and failover WAN, with the latter in standby (i've seen it suggested to have both in active interfaces with a 100/0 weight, but this seems to be working)
- no link aggregation or multipath, this setup is intended for redundancy only
- dns service set to answer internal IP, forwarders setup using availability group of 2 (external, 3rd party) DNS servers, "use forwarders assigned by ISP" unchecked
- dhcp service is up for internal, answering range 10.10.1.1/24
- firewall set for internal -> any -> any ipv4
- masquerading set for internal (network) -> uplink interfaces (both external WAN and failover WAN)
- SNAT rule setup for internal (network) -> any -> failover (WAN) (network), source translation failover (WAN) (address), automatic firewall rule [[to access dd-wrt without needing to activate remote access]]

all connectivity is functioning as desired. i've tried creating a number of new firewall rules--if even to stop logging these drops--using various scenarios including specifying the 10.10.2.1 gateway as specific host, allowing all/all/all, and quite a few other configurations. i'm hoping someone spots an obvious flub in my configuration and has something to suggest. guessing this has to do with dhcp traversal attempts between the two subnets but i can't figure out what is occurring, specifically.



This thread was automatically locked due to age.
Parents Reply Children
  • Thanks Sachin!  Here you go:

     

  • Looking at the configurations and the deployment scenario, eth2 and the ISP modem are directly connected devices. Hence, the traffic initiated by the WAN interface should not pass through the firewall rule as it is an UTM initiated traffic. Please verify the MAC address of the WAN interface (eth2) with the MAC address discovered and dropped in the logs. Do they match?

    Cheers-

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • Hi Sachin,

    According to my logs the dropped MAC (src) belongs to the device labeled "Internal" in my previous screenshot--eth0--which is the interface to LAN. Indeed, the eth2 (Failover WAN) and eth1 (External WAN) are directly-connected devices.

    Thanks!

  • Interesting! I wonder why would an internal interface NAT the IP with WAN interface and  do a DHCP request?

    Provide me some time to investigate.

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • Hi, and welcome to the UTM Community!

    While Sachin researches, you might consult #7 in Rulz.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Ah yes, the esteemed BAlfson.  Without knowing it, you've helped me resolve a number of issues that have arisen in the last few weeks.  A similar set of circumstances for many-a-googler no doubt.  Thanks!

    As for the set of Rulz, I *think* i'm in compliance with them--save of course for 7.1, and the resulting recommendation of 7.8.  Perhaps those are the bullets you were suggesting I follow? :)

    From my (admittedly biased) perspective, the response of "change your NIC" should work its way out of favored lexicon by way of development or troubleshooting.  I understand that Sophos hardware may house Intel hardware so there may exist very limited motivation for perfecting compatibility of non-Intel devices, but adding this to a development roadmap should not be infeasible given the extensive hardware exposure the software platform gets.  Granted the limitation may be due to 3rd party development (open source / kernel inclusions) or lack thereof, but the ability to add such devices to the environment only to have them malfunction is but a tease! 

    All told, it *works*...but the steady redline misfires in the firewall livelog drive me up the wall. :)