Port forwarding problem on VLAN

simonefil · Wed Dec 08, 2021 8:20 pm

Goodmorning everyone.
In my SOHO network I am using an RB3011UiAS device with ROS 6.48.2 installed.
I have a bridge in which there are many subnets, a "main" 192.168.3.0/24 and a VLAN400 172.16.10.0/24. Some ports are untagged and some tagged in VLAN400.
I have two Synology NAS. The first is connected to an untagged port with IP 192.168.3.173, while the second is connected to a port tagged in VLAN400 with IP 172.16.10.5.
Using this firewall rule I allow all devices on subnet 172.16.10.0/24 to communicate only with the IP of the synology NAS on subnet 192.168.3.0/24.

add action=drop chain=forward comment="Drop all from vlan 400 except IP NAS" dst-address=!192.168.3.173 in-interface="vlan 400"

Using this other firewall rule, I allow all devices on subnet 192.168.3.0/24 to reach devices 172.16.10.0/24 (for maintenance).

add action=accept chain=forward comment="Accept request from lan master to vlan NAS Synology Backup" dst-address=172.16.10.0/24 src-address=192.168.3.0/24

Through this NAT rule I can reach the NAS of the subnet 192.168.3.0/24 from the outside using my Public IP and dedicated port.

add action=dst-nat chain=dstnat comment="NAS Management WAN" dst-address-type="" dst-port=5050 protocol=tcp to-addresses=192.168.3.173 to-ports=5050

Well, I would like to do the same thing to reach the NAS of subnet 172.16.10.0/24 as well, but applying this rule doesn't work.
What am I doing wrong?
Complete config:

[simone@Routerboard] > export
# dec/08/2021 19:08:37 by RouterOS 6.48.2
# software id = 
#
# model = RouterBOARD 3011UiAS
# serial number = B8********
/interface bridge
add arp=proxy-arp comment="LAN untagged + VLAN" name=bridge1 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether9 ] comment=FASTWEB
set [ find default-name=ether10 ] comment="FIBRA 200"
/interface vlan
add arp=proxy-arp comment="vlan Synology NAS Backup" interface=bridge1 name="vlan 400" vlan-id=400
add comment="vlan C***** L******" interface=bridge1 name="vlan 410" vlan-id=410
add comment="vlan G****** WiFi" interface=bridge1 name=vlan100 vlan-id=100
add comment="vlan service" interface=bridge1 name=vlan200 vlan-id=200
add arp=proxy-arp comment="vlan Simone" interface=bridge1 name=vlan300 vlan-id=300
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp_pool0 ranges=192.168.3.101-192.168.3.149
add name=dhcp_pool1 ranges=192.168.1.100-192.168.1.200
add name=dhcp_pool2 ranges=192.168.2.100-192.168.2.200
add name=dhcp_pool3 ranges=192.168.5.100-192.168.5.200
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=bridge1 name=dhcp-master
add address-pool=dhcp_pool1 disabled=no interface=vlan100 name=dhcp-g******
add address-pool=dhcp_pool2 disabled=no interface=vlan200 name=dhcp-service
add address-pool=dhcp_pool3 disabled=no interface=vlan300 name=dhcp-simone

/interface bridge port
add bridge=bridge1 interface=ether1 multicast-router=disabled
add bridge=bridge1 interface=ether2 multicast-router=disabled
add bridge=bridge1 interface=ether3 multicast-router=disabled
add bridge=bridge1 interface=ether4 multicast-router=disabled
add bridge=bridge1 interface=ether5 multicast-router=disabled
add bridge=bridge1 interface=sfp1 multicast-router=disabled
/ip settings
set allow-fast-path=no
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether1,ether2,ether3,ether4,ether5,sfp1 vlan-ids=100,200,300,400,410
/ip address
add address=192.168.3.75/24 interface=bridge1 network=192.168.3.0
add address=192.168.1.1/24 interface=vlan100 network=192.168.1.0
add address=192.168.2.1/24 interface=vlan200 network=192.168.2.0
add address=192.168.5.1/24 interface=vlan300 network=192.168.5.0
add address=192.168.50.200/24 comment="Fastweb ADSL" interface=ether9 network=192.168.50.0
add address=192.168.100.100/24 comment="FIBRA 200" interface=ether10 network=192.168.100.0
add address=172.16.10.1/24 interface="vlan 400" network=172.16.10.0
add address=172.16.20.1/28 interface="vlan 410" network=172.16.20.0
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.1.1
add address=192.168.2.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.2.1
add address=192.168.3.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.3.75
add address=192.168.5.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.5.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip firewall address-list
add address=192.168.1.0/24 list="Subnet"
add address=172.16.10.0/24 list="Subnet"
add address=192.168.2.0/24 list="Subnet"
add address=172.16.20.0/28 list="Subnet"
/ip firewall filter
add action=accept chain=forward comment="Consenti inoltro per connessioni stabilite e correlate" connection-state=!related,new
add action=accept chain=input comment="Consenti richieste ICMP" protocol=icmp
add action=accept chain=input disabled=yes dst-port=1723 in-interface=ether10 protocol=tcp
add action=accept chain=forward comment="Accept request from lan master to vlan NAS Synology Backup" dst-address=172.16.10.0/24 src-address=192.168.3.0/24
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=34w6d chain=input comment="Port scanners to list " fragment=no hotspot="" protocol=tcp psd=21,3s,3,1
add action=drop chain=input comment="Drop richieste DNS esterne TCP" dst-port=53 in-interface=ether10 protocol=tcp
add action=drop chain=input comment="Drop richieste DNS esterne UDP" dst-port=53 in-interface=ether10 protocol=udp
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether10
add action=drop chain=forward comment="Drop to bogon list" dst-address-list=Bogons
add action=drop chain=input comment="Regola Drop accesso WinBox" dst-port=8291 protocol=tcp src-address-list="!Subnet"
add action=drop chain=input protocol=tcp src-address-list="port scanners"
add action=drop chain=input comment="Drop Invalid Connections" connection-state=invalid
add action=drop chain=forward comment="Drop all from vlan 400 except IP NAS" dst-address=!192.168.3.173 in-interface="vlan 400"
add action=drop chain=input comment="Drop tutto il resto"
/ip firewall nat
add action=masquerade chain=srcnat comment="Masquerade FIBRA 200" out-interface=ether10
add action=masquerade chain=srcnat comment="Masquerade Fastweb" out-interface=ether9
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=!192.168.3.75 src-address=192.168.3.0/24
add action=dst-nat chain=dstnat comment="NAS Management WAN" dst-address-type="" dst-port=5050 protocol=tcp to-addresses=192.168.3.173 to-ports=5050
/ip route
add comment=FIBRA distance=10 gateway=192.168.100.1
add comment=ADSL distance=30 gateway=192.168.50.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes port=17800
set ssh disabled=yes
set www-ssl certificate=ca disabled=no port=17801
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-name=Europe/Rome
/system identity
set name="Routerboard"
/system package update
set channel=long-term

