cross-posted to: https://sh.itjust.works/post/14114583


If the rule is about forwarding traffic from the lan interface to the wan interface, then why is there also a forward rule? How would inputs, and outputs make any sense if the rule is talking about forwarding? What does it mean for wan to forward to REJECT? I interperet that as saying that wan doesn’t go anywhere, but that wouldn’t make sense given that the router can send, and receive over the internet.

For example I would interperet the first rule as follows:

  • lan => wan: the conditions for which connections from the lan interface are forwarded to to the wan interface.
  • Input: accept: the lan interface accepts all connections originating from the network (I wouldn’t understand the point of setting this to be reject).
  • Output: accept: all connections exiting the wan interface are accepted (again, I’m not sure what the point of this would be).
  • Forward: accept: forwarding of packets from lan to wan is allowed.
  • Masquerade: I honestly don’t know what the effect of enabling this would be. What would it mean to masquerade the lan interface?

I tried finding documentation, and I did come across this, and this, but, from what I could understand, they didn’t really answer any of my questions.

  • Matt The Horwood@lemmy.horwood.cloud
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    in short, no I dont know how the firewalling works.

    So a read of the wiki has what I thought

    • INPUT is into the router
    • OUTPUT is from the router
    • FORWARD is across the router

    all as default settings, NAT is applied after the zone rules. So even though the zone will reject INPUT, a NAT rule will allow it.

    Does that help?

    • Kalcifer@sh.itjust.worksOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      10 months ago

      So even though the zone will reject INPUT, a NAT rule will allow it.

      I don’t think this is correct. NAT doesn’t “allow” connections – It just masquerades the source IP as that of the router. For WAN connections to be accepted, conntrack must see them as related to connections that were initiated by the router, or by a device on the LAN (assuming, of course, that conntrack is enabled, which, in my case, it is).