Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 5985 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

Packets with same from-to and port are not matched by a firewall rule when scan HTTP is selected

BAlfson

Topology: Internet<--><50.x.y.228[MikroTik]192.168.z.9><--><192.168.z.129[XG]

  • The subnet between the XG and the MikroTik is 192.168.z.0/22.
  • Port2 and Port4 are bridged.
  • The connection to the MikroTik is on XG Port2.
  • The connection to all other computers and devices is on XG Port4
  • STAS is not active.

When I Browse from the Internet to 50.x.y.228, my traffic is forwarded to the XG as 192.168.z.57.  The firewall rule passes some of the traffic and the server at .57 responds.  Some of the traffic is dropped by rule 0.  In my browser, I get the XG's dropped ice cream cone "Website not available" message.

Packet capture:

9/20/2018 15:48 Port2 IPv4 50.x.y.110 192.168.z.57 TCP 50333,80 3 Consumed No Policy No Policy
9/20/2018 15:48 Port2 IPv4 50.x.y.110 192.168.z.57 TCP 50333,80 0 Incoming No Policy No Policy
9/20/2018 15:48 Port2 IPv4 50.x.y.110 192.168.z.57 TCP 50333,80 3 Consumed No Policy No Policy
9/20/2018 15:48 Port2 IPv4 50.x.y.110 192.168.z.57 TCP 50333,80 0 Incoming No Policy No Policy

Firewall rule #3:

Why are those packets dropped when I select 'Scan HTTP" in the firewall rule?

Cheers - Bob



This thread was automatically locked due to age.
Parents
  • 0

    Hi Bob,

    i am still kinda confused about this setup.

    Maybe i can help you, if you try to explain how you would setup such an setup in UTM? 

    Because as far as i can see, you need a DNAT Rule instead of Firewall Rule. Like on UTM, you would setup a DNAT rule to the web server instead of using a firewall rule. 

    .57 is XG, so what is the IP of the server? 

    As well as you speak to .57 but does not mention this ip in your overview:

    Topology: Internet<--><50.x.y.228[MikroTik]192.168.z.9><--><192.168.z.129[XG]

     

  • 0 in reply to LuCar Toni

    This bridge is the client's requirement.  It's the reason that no DNAT is needed.  All of the devices and computers are in the /22 subnet on Port4.  The edge router, the MikroTik, is connected on Port2 which is bridged with Port4.

    The DNAT is in the MikroTik - it forwards ports 80 & 443 from 50.x.y.228 to 192.168.z.129.

    Why would every other packet get dropped?  Funny thing, it looks like each packet that's accepted was a duplicate (same sequence #) of the one dropped immediately before it.

    Cheers - Bob

Reply
  • 0 in reply to LuCar Toni

    This bridge is the client's requirement.  It's the reason that no DNAT is needed.  All of the devices and computers are in the /22 subnet on Port4.  The edge router, the MikroTik, is connected on Port2 which is bridged with Port4.

    The DNAT is in the MikroTik - it forwards ports 80 & 443 from 50.x.y.228 to 192.168.z.129.

    Why would every other packet get dropped?  Funny thing, it looks like each packet that's accepted was a duplicate (same sequence #) of the one dropped immediately before it.

    Cheers - Bob

Children
  • +1 in reply to BAlfson

    I am still struggling with the setup.

    This does not make any sense to me. 

     

    So lets wrap up: 

     

    Topology: Internet<--><50.x.y.228[MikroTik] (your Internet Router / NAT Modem?) 

    This Device does what? Just forward to 192.168.z.9 ?  Who is 192.168.z.9 ? Is it the internal IP of the MikroTik? 

    <192.168.z.129[XG] This is the XG IP of the Bridge (br0) ? 

    So i assume 192.168.z.57 is the WebServer? 

     

    So you have one Bridge Port2 and Port4. 

     

    So basically try to use following shell tools to get more insight.

     

    drppkt

    conntrack -E 

    tcpdump 

     

    And post the output of your results. You can use pipe and grep for conntrack and drppkt. 

     

     

    *edit*

    forgot another point to ask: You have a bridge, which zones are involved in this bridge? 

    Also scanning http will enable the http proxy in transparent / standard mode on this policy (traffic). 

    So maybe you should try to build two rules, WAN to LAN without http scanning and LAN to WAN with http scanning. 

  • 0 in reply to LuCar Toni

    Thanks, MBP!

    I got Kent out of Support in Vancouver to dig into this with me.  It took us a bit, but he solved it.

    The secret was that the bridge included WAN and LAN.  When 'Scan HTTP' was selected, the above firewall rule handled inbound browsing requests from the Internet as if it were traffic from an internal client going to the Internet.  This caused the proxy to change the port to 3128.  In Firefox, I opened a new tab, touched [F12], selected the 'Network' tab and browsed to the website.  After the request resulted in a "Website not available" message, I clicked on the image and saw something similar to:

    This change to port 3128 is not documented in the help.

    The solution was indeed to have an earlier rule with 'Scan HTTP' selected for traffic from LAN to WAN - that one would do just what was needed for internal requests going to external web sites or to internal sites from browsers configured to use the Proxy for that.  Rule #3 then was left without 'Scan HTTP' selected.

    I'll work with the client to enable a WAF rule for inbound traffic.

    Cheers - Bob

  • 0 in reply to BAlfson

    The Change to Port 3128 is done by the transparent proxy. Basically this is the mechanism for http scanning.

    Like mention before, if you enable HTTP Scanning, you enable the Transparent proxy.

    Like on UTM. Take a bridge network, put it into the allowed networks of transparent proxy and this will get messy for inbound http traffic. 

  • 0 in reply to LuCar Toni

    Well, Well, Well.  I've discovered a similar packet dropping phenomenon when 'Scan FTP for Malware' is activated for FileZilla requests originating behind the XG going to an external server at 50.mmm.nnn.29.  De-activating the scan resolved the problem.

    Cheers - Bob

  • 0 in reply to BAlfson

    So you enabled WAN to LAN FTP Scanning? 

    This will also break the Proxy (Like on UTM). 

  • 0 in reply to LuCar Toni

    No, this was scanning requests from behind the XG.  The FTP server was out on the Internet.  The same phenomenon occurred - every other packet failed to qualify for the firewall rule.  Are you saying that FTP scanning is incompatible with a bridge on the XG?

    Cheers - Bob

  • 0 in reply to BAlfson

    I am quite sure, this should work, but i do not have such a test setup at the moment. 

    Did you already talked to the support about this?