Thank you very much for your help

Sob · Wed Dec 08, 2021 9:59 pm

That's one horrible firewall. For example, why do you bother with port scanners in input chain, when you'd drop those connections anyway? Same for connection-state=invalid, the next rule drops them too.

As for your problem with port forwarding, if I take rules in forward chain:

#1 - allow packets with connection state not related or new, i.e. those with connection state established, untracked or invalid
#2 - allow everything from 192.168.3.0/24 to 172.16.10.0/24
#3 - drop new connections from ether10 if they are not dstnatted
#4 - drop if destination is in Bogons list (if such list exists and you just removed it from export)
#5 - drop anything from vlan 400, if it's not to 192.168.3.173
#x - allow everything else (default behaviour)

So:

#1 - usually you want to simply allow established, related and untracked
#2 - completely useleless, unless your Bogons list contains 172.16.10.0/24
#3 - this one is ok, but don't you want the same for ether9, which looks like another WAN?
#4 - depends on what's in Bogons list
#5 - at first sight your prime suspect, because response from 172.16.10.x to port-forwarded connection will match dst-address=!192.168.3.173; but on second look, it will be established, so #1 should allow it

anav · Wed Dec 08, 2021 11:08 pm

As Sob noted, your use of youtube and other sources for firewall rules have misguided you and are actually preventing traffic flow you need.
Best to reset to defaults and then add rules your really need........

(1) Missing dhcp server for MAIN (another bleeping op who uses Bridge for DHCP and subnet vice simply another vlan - argggggg )
You screwed up your DHCP services for example you have vlanX00 set to use pool3 etc............

ALL NEED TO BE FIXED, IP POOLS, IP ADDRESSES, DHCP SERVER AND DHCP-SERVER NETWORK.
Many missing entries!!

Its easy when I do it, because I dont mix and match shit.
you have six subnets thus
6 of everything!!! ( in your case 5 vlans and one bridge)

as for firewall rules.........
Suggest....... as a starting point!!

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 {disable if not required}
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \ {disable if not required}
connection-state=new in-interface-list=WAN
add action=drop chain=forward

Then..........

The biggest problem is the lack of a proper firewall, the rest can wait.
Suggest.......
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 {disable if not required}
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=LAN out-interface-list=WAN

add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400

add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=forward

LETS cover port forwarding.
SOURCENAT.
I take it you have users on the MAIN subnet, that need to access the NAS but for some strange reason they are not allowed to use the LANIP of the server and you make them use the WANIP or dyndns URL?? Assuming this is why the hairpin nat rule......
Well the proper format for the hairpin nat rule is as follows:
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=192.168.3.0/24 src-address=192.168.3.0/24

DSTNAT
You are missing info............... one can use dst-address=WANIP and if dst-port is same as to-port, you dont need to put in to-port.
add action=dst-nat chain=dstnat comment="NAS Management WAN" dst-address=WANIP dst-port=5050 protocol=tcp to-addresses=192.168.3.173

However, if the wanip is dynamic.....................
you need to read this........
viewtopic.php?t=179343
skip to 1. B. ii or iii options. (ii probably the quickest to understand and implement).

Also missing interface list and interface list members.
Each vlan needs to be listed as per LAN
as well as the bridge......

simonefil · Fri Dec 10, 2021 5:10 pm

As Sob noted, your use of youtube and other sources for firewall rules have misguided you and are actually preventing traffic flow you need.
Best to reset to defaults and then add rules your really need........

(1) Missing dhcp server for MAIN (another bleeping op who uses Bridge for DHCP and subnet vice simply another vlan - argggggg )
You screwed up your DHCP services for example you have vlanX00 set to use pool3 etc............

