Yup -- that "accept established / related " rule lets "requested for" traffic through.
Here's a diagram of the router's logic / featureset
Image may be NSFW.
Clik here to view.
Let's say the cloud on the left is your local LAN, and the cloud on the right is the internet for now (note too that I'm assuming the ER is your main / edge router, and treating things accordingly). Hope this isn't too mind bending for you Image may be NSFW.
Clik here to view.
Scenario: Host A (192.168.1.101) on your LAN (eth1) wants to go to google's DNS server (8.8.8.8) (wan on eth0)
1. packet comes in from "left cloud", hits DNAT check. NO DNAT NEEDED
2. packet moves up to routing engine, which checks if the packet's destined for the router (it's not)
3. routing engine passes to the eth1_IN firewall.
- check rule 1 --> NOT destined for "local LANs"
- fall thru to default --> okay, allow it through
4. eth1_in firewall passes to eth0_out
- there is no eth0_out defined, default action in this case is "accept"
5. Check SNAT --> NO SNAT NEEDED
And for the response -- NOTE THIS FLIPS THE DIAGRAM -- LEFT IS NOW WAN / RIGHT IS LAN
Scenario: Google DNS (8.8.8.8) (eth0) responding to HostA (192.168.1.101)
1. packet comes in from "left cloud" (WAN) hits DNAT Check. DNAT from WAN_IP_ADDRESS to 192.168.1.101. Router knows to do this, because it's keeping track of outbound connection requests and where they're going to.
2. packet moves up to routing engine, which checks if the packet's destined for the router (it's not)
3. routing engine passes to the eth0_IN firewall.
- check rule 1 --> Yep, ESTABLISHED DNS request from HostA. Accept the packet
4. eth0_in firewall passes to eth1_out
- there is no eth1_out defined, default action in this case is "accept"
5. Check SNAT for packets leaving eth1 - Nothing defined. Send to host A
