i know that these are newbie questions, but i haven't found them explicitly answered and i want to make sure that i have understood everything correctly.
i have learned that the input and output policies of the lan and the wan zone are intended for data coming to or from the router itself.
i assume that the "regular" network traffic (sending data over the router when browsing the internet with a pc connected to the router) is inspected and secured by openwrt's packet filter (which makes sure only requested packets can travel from the internet over the router and then back to my pc).
so i have three questions:
is the described assumption correct?
is the packet filter enabled by default on all devices?
are the default settings of the packet filter the same on all devices?
You wrote "why LAN traffic successfully goes to WAN ... A rule on WAN that enables masquerade (NAT) on traffic exiting WAN". what rule is that? the default (my) setting for wan is input:reject, output:accept and forward:reject.
one more thing i would like to know is: if i use tor or a vpn on my computer, isn't openwrt's packet filter then unable to inspect the packets?
config forwarding
option dest 'wan'
option src 'lan'
On your computer!?!?
It can see the encrypted packets. It doesn't do DPI anyways, so it cannot "inspect" them (it would need the private key to do so anyways).
So that means you can block the port/IP used to connect to the VPN server.
...Are you under an impression that your firewall isn't working...you need to understand zones...what are you attempting to understand?
ah, okay, i thought you were just referring to the settings of input/output/forward (which i know are only relevant for the traffic coming to or from the router itself, that's why i was confused).
basically i was just attempting to understand if the packet filter works on the traffic i described in the first post and if the settings are the same for all devices. since these assumptions were confirmed to be correct, that's all i want to know so far.
to the tor/vpn situation: in my research about packet-filter firewalls, i have read that (even without deep-packet-inspection), it checks the packets e.g. for ip-addresses to know they have been requested. but as you said, when one uses tor or vpn, openwrt can only see the encrypted packets (from my understanding without ip-addresses or other significant information). so how can openwrt know if a packet has been requested then? sorry, maybe i'm blockheaded right now.
it will then sent that encrypted packet out on the wire to the VPN provider
Your VPN provider will decrypt it and sent the traffic to the Internet
The reply traffic is encrypted by the VPN provider and sent to your client
Hence, your OpenWrt can see traffic going to/from your client to the VPN provider; but it cannot decrypt the packets to see where the traffic is going on the Internet, nor can it see the data inside. This is the concept of what a VPN is.
okay, i see. and since the vpn server should have its own firewall, all should be fine.
how in the case of using tor? i think i have understood their concept: the client encrypts the packet three times, sends it to the entry node (which removes the first encryption layer and sends it to the middle node), middle node removes second encryption layer and sends it to the exit node (which removes the last encryption layer and sends it to the internet). when replies come back, exit node encrypts it once, sends it to the middle node (which encrypts again and sends it to the entry node), entry node encrypts it once again and sends it to the client which decrypts everything.
but wouldn't it be possible that an exit node without good protection (e.g. firewall) receives unrequested and malicious data which in the end reaches the computer the client is running on? without the router's packet filter even noticing it (since it can only see that the packet comes from the entry node and not that it contains unrequested data)?
I think you are not synced with this philosophy, so you think packets are flying on the Internet willy-nilly. Random IPs cannot "hail" an endpoint and make it send unsolicited traffic to a different IP/port pair (it could try to spoof that traffic if the internal traffic leaving the node is ultimately unencrypted, though, e.g. HTTP).
I also think you're missing the concept of the normal packet encapsulated inside the encrypted one. Only the intended endpoint can decrypt traffic. The machine's connection state with the actual decrypted endpoint's IP/ports handles the rest.
Read up on the 3 way handshake and the notion of IP combinations with connection states - you're missing that concept. You're also forgetting that the reply packets must also traverse back through TOR encrypted network to reach you.