ALL NEED TO BE FIXED, IP POOLS, IP ADDRESSES, DHCP SERVER AND DHCP-SERVER NETWORK.
Many missing entries!!

Its easy when I do it, because I dont mix and match shit.
you have six subnets thus
6 of everything!!! ( in your case 5 vlans and one bridge)

as for firewall rules.........
Suggest....... as a starting point!!

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 {disable if not required}
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \ {disable if not required}
connection-state=new in-interface-list=WAN
add action=drop chain=forward

Then..........

The biggest problem is the lack of a proper firewall, the rest can wait.
Suggest.......
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 {disable if not required}
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=LAN out-interface-list=WAN

add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400

add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=forward

LETS cover port forwarding.
SOURCENAT.
I take it you have users on the MAIN subnet, that need to access the NAS but for some strange reason they are not allowed to use the LANIP of the server and you make them use the WANIP or dyndns URL?? Assuming this is why the hairpin nat rule......
Well the proper format for the hairpin nat rule is as follows:
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=192.168.3.0/24 src-address=192.168.3.0/24

DSTNAT
You are missing info............... one can use dst-address=WANIP and if dst-port is same as to-port, you dont need to put in to-port.
add action=dst-nat chain=dstnat comment="NAS Management WAN" dst-address=WANIP dst-port=5050 protocol=tcp to-addresses=192.168.3.173

However, if the wanip is dynamic.....................
you need to read this........
viewtopic.php?t=179343
skip to 1. B. ii or iii options. (ii probably the quickest to understand and implement).

Also missing interface list and interface list members.
Each vlan needs to be listed as per LAN
as well as the bridge......

Hello.
Thank you very much for your help, unfortunately I knew my firewall was not doing very well. Now I'm preparing a new list of firewall rules based on your rules and adding the ones I need.
In the meantime I managed to solve the remote access problem on the NAS from vlan. trivially this rule dropped the subnet.

add address=169.254.0.0/16 comment="Link Local [RFC 3330]" list=Bogons

I deleted the subnet from the bogon list and now it works.
Now I would like to try a next step. I have a NAS in another location, I have set up an L2TP / ipsec VPN on the mikrotik in question

/interface l2tp-server server
set authentication=mschap2 default-profile=L2TP_IPsec_VLAN400 enabled=yes \
    ipsec-secret="*****" \
    one-session-per-host=yes use-ipsec=yes 
    /ppp profile
add local-address=172.16.10.1 name=L2TP_IPsec_VLAN400

and the ad hoc profile for that nas is configured:

/ppp secret
add local-address=172.16.10.1 name=naspippo password=\
    "******" profile=L2TP_IPsec_VLAN400 remote-address=\
    172.16.10.7 service=l2tp

Everything works perfectly, in fact from my local PC by typing the IP 172.16.10.7:5001 I reach the login page of the remote NAS perfectly. Now, again I would like to reach the login page of the remote NAS using my public WAN IP and a dedicated port, but using this rule:

add action=dst-nat chain=dstnat comment="NAS Pippo Management WAN" dst-address-type="" dst-port=5057 hotspot="" protocol=tcp to-addresses=172.16.10.7 to-ports=5001

it doesn't work, even though it is in the same subnet as the other NAS. NAS 172.16.10.7 reach perfectly NAS 192.168.3.173.
Don't take me for a fool, I currently don't really need this setup to work, but I might need it soon (for remote backups) and I'd like to be prepared already.
Thank you very much for your help

Sob · Fri Dec 10, 2021 7:07 pm

It's because remote NAS probably doesn't use VPN connection as gateway. So if I'd connect to it using your public address, dstnat would forward initial packet to NAS correctly, but NAS would still see my original IP address, so it would send response directly to me via its default gateway. And that can't work.

Simple fix is to add srcnat rule that will make all connections look as if they come from your end of VPN tunnel. This way, responses will be sent back via VPN, and it will work. But what fixes it is also the main problem of this solution, NAS won't be able to tell clients apart.

If that's a problem, better solution, where original addresses can be kept, does exist. But it depends on VPN client. If it's NAS itself, it probably can't do it. But if it's remote router with RouterOS (or similarly capable OS), it's possible.

simonefil · Sat Dec 11, 2021 12:38 pm

It's because remote NAS probably doesn't use VPN connection as gateway. So if I'd connect to it using your public address, dstnat would forward initial packet to NAS correctly, but NAS would still see my original IP address, so it would send response directly to me via its default gateway. And that can't work.

Simple fix is to add srcnat rule that will make all connections look as if they come from your end of VPN tunnel. This way, responses will be sent back via VPN, and it will work. But what fixes it is also the main problem of this solution, NAS won't be able to tell clients apart.

If that's a problem, better solution, where original addresses can be kept, does exist. But it depends on VPN client. If it's NAS itself, it probably can't do it. But if it's remote router with RouterOS (or similarly capable OS), it's possible.

Hi Sob.
Thank you for your answer, very clear and simple to understand. The srcnat rule that will make all connections look like they come from the end of the VPN tunnel will no longer allow me to access the NAS from local PCs within the LAN right? This is a problem, as both local PCs and myself (via VPN) access the NAS. Currently the NAS is connected to a trivial FritzBox, so I don't think it is possible to create a rule for keeping the original addresses, but in the future I could remove it and install a Mikrotik and install the VPN client on it. In this case, how can I do to keep the original addresses? A srcnat? Or tagging connections using Mangle?
Thank you for your time
Have a good day

