Hello, i’m trying to add portforward rule and hairpin nat on port 25565, but the problem is, the rules only work on minecraft but not other games. It was working before, but then i had to reset to factory settings, am i missing some option?
Port is showing open from https://www.yougetsignal.com/tools/open-ports/ after i add chain forward rule to firewall and deleted all other firewall rules (i know thats bad practice, but i was out of options). Any help?
/ip firewall filter
add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related
add action=accept chain=forward comment="Established, Related" connection-state=established,related
add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid
add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge log=yes log-prefix=!public_from_LAN out-interface=!bridge
add action=drop chain=forward comment="Drop incoming packets that are not NATted" connection-nat-state=!dstnat connection-state=new in-interface=ether1 log=yes log-prefix=!NAT
add action=drop chain=forward comment="Drop incoming from internet which is not public IP" in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet
add action=drop chain=forward comment="Drop packets from LAN that do not have LAN IP" in-interface=bridge log=yes log-prefix=LAN_!LAN src-address=!192.168.88.0/24
Still no good as I dont see any INPUT CHAIN firewal rules and thus not secure to attach to the internet.
Also your forward rules are cumbersome and thus confusing. keep it simple, clean and default.
This is the default list that you cant go wrong with!!!
/ip firewall filter
{INPUT}
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=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
{FORWARD}
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
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=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
…
Typically I recommend changing from an allow everything with some key block rules, to block everything with a few key allow rules.
So one adds the following in the input chain
ALLOW ADMIN ACCESS TO ROUTER - usually via firewall address list - which list devices I will use to access winbox ( desktop, laptop, ipad etc)
ALLOW LAN USERS ACCESS TO ROUTER but ONLY FOR SERVICES - typically DNS only port 53 udp, tcp
DROP ALL ELSE
Notes:
only put in the drop all else rule when you have the allow admin rule in place otherwise one is locked out of the router LOL
once the above rules are in place you can then remove this redundant rule
(add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN)
So what the above does is not give everyone access to the router, ONLY the admin and block all traffic not specifically allowed.
In the forward chain.
One adds
Before the last rule (which will also be)
DROP ALL ELSE
any rules required to enable services typically
ALLOW SUBNETS or VLANS access to the INTERNET
ALLOW ADMIN to access ALL subnets and VLANS (if required)
ALLOW USERS any other access across subnet or vlan for shared devices, like a printer (If required)
ALLOW PORT FORWARDING (if required). ***
DROP ALL ELSE
Notes:
once the above are in place you can remove this rule
(add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface-list=WAN)
So what the above does is allow only the traffic you wish to permit and block everything else, it also separate out port forwarding and its an optional rule which looks like this.
*** add action=accept chain=forward comment=“Allow Port Forwarding”
connection-nat-state=dstnat connection-state=new in-interface-list=WAN
all these rules in your forward chain can be removed as they are covered by DROP ALL ELSE.
add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge log=yes log-prefix=!public_from_LAN out-interface=!bridge
add action=drop chain=forward comment="Drop incoming packets that are not NATted" connection-nat-state=!dstnat connection-state=new in-interface=ether1 log=yes log-prefix=!NAT
add action=drop chain=forward comment="Drop incoming from internet which is not public IP" in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet
add action=drop chain=forward comment="Drop packets from LAN that do not have LAN IP" in-interface=bridge log=yes log-prefix=LAN_!LAN src-address=!192.168.88.0/24
As for the port forwarding rules, not sure how mangle will affect your config, but normally its not used for basic port forwarding, so you must have some purpose with it not communicated??
As for the hairpin source nat rule, its better not to be specific and the rule should be as follows and remove the ones in red).
add action=masquerade chain=srcnat comment=hairpinnat dst-address=192.168.88.0/24 src-address=192.168.88.0/24
As for this rule, I have no idea what you are trying to do here??? This has nothing to do with UPNP as that is handled in a separate location???
If its simply a port forwarding rule you would have get rid of the in-interface=ether1
Why are LAN clients connecting to your game server from the WAN ip? If you forward ports, why are you using UPnP?
By default, only outbound connections are allowed for all LAN clients in the firewall filter. NAT is setup both ways accordingly.
Logically, for clients to connect from the WAN side to your server, you first need to open a port in the firewall’s forward chain so those clients can connect. Then, you make a dstnat rule for the server connections. I have no idea why you have so many rules…
If you need to forward more than one port, you can add all of them to the same rule. The more you add rules, the more confusing your config gets and the more resources are required to process everything. ROS is very efficient, until you add things that you don’t need. The last thing most people want for gaming servers/clients is adding useless processing delays on packets…
Sob he already had the default rule in place… (but I much prefer the cleaner rule you suggested)
add action=drop chain=forward comment=“Drop incoming packets that are not NATted” connection-nat-state=!dstnat connection-state=new in-interface=ether1 log=yes log-prefix=!NAT
