Good thing about finding the issue yourself is that you will never forget about it
It’s not unrelated if the request got there. But this was a config problem.
If that should not be possible at all, you may have to consider hard boundaries between those subnets (firewall rules, dropping DHCP requests coming from the “wrong” interface. That’s one option).
Please make sure, you havent somewhere in your network a cable, bridging your both LANs together.
It could be the case, because the “wrong” DHCP answers sometimes faster as the right DHCP…
/interface list member
add interface=ether1 list=WAN
add interface=bridgeNet1 list=LAN
add interface=bridgeNet2 list=LAN ???
(2) Confused about another part of the setup…
add address=172.16.200.254/24 interface=bridgeNet1 network=172.16.200.0
add address=172.16.172.254/24 interface=bridgeNet1 network=172.16.172.0
add address=172.16.100.254/24 interface=bridgeNet1 network=172.16.100.0
add address=172.16.210.254/24 interface=bridgeNet1 network=172.16.210.0
add address=172.16.215.0/24 interface=bridgeNet2 network=172.16.215.0
Since both bridges already have an IP address I am not sure.
a. if you can add other addresses like this
b. if you can add pptp and the like vpn to bridges as they are not technically complete interfaces …
(3) Your firewall rules are messy and hard to read as you should put all input together and all forward together so its legible and the order of rules seems off as well within a chain.
Not even sure why port 2221 is allowed from anywhere to anywhere in the forward chain…
(4) You source nat and masquerade the hell out of everything is this really required??
(5) You seem to port forward to networks/servers that dont exist… for example 172.16.200.202 has no such subnet or dhcp etc etc…
Clearly there is something I dont understand about how you are using the router…
MT (ROS in particular) is comparable to women in general.
If you think you understand them, they will show you, your knowledge about them is - maybe - 5%…
The MT Switch → VLAN menu (in particular from the CRS1/2xxx) is like my ex-GF Eva. I always though I understand her, but I knew NOTHING…
Both - ROS/VLANs and Eva gave me almost a depression.
Many thanks for taking the time to review my config ! I am still obviously learning Mikrotik and any and all input is much appreciated !
Concretely what good would it do me ? Ie what is the purpose of the WAN and LAN lists… I know a newbee question
a. Well at least in seems to work - what would be the “proper” way to define multiple subnets on a single bridge ?
b. No PPTP involved but OpenVPN - also seems to work as is. What is the proper way to bridge OpenVPN without using bridges ?
Rules where defined in the GUI (winbox) and certainly no “clean”. That said I’m not sure about “all forward together” - in a single rule ?
Rule 10 was to open port 2211 to the external world (so source is indeed “anywhere”) and valid for all my public IP (so destinatin is indeed “any”). Is there a cleaner way to do this ?
I understand that I have to masquerade for all subnets so that they can reach out ? And sourcenat all IPsec site to site subnets ? Again if there is a cleaner / better way to do this I’m happy to learn !
Hmm there is a sunet 172.16.200.0/24 (see point 2 first entry) and a server at 202.
Again gratefull for any advice / suggestion to improve my config.
Every interface can be part of an interface list. The most common used are LAN and WAN. You can make others if you want.
Default firewall rules are mostly based on allowing traffic from LAN and blocking stuff from WAN.
If you got an interface without label, it’s certainly not LAN hence it might be blocked which might not be what you want.
At least give that interface a proper label so there is no misunderstanding on what it is supposed to do.
On the ordering of firewall rules:
it is not NEEDED but it makes it a lot easier when others need to review your rules.
Or for yourself when you look at it again some weeks or months from now when you want to change something and are not in the current mind set anymore (now you may have a lot of the things clear in your head, I assure you some time from now it will evaporate).
Just best practice.
3 chains:
Input
Forward
Output
Put your rules together within the chain PRESERVING the current order.
Everything from Input together.
Everything from Forward together.
Everything from Output together.
Example from rules on my mAP device:
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="accept from local network (Lab Environment)" src-address=192.168.2.0/24
add action=drop chain=input comment="drop all coming from WAN" in-interface-list=WAN
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=\
new in-interface-list=WAN
I dont think its possible or wise to attach your VPN connections to bridges.
Simply make the firewall rules you need to allow connectivity from VPN access to LAN subnets and vice versa etc…
I think of VPNs a faux LANs, they are not real LANs but are parallel to them.
A VPN is a tunnel that with an entry/exit at the LAN level but is not a LAN subnet.
Seems like you have many tunnels.
So use firewall rules for VPN tunnel to LAN connectivity
So use firewall rules for VPN tunnel to VPN Tunnel connectivity (BUT I DO NOT KNOW if this is even possible/legal).
If the VPN tunnels require access to the Routers Internet then you need to ensure there is a route back to the right tunnel for that traffic
(