Sob · Sat Dec 11, 2021 1:14 pm

It doesn't break anything. If you add it with only out-interface=<to vpn client>, it will affect also connections from LAN, but you can exclude those with src-address=!<LAN subnet> ("!" is "not").

The other way is same as multi-WAN port forwarding, so add new routing table with default route via VPN, mark new incoming connections from VPN, and finally mark routing for outgoing packets of these marked connections, to use the new routing table and VPN as gateway as a result.

simonefil · Sat Dec 11, 2021 1:27 pm

It doesn't break anything. If you add it with only out-interface=<to vpn client>, it will affect also connections from LAN, but you can exclude those with src-address=!<LAN subnet> ("!" is "not").

The other way is same as multi-WAN port forwarding, so add new routing table with default route via VPN, mark new incoming connections from VPN, and finally mark routing for outgoing packets of these marked connections, to use the new routing table and VPN as gateway as a result.

Ok, I think it's all pretty clear to me.
I don't think the first way you suggested to me is viable now, because I can't create out-interface and src-address rules on the NAS (which now sets up the VPN) so I think I'll follow the second way, it seems more functional. I will do a test in the next few days. I dust off my test SXT LTE, insert a SIM, configure an L2TP / IPsec VPN (like the one established on the NAS now) and create the rules for multi-WAN port Forwarding. I'll give you feedback as soon as I've tried. Thank you very much for your help.

Sob · Sat Dec 11, 2021 2:05 pm

No, the first way is what you do on VPN server, i.e. your router. If you don't have interface for client, you can add it:

/interface l2tp-server add name=<interface name> user=<user name>

Or you can replace out-interface with dst-address=<remote NAS address>.

simonefil · Sat Dec 11, 2021 2:42 pm

No, the first way is what you do on VPN server, i.e. your router. If you don't have interface for client, you can add it:
Code: Select all
/interface l2tp-server add name=<interface name> user=<user name>
Or you can replace out-interface with dst-address=<remote NAS address>.

oh ok, I apply the rule on my mikrotik VPN server. Let's see if I understand correctly. I insert a rule like this:

/ip firewall nat
add action=masquerade chain=srcnat dst-address=172.16.10.7 src-address-list="!Mikrotik Subnet"
/ip firewall address-list
add address=***.***.****.*** list="Mikrotik Subnet" (my WAN IP)
add address=192.168.3.0/24 list="Mikrotik Subnet"
add address=192.168.5.0/24 list="Mikrotik Subnet"
add address=192.168.1.0/24 list="Mikrotik Subnet"
add address=172.16.10.0/24 list="Mikrotik Subnet"
add address=192.168.2.0/24 list="Mikrotik Subnet"
add address=172.16.20.0/28 list="Mikrotik Subnet"

Is the srcnat rule correct? Do I leave my WAN IP in the address list or is it better to remove it?
Forgive me if I wrote some bullshit.
Thanks again for your help

Sob · Sat Dec 11, 2021 2:48 pm

The list is simply to what source subnets the rule shouldn't apply to. You don't want WAN IP in there. It probably doesn't matter, because it's unlikely that router itself would be connecting to NAS at all, and on top of that with source set to its WAN IP. But if it actually attempted to, it wouldn't work, because it would be the same problem as before.

simonefil · Sat Dec 11, 2021 2:58 pm

The list is simply to what source subnets the rule shouldn't apply to. You don't want WAN IP in there. It probably doesn't matter, because it's unlikely that router itself would be connecting to NAS at all, and on top of that with source set to its WAN IP. But if it actually attempted to, it wouldn't work, because it would be the same problem as before.

It worksss

With the srcnat rule above and the dstnat rule I can now reach my remote server connected in VPN via my WAN IP. Thank you so much! I would never have succeeded without your help.
Thank you very much
A good day

simonefil · Tue Dec 21, 2021 6:41 pm

As Sob noted, your use of youtube and other sources for firewall rules have misguided you and are actually preventing traffic flow you need.
Best to reset to defaults and then add rules your really need........

(1) Missing dhcp server for MAIN (another bleeping op who uses Bridge for DHCP and subnet vice simply another vlan - argggggg )
You screwed up your DHCP services for example you have vlanX00 set to use pool3 etc............

ALL NEED TO BE FIXED, IP POOLS, IP ADDRESSES, DHCP SERVER AND DHCP-SERVER NETWORK.
Many missing entries!!

Its easy when I do it, because I dont mix and match shit.
you have six subnets thus
6 of everything!!! ( in your case 5 vlans and one bridge)

as for firewall rules.........
Suggest....... as a starting point!!

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 {disable if not required}
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \ {disable if not required}
connection-state=new in-interface-list=WAN
add action=drop chain=forward

Then..........

The biggest problem is the lack of a proper firewall, the rest can wait.
Suggest.......
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 {disable if not required}
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=LAN out-interface-list=WAN

add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400

add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=forward

LETS cover port forwarding.
SOURCENAT.
I take it you have users on the MAIN subnet, that need to access the NAS but for some strange reason they are not allowed to use the LANIP of the server and you make them use the WANIP or dyndns URL?? Assuming this is why the hairpin nat rule......
Well the proper format for the hairpin nat rule is as follows:
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=192.168.3.0/24 src-address=192.168.3.0/24

