Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 38 subscribers
  • Views 901 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

Adding an explicit "allow" rule causes return packets to drop

Nicholas Bethard

I'm trying to set something up where I have a rule for a particular device on my LAN that will reject all traffic from that device to the internet (WAN on my XG), but then be able to define allow rules to sit above it in the rule list so that I can open up certain services. The problem is that even without the "reject" rule in place, the "accept" rule breaks communication! I'm so confused.

With the accept rule enabled, I can see packets go out through the rule in the logs, but nothing comes back. If I disable the accept rule, then communication works fine. What am I doing wrong??

From the log (shows 0 packets received):

Rule list:

Rule configuration:

To test, I'm trying to get to zoom.us from the "VTP White" device. I previously had the source zone set as LAN and destination zone as WAN, but changing them to Any/Any didn't change anything.



This thread was automatically locked due to age.
  • 0

    Hi,

    a couple of points

    1/. you do not need a reject/drop rule the firewall does that if there are no matching allow rules

    2/. depending on your rules whether the packets are dropped in the proxy then there will be shown as allowed but not provide a connection. I believe this is to be fixed in a coming mr release.

    3/. there are occasions I have found that using the device IP address (name) in the allowed network does not work as expected and I have had to change the allowed network to the internal network and use clientless users to manager access to the firewall rules. No errors are  logged, just does not work as expected.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0

    I didn't have a linked NAT rule, so I added that. That seems to have made zoom.us HTTPS work, but the time server NTP still doesn't work (logs show allowed and 1 packet sent, but 0 received).

  • 0 in reply to Nicholas Bethard

    Hi,

    you do not need house linked NAT rules, a simple MASQ will be more than suitable for most cases.

    If you open logviewer and search by destination service (123) what does logviewer show you?

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • +1 in reply to rfcat_vk

    I changed something (not totally sure what) and NTP started working as well. So indeed it seems that lacking a NAT rule (simple MASQ rule) linked to the "allow" firewall rule was causing the problem.

    Prior to adding the linked NAT rule, the logs for a packet going out looked like the snip in my original post (for the zoom.us:443 and time-a.nist.gov:123). Packets sent, but no packets received, and no translated IP. Now everything looks correct in the logs and its all working properly.

Unfiltered HTML