VLAN 1 is the default one, VLAN 100 is for my ISP, VLAN 2 is my new network.
I have 3 interfaces:
LAN_1 is linked to eth0.1 with static IP 192.168.1.1 on network 192.168.1.0 with DHCP server active
LAN_2 is linked to eth0.2 with static IP 192.168.2.1 on network 192.168.2.0 with DHPC server active
WAN_3 is linked eth1.100 with DHCP IP from my ISP.
I have connected two computers to my router: one on LAN 1 and one on LAN 2
The computer A has IP 192.168.1.28
The computer B has IP 192.168.2.53
Now I don't hunderstand why the computer A can ping the computer B, but computer B can't ping the computer A.
Is there a rule related to VLAN id ?
I don't want any possible communication between computer A or B.
I also tried to add both ways static route between networks but computer B can't still ping the computer A.
If the purpose to isolate them then you need to create to zones LAN1 and LAN2, where traffic is allowed from each of them to WAN but traffic between them is blocked.
I'll check the firewall rule and create then assign different rules for the both LAN.
I discussed with a coworker this morning and we think this behavior is because my LAN1 is the default configuration (after hard reset, bridged with radio/wifi initially) there is somewhere a rule not visible in the GUI that allow communication.
So If I delete LAN1 interface and create a new one from scratch (like LAN2) my networks won't exchange the traffic.
After deleting all firewall rules, there is no more link between interfaces.
But I can't get internet anymore. I tried different configuration, allow anything from anywhere between LAN1 and WAN but can't ping google.com from LAN 1.
I don't know what I'm missing, I'll search again and send you my configuration later if I don't found a solution.
On the router in SSH mode I can ping google.com, so link is up and good.
One last strange behaviour. My LAN2 host a webserver.
A added a port forward: From wan port 8888 forward to 192.168.2.100 port 80.
The redirect from my phone in cell network (4G) is good, I can display the web page with my https://ISPIP:8888, but from my local network LAN1 (192.168.1.0) my web browser said ERR_CONNECTION_REFUSED.
So I added a zone rule from lan 1: allow forward to LAN2 in addition to WAN.
Now I can join my LAN2 from my LAN but I don't really like this solution because I use the local adresse 192.168.2.100 to join the web server and not the ISPIP (resolved with a domaine).
A common reason for using DROP rather than REJECT is to avoid giving away information about which ports are open, however, discarding packets gives away exactly as much information as the rejection.
With REJECT, you do your scan and categorise the results into "connection established" and "connection rejected".
With DROP, you categorise the results into "connection established" and "connection timed out".
The most trivial scanner will use the operating system "connect" call and will wait until one connection attempt is completed before starting on the next. This type of scanner will be slowed down considerably by dropping packets. However, if the attack sets a timeout of 5 seconds per connection attempt, it is possible to scan every reserved port (1..1023) on a machine in just 1.5 hours. Scans are always automated, and an attacker doesn't care that the result isn't immediate.
A more sophisticated scanner will send packets itself rather than relying on the operating system's TCP implementation. Such scanners are fast, efficient and indifferent to the choice of REJECT or DROP.
DROP offers no effective barrier to hostile forces but can dramatically slow down applications run by legitimate users. DROP should not normally be used.
I guess you missed that the setting you suggested (i.e. the FORWARD settings) has 0 affect on the OP's listed traffic (i.e. LAN1-to-WAN and LAN2-to-WAN), but OK, I understand your explanation...although I never understood why one would give away their presence on WAN (or use CPUs to do so) by sending rejects to IPs on WAN - when using DROP, a malicious person wouldn't know it's there.
...worse yet, setting REJECT on WAN could even unwittingly make you a participant in a reflection attack from a malicious botnet or device spoofing the SRC IPs...the extra CPUs could possibly (D)DoS your router.