DSTNAT
You are missing info............... one can use dst-address=WANIP and if dst-port is same as to-port, you dont need to put in to-port.
add action=dst-nat chain=dstnat comment="NAS Management WAN" dst-address=WANIP dst-port=5050 protocol=tcp to-addresses=192.168.3.173

However, if the wanip is dynamic.....................
you need to read this........
viewtopic.php?t=179343
skip to 1. B. ii or iii options. (ii probably the quickest to understand and implement).

Also missing interface list and interface list members.
Each vlan needs to be listed as per LAN
as well as the bridge......

765 / 5.000
Risultati della traduzione
I'm back. I took some time to review my firewall rules. This is a draft that I have prepared, I would like to have your opinion.

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 in-interface-list=LAN
add action=accept chain=input comment="Accept requests from private subnets to the Fiber WAN" in-interface=!ether10 src-address-list="Simone Subnet"
add action=accept chain=input comment="Accept requests from private subnets to the ADSL WAN" in-interface=!ether9 src-address-list="Simone Subnet"
add action=drop chain=input comment="Drop Rule WinBox" dst-port=8291 protocol=tcp src-address-list="!Simone Subnet"
add action=drop chain=input comment="Drop DNS requests from WAN TCP" dst-port=53 in-interface=ether10 protocol=tcp
add action=drop chain=input comment="Drop DNS requests from WAN UDP" dst-port=53 in-interface=ether10 protocol=udp
add action=drop chain=input
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \ {disable if not required}
connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="Drop to bogon list" dst-address-list=Bogons
add action=drop chain=forward

add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400

add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=forward

add action=drop chain=output comment="drop OpenDNS1 su WAN2" dst-address=208.67.222.222 out-interface=ether9
add action=drop chain=output comment="drop OpenDNS2 su WAN1" dst-address=208.67.220.220 out-interface=ether10

I have a second problem now. The routerboard, with these rules, is unable to communicate externally, let me explain, by going to /system /packages and pressing on "ceck for update" the system returns me: "ERROR: could not resolve DNS name" same thing for the mail in output, fails to send them.
By disabling the

add action = drop chain = input

rule, the services start working perfectly again, but as soon as I re-enable it, they no longer work. I think I need to add an input rule intended for the routerboard, but I don't know how to identify the "routerboard". Can you give me a suggestion? Thank you

anav · Tue Dec 21, 2021 7:06 pm

What I understand and looks good.

input chain (this is the minimum almost default which is good to go and will allow access to the router from the LAN and drop everything else).

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 in-interface-list=LAN
add action=drop chain=input

What I dont understand: Are the funky rules in the mix...........
Because it almost looks like you are trying to allow internet access on the input chain which is wrong.
Input chain is for traffic TO the router Wan to router, LAN to router.
Forward chain traffic on the other hand is for traffic through the router, WAN to LAN, LAN to LAN, LAN to WAN.
No need to drop winbox, the last rule already drops all traffic.
No need to drop DNS, the last rule already drops traffic.

REMOVE THESE
add action=accept chain=input comment="Accept requests from private subnets to the Fiber WAN" in-interface=!ether10 src-address-list="Simone Subnet"
add action=accept chain=input comment="Accept requests from private subnets to the ADSL WAN" in-interface=!ether9 src-address-list="Simone Subnet"
add action=drop chain=input comment="Drop Rule WinBox" dst-port=8291 protocol=tcp src-address-list="!Simone Subnet"
add action=drop chain=input comment="Drop DNS requests from WAN TCP" dst-port=53 in-interface=ether10 protocol=tcp
add action=drop chain=input comment="Drop DNS requests from WAN UDP" dst-port=53 in-interface=ether10 protocol=udp

If you did have a VPN tunnel to the router, and you wanted to be able to configure the router remotely through the tunnel.
A. you would have an input rule for the initial connection of VPN via the typical VPN ports or a random wireguard port.
B. you would ensure that the there was an input chain rule that allowed the vpn interface access to the router

Now if you want to take the GOOD shortNsweet input chain rule above and LIMIT who all has access to the router that would be a good thing!!
In other words, only the ADMIN not everyone on the LAN needs FULL access to the router.
The rest of the users simply need DNS access for the most part (also NTP if running an NTP server for devices down the line).
So the rules would look like this.

Step1: DISABLE the block all rule at the end, so you dont lock yourself out
make the changes Ive noted above........

Step2: Create a firewall address list named: authorized , from dhcp leases set to be static/fixed, such that

add IP=IP of admin desktop list=authorized
add IP=IP of admin laptop list=authorized
add IP=IP of admin smartphone list=authorized
etc.........

Step3: Modify this rule after to look like.
add action=accept chain=input in-interface-list=LAN src-address-list=authorized

Step4: add the DNS rules to allow LAN users to access DNS services on the router.
add action=accept chain=input dst-port=53 in-interface-list=WAN protocol=tcp
add action=accept chain=input dst-port=53 in-interface-list=WAN protocol=udp

Step5: ENABLE the block all rule at the end.

anav · Tue Dec 21, 2021 7:08 pm

Now lets look at the forward chain...............

No real issues until we hit the port forwarding rule.
Remove the text I had added as explanation {disable if not required}
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \ {disable if not required}
connection-state=new in-interface-list=WAN
It is not part of the configuration LOL.

The other point is, what is your purpose of the BOGON rule?
Is it to prevent LAN users from attempting to connect to private IPs that are not on the subnet?
Is it to prevent LAN user from attempting to connect to private IPs via the WAN
Is it to prevent private IP addresses from leaking out the WAN?

If you look at its placement, all the LAN to WAN traffic has already been matched and thus would never see this rule.
With Vlans (L2) and block all else in effect (L3) no traffic is being passed between subnets......
One is not preventing L2 traffic between same subnet users.

In other words for now I would simply remove the bogon rule.
A more elegant way to achieve the same is via some iP routes. However, since you do not understand what these rules are doing at the moment its best not to use them

/ip route
add dst-address=10.0.0.0/8 type=unreachable
add dst-address=172.16.0.0/12 type=unreachable
add dst-address=192.168.0.0/16 type=unreachable

note in version 7 firmware unreachable is not available and thus one needs to use the checkbox of blackhole.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Then we get to these rules WHICH HAVE ZERO AFFECT because order counts within a chain,
what do you notice that is above these rules................ ??
Correct this very good rule! I have added a comment to drill this rule home.
add action=drop chain=forward comment="drop all else"

In other words, the router doesnt ever look at them.
So they have to be placed appropriately.
I have no clue of what you are doing with OPENDNS................... but suggest you tell us what you want to occur and we can figure out what makes sense!!!

PLACE BEFORE THE DROP RULE ABOVE
add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400

DUPLICATE REMOVE
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=forward

REMOVE FOR NOW
add action=drop chain=output comment="drop OpenDNS1 su WAN2" dst-address=208.67.222.222 out-interface=ether9
add action=drop chain=output comment="drop OpenDNS2 su WAN1" dst-address=208.67.220.220 out-interface=ether10

simonefil · Thu Dec 23, 2021 8:13 pm

Now lets look at the forward chain...............

No real issues until we hit the port forwarding rule.
Remove the text I had added as explanation {disable if not required}
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \ {disable if not required}
connection-state=new in-interface-list=WAN
It is not part of the configuration LOL.

The other point is, what is your purpose of the BOGON rule?
Is it to prevent LAN users from attempting to connect to private IPs that are not on the subnet?
Is it to prevent LAN user from attempting to connect to private IPs via the WAN
Is it to prevent private IP addresses from leaking out the WAN?

If you look at its placement, all the LAN to WAN traffic has already been matched and thus would never see this rule.
With Vlans (L2) and block all else in effect (L3) no traffic is being passed between subnets......
One is not preventing L2 traffic between same subnet users.

In other words for now I would simply remove the bogon rule.
A more elegant way to achieve the same is via some iP routes. However, since you do not understand what these rules are doing at the moment its best not to use them

/ip route
add dst-address=10.0.0.0/8 type=unreachable
add dst-address=172.16.0.0/12 type=unreachable
add dst-address=192.168.0.0/16 type=unreachable

note in version 7 firmware unreachable is not available and thus one needs to use the checkbox of blackhole.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Then we get to these rules WHICH HAVE ZERO AFFECT because order counts within a chain,
what do you notice that is above these rules................ ??
Correct this very good rule! I have added a comment to drill this rule home.
add action=drop chain=forward comment="drop all else"

In other words, the router doesnt ever look at them.
So they have to be placed appropriately.
I have no clue of what you are doing with OPENDNS................... but suggest you tell us what you want to occur and we can figure out what makes sense!!!

PLACE BEFORE THE DROP RULE ABOVE
add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400

DUPLICATE REMOVE
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=forward

REMOVE FOR NOW
add action=drop chain=output comment="drop OpenDNS1 su WAN2" dst-address=208.67.222.222 out-interface=ether9
add action=drop chain=output comment="drop OpenDNS2 su WAN1" dst-address=208.67.220.220 out-interface=ether10

Thanks so much for all your advice. I finished completely overhauling my firewall by also adding some remaining rules that I hadn't entered before (I wanted to sort out the main ones)
1) I have deleted the drop input rules recommended by you
2) I have a l2tp server, so I have inserted some rules
3) The router and all subnets are under my control, at the moment I don't need to restrict access to the router
4) I removed the port forwarding rule
5) I have completely removed the bogons (actually they are not needed)
6) I need the OpenDNS rules for netwatch. Every 30 seconds ping one OpenDNS server with one connection and the other server with the other connection. In the event of a connection down, it disables the related route
7) I need the latest forward rules to prevent certain subnets from communicating with others, I think they can be improved

ip firewall filter
add action=drop chain=input comment="Block wrong IPSEC requests" protocol=udp src-address-list=IPSEC_blacklist
add action=drop chain=input protocol=tcp src-address-list=IPSEC_blacklist
add action=drop chain=input comment="Block Port Scanners" protocol=tcp src-address-list="port scanners"
add action=drop chain=input protocol=udp src-address-list="port scanners"


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 in-interface-list=Simone Subnet
add action=accept chain=input comment="Accetta richieste Webfig Mikrotik" dst-port=17801 in-interface=ether10 protocol=tcp
add action=accept chain=input comment="Regola di accesso protocollo L2TP IPsec" in-interface=ether10 protocol=ipsec-esp
add action=accept chain=input comment="Regola di accesso porte per L2TP IPsec" dst-port=500,1701,4500 in-interface=ether10 protocol=udp
add action=drop chain=input

add action=add-src-to-address-list address-list="port scanners" address-list-timeout=none-dynamic chain=input comment="Port scanners to list " fragment=no hotspot="" protocol=tcp psd=21,3s,3,1
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=Simone Subnet out-interface-list=WAN interfaces
add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400
add action=accept chain=forward comment="Internet Access Fiber Cristina" in-interface="vlan 410" out-interface=ether10
add action=accept chain=forward comment="Internet Access ADSL Cristina" in-interface="vlan 410" out-interface=ether9
add action=accept chain=forward comment=Accept request from lan master to vlan NAS Synology Backup" dst-address=172.16.10.0/24 src-address=192.168.3.0/24
add action=drop chain=forward comment="Drop all from vlan 410 except to WAN1" out-interface=!ether10 src-address=172.16.20.0/28
add action=drop chain=forward comment="Drop request from vlan graziano to lan master" dst-address=192.168.3.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan graziano to vlan Simone" dst-address=192.168.5.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan graziano to vlan Service" dst-address=192.168.2.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan service to lan Master" dst-address=192.168.3.0/24 src-address=192.168.2.0/24
add action=drop chain=forward comment="Drop request from vlan service to vlan Simone" dst-address=192.168.5.0/24 src-address=192.168.2.0/24
add action=drop chain=forward

add action=drop chain=output comment="drop OpenDNS1 su WAN2" dst-address=208.67.222.222 out-interface=ether9
add action=drop chain=output comment="drop OpenDNS2 su WAN1" dst-address=208.67.220.220 out-interface=ether10

I hope I didn't write stupid (although I think I did)

anav · Thu Dec 23, 2021 8:23 pm

Sure,
-rules in orange I would get rid of.
-rules in blue I would keep
-rules in green I have a question
-rules in purple have me confused

ip firewall filter
add action=drop chain=input comment="Block wrong IPSEC requests" protocol=udp src-address-list=IPSEC_blacklist
add action=drop chain=input protocol=tcp src-address-list=IPSEC_blacklist
add action=drop chain=input comment="Block Port Scanners" protocol=tcp src-address-list="port scanners"
add action=drop chain=input protocol=udp src-address-list="port scanners"

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 in-interface-list=Simone Subnet
add action=accept chain=input comment="Accetta richieste Webfig Mikrotik" dst-port=17801 in-interface=ether10 protocol=tcp
add action=accept chain=input comment="Regola di accesso protocollo L2TP IPsec" in-interface=ether10 protocol=ipsec-esp
add action=accept chain=input comment="Regola di accesso porte per L2TP IPsec" dst-port=500,1701,4500 in-interface=ether10 protocol=udp
add action=drop chain=input
(1) I will assume that simone-subet is your LAN subnet and thus the rule is fine.

add action=add-src-to-address-list address-list="port scanners" address-list-timeout=none-dynamic chain=input comment="Port scanners to list " fragment=no hotspot="" protocol=tcp psd=21,3s,3,1
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=Simone Subnet out-interface-list=WAN interfaces
add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400
add action=accept chain=forward comment="Internet Access Fiber Cristina" in-interface="vlan 410" out-interface=ether10
add action=accept chain=forward comment="Internet Access ADSL Cristina" in-interface="vlan 410" out-interface=ether9
add action=accept chain=forward comment=Accept request from lan master to vlan NAS Synology Backup" dst-address=172.16.10.0/24 src-address=192.168.3.0/24
add action=drop chain=forward comment="Drop all from vlan 410 except to WAN1" out-interface=!ether10 src-address=172.16.20.0/28
add action=drop chain=forward comment="Drop request from vlan graziano to lan master" dst-address=192.168.3.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan graziano to vlan Simone" dst-address=192.168.5.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan graziano to vlan Service" dst-address=192.168.2.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan service to lan Master" dst-address=192.168.3.0/24 src-address=192.168.2.0/24
add action=drop chain=forward comment="Drop request from vlan service to vlan Simone" dst-address=192.168.5.0/24 src-address=192.168.2.0/24

(2) Just to be clear you are saying you need anybody/everybody on vlan400 to be able to reach/originate a session to a single address 192.168.3.173
and you need anyone/everyone on the 192.168.3.0/24 subnet to be able to reach/originate a session to everyone on vlan400??

(1) Is this your way of allowing LAN to WAN traffic for vlan410 (internet access if so OK)
but why not
in-interface=vlan410 out-interface-list=WAN (one rule vice two ??)

(3) Okay the comment says from LAN master to synology (since both are complete subnets why not in-interface=vlanXX out-interface=vlanYY
( i was expecting the NAS to be a single device IP ?)

(2) This makes no sense what are you trying to accomplish with this rule. You have already allowed 410 to both WAN1 and WAN2
Suggest remove it.........

(4) Upon review all these rules should be removed. Remember the drop rule is last drops anything not already ALLOWED (accepted) previously.
So those rules are automatically applied by the last rule, very efficient

add action=drop chain=output comment="drop OpenDNS1 su WAN2" dst-address=208.67.222.222 out-interface=ether9
add action=drop chain=output comment="drop OpenDNS2 su WAN1" dst-address=208.67.220.220 out-interface=ether10

(2) The proper place to deal with WAN connectivity based on being able to reach the gateway directly or thru recursive routes is in IP ROUTES, so not sure what you are doing here??

simonefil · Mon Dec 27, 2021 3:08 pm

Sure,
-rules in orange I would get rid of.
-rules in blue I would keep
-rules in green I have a question
-rules in purple have me confused

ip firewall filter
add action=drop chain=input comment="Block wrong IPSEC requests" protocol=udp src-address-list=IPSEC_blacklist
add action=drop chain=input protocol=tcp src-address-list=IPSEC_blacklist
add action=drop chain=input comment="Block Port Scanners" protocol=tcp src-address-list="port scanners"
add action=drop chain=input protocol=udp src-address-list="port scanners"

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 in-interface-list=Simone Subnet
add action=accept chain=input comment="Accetta richieste Webfig Mikrotik" dst-port=17801 in-interface=ether10 protocol=tcp
add action=accept chain=input comment="Regola di accesso protocollo L2TP IPsec" in-interface=ether10 protocol=ipsec-esp
add action=accept chain=input comment="Regola di accesso porte per L2TP IPsec" dst-port=500,1701,4500 in-interface=ether10 protocol=udp
add action=drop chain=input
(1) I will assume that simone-subet is your LAN subnet and thus the rule is fine.

add action=add-src-to-address-list address-list="port scanners" address-list-timeout=none-dynamic chain=input comment="Port scanners to list " fragment=no hotspot="" protocol=tcp psd=21,3s,3,1
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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=accept chain=forward comment="Allow internet traffic outbound" in-interface-list=Simone Subnet out-interface-list=WAN interfaces
add action=accept chain=forward in-interface=vlan400 dst-address=192.168.3.173
add action=accept chain=forward src=address=192.168.3.0/24 out-interface=vlan400
add action=accept chain=forward comment="Internet Access Fiber Cristina" in-interface="vlan 410" out-interface=ether10
add action=accept chain=forward comment="Internet Access ADSL Cristina" in-interface="vlan 410" out-interface=ether9
add action=accept chain=forward comment=Accept request from lan master to vlan NAS Synology Backup" dst-address=172.16.10.0/24 src-address=192.168.3.0/24
add action=drop chain=forward comment="Drop all from vlan 410 except to WAN1" out-interface=!ether10 src-address=172.16.20.0/28
add action=drop chain=forward comment="Drop request from vlan graziano to lan master" dst-address=192.168.3.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan graziano to vlan Simone" dst-address=192.168.5.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan graziano to vlan Service" dst-address=192.168.2.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="Drop request from vlan service to lan Master" dst-address=192.168.3.0/24 src-address=192.168.2.0/24
add action=drop chain=forward comment="Drop request from vlan service to vlan Simone" dst-address=192.168.5.0/24 src-address=192.168.2.0/24

(2) Just to be clear you are saying you need anybody/everybody on vlan400 to be able to reach/originate a session to a single address 192.168.3.173
and you need anyone/everyone on the 192.168.3.0/24 subnet to be able to reach/originate a session to everyone on vlan400??

(1) Is this your way of allowing LAN to WAN traffic for vlan410 (internet access if so OK)
but why not
in-interface=vlan410 out-interface-list=WAN (one rule vice two ??)

(3) Okay the comment says from LAN master to synology (since both are complete subnets why not in-interface=vlanXX out-interface=vlanYY
( i was expecting the NAS to be a single device IP ?)

(2) This makes no sense what are you trying to accomplish with this rule. You have already allowed 410 to both WAN1 and WAN2
Suggest remove it.........

(4) Upon review all these rules should be removed. Remember the drop rule is last drops anything not already ALLOWED (accepted) previously.
So those rules are automatically applied by the last rule, very efficient

add action=drop chain=output comment="drop OpenDNS1 su WAN2" dst-address=208.67.222.222 out-interface=ether9
add action=drop chain=output comment="drop OpenDNS2 su WAN1" dst-address=208.67.220.220 out-interface=ether10

(2) The proper place to deal with WAN connectivity based on being able to reach the gateway directly or thru recursive routes is in IP ROUTES, so not sure what you are doing here??

Hello. Thank you very much for your reply. I answered your points using your own number.
0) I have seen that you don't like the filters for blocking IPSEC requests and port scanners. Why? I have been implementing them for several weeks and they are blocking several requests from unknown IPs (which I throw in blacklist)
1) Simone Subnet, yes it's my personal LAN subnet
2) Yes exactly, all the clients of the VLAN400 will have to reach and create sessions only towards the IP 192.168.3.173. Everything else must be drop. At the same time all my devices on my personal subnet will have to reach the VLAN400 devices for management.
1) Yes indeed by having a wan list, I can just declare that list. thank you
3) No, it is an entire subnet dedicated to remote synology backups. Through IPsec VPN the remote synologies will authenticate in the VLAN400 and will only be able to reach their recipient, that is 192.168.3.173
2) Ok I remove
4) Initially I used the distances on the routes, but it did not always work, as my internet provider sometimes made me reach its gateway but I had no connection, so I found this system that pings known servers (openDNS) and if it does not reach them deactivate the route until it is reached again.

anav · Mon Dec 27, 2021 4:43 pm

If all is working well for you, no need to change it.

Port forwarding problem on VLAN

Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Re: Port forwarding problem on VLAN

Who is online