UPnP does not create dynamic rules in ip firewall filter.
UPnP create dynamic rules only ip firewall nat.
I found a topic 2 years ago, where it is solved by the scripts http://forum.ixbt.com/topic.cgi?id=14:57592-41#1141
http://forum.ixbt.com/topic.cgi?id=14:57592-42#1148
Mikrotik did for so many years can not solve this problem?
it does what it has to do - dynamic nat rules to forward certain ports to your internal host.
Dynamic nat rules will work if all the filter will be allowed, but no one does. Firewall order is not to put all generally allowed in the filter. In mikrotik have specialists who understand what I’m saying?
If you do not allow the filter to the nat does not fall.
Ie all have a problem, and mikrotik believes that it should be so.
Thus you confirm that you mikrotik way to fix it is not going to?
DST-NAT is done before any firewall filter.
Check packet flow diagram first:
http://wiki.mikrotik.com/wiki/Packet_Flow#Diagram
UPnP works properly on MikroTik routers.
Regards,
I understand the rules of procedure for passing.
Order flow does not affect the fact that usually all the last rule in the firewall forward prohibits the passage of incoming connections.
What’s the point having a firewall on it to allow all incoming connections?
I also noticed this. My solution was to add a filter rule to allow all connections to my local subnet. Not a good solution, and I agree that UPnP should add a dynamic allow rule to the filter for the dst-nat’ed port.
Sent from my LG-D800 using Tapatalk
@aya & rkau045
I don’t know how your configuration looks like,
but my UPnP settings works perfectly without filter allow rule to DST-NAT’ed ports.
usually all the last rule in the firewall forward prohibits the passage of incoming connections.
Why ‘forward’ chain, not ‘input’?
Properly configured firewall allows packets forwarded from WAN to LAN, only if they belongs to established/related connection initiated from LAN side.
Regards,
Established and related traffic from WAN is allowed in my configs. The problem is that I have devices that should accept New connections on the ports set up by UPnP, but standard firewall rules will drop that traffic without the accept rule added for the local subnet. This is the issue I had, and the solution I end up using.
Sent from my LG-D800 using Tapatalk
I should add:
For established and related connections, UPnP is never necessary. That is the reason for UPnP to exist at all.
Sent from my LG-D800 using Tapatalk
I have to add a filter rule on my forward chain for every dst-nat rule I make.
ditonet do you have a “drop everything else” rule at the end of your forward chain?
chain=forward action=drop
IMHO ‘standard firewall rules’ definition is different for every network administrator 
.
For me UPnP works even if everything from WAN side is dropped.
As I wrote earlier, packet flow clearly states that DST-NAT is before firewall filter, no matter manually defined or dynamically added by UPnP.
ditonet do you have a “drop everything else” rule at the end of your forward chain?
chain=forward action=drop
No, I don’t. What is your reason for this rule???
‘Forward’ chain is for packet passing through the router.
Regards,
I know that the forward chain is for packets going through the router.
I saw chain=forward action=drop in the Firewall section of the Learn RouterOS by example book and numerous firewall rules on this forum.
Another example is the wiki http://wiki.mikrotik.com/wiki/Protecting_your_customers
So I thought I did the right thing by adding that rule.
Ok let me get this straight in my head.
chain=forward action=drop is not needed on the forward chain.
But am I correct that everything is allowed on the forward chain then?
My basic config for ‘forward’ chain is:
Allow if connection-state is ‘established’ and ‘related’
Drop if connection-state is ‘invalid’
/ip firewall filter
add chain=forward comment=“default configuration - established” connection-state=established
add chain=forward comment=“default configuration - related” connection-state=related
add action=drop chain=forward comment=“default configuration - drop invalid” connection-state=invalidHTH,
Now I understand why you do not require any additional rules: you are ACCEPTING ALL TRAFFIC transiting your router via the default ACCEPT policy of the router, i.e. you have no firewall for forwarded traffic. Any packet sent to your router with any destination address that is not the router address will be forwarded. So it is possible to source-route packets from any network attached device in the world to any other (public) device as well as all of the devices on your local network.
This is considered to be highly insecure, and could easily be used as a vector to disguise the source of internet based intrusions or attacks.
Almost every network security professional I can think of will tell you that you should terminate every chain with a DROP rule, and only allow traffic that you have explicitly authorized to pass.
No, I accept established and related connections only and drop invalid.
Could you explain this?
E. g. my WAN interface address is 1.2.3.4 and this interface receives packet with dst-address 5.6.7.8.
According to your post this packet will be forwarded by router in case of no drop rule at the end of ‘forward’ chain.
IMHO this packet is dropped by rule:
/ip firewall filter
add action=drop chain=forward comment=“default configuration - drop invalid” connection-state=invalidDid you ever test this???
Regards,
connection-state (estabilished | invalid | new | related; Default: )
Interprets the connection tracking analysis data for a particular packet:
established - a packet which belongs to an existing connection
invalid - a packet which could not be identified for some reason
new - the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions.
related - a packet which is related to, but not part of an existing connection, such as ICMP errors or a packet which begins FTP data connection
does not describe the State=new. Packets to initiate a connection you allow?
If you put a more restrictive rule you would eliminate the thread (If I understood you correctly). For instance, allowing forward of all new connections but only when your destination is your internal network (this way no one could route public packets through you)
There is no matcher for SYN packets in these rules. therefore they follow the default policy of ACCEPT. This is how a new connection is established.
If the packet is a SYN packet (new connection request), then the DROP invalid matcher does not apply and the packet will reach the end of your firewall chain where is is ACCEPT’ed by default. This is why the wiki articles on firewalls include a DROP statement at the end of each chain.
This is quite correct according to the rules posted above.
Yes. This would be the rule allowing new connections to the local subnet that needed to be added to address the issue in the OP. The problem with this is that it effectively opens the local subnet for a similar type of attack vector.
The better solution would be to have dynamic rules that match the dst-nat rules added by UPnP. Another option would be to let dst-nat be the terminal action in the firewall with the implication that any traffic that matches a dst-nat rule is to be accepted with no further processing by the firewall (you can see how this could cause different issues) or some other alteration of the packet flow within the routing engine.
I am certain that people smarter than myself about these things could design a proper solution.
Hope that makes things clearer
Are you sure that these SYN packets from WAN side hit ‘forward’ chain, not ‘input’? For what reason?
According to packet-flow diagram if SYN packet hits WAN interface,
first is checked against DST-NAT rules and router’s service ports (Winbox, SSH, etc.).
Next this packet flows to ‘input’ chain, where is dropped (in my case) by filter’s last rule.
Because you wrote than my ‘forward’ chain ruleset is insecure I’ve made some test.
I’ve added log rule as last rule in ‘forward’ chain, just after drop invalid.
After few hours result is zero hits, but ‘input’ chain drop rule counter still increase.
Regards,
The packet will only flow into the input chain if the destination address is the router address. For other addresses behind the router, the flow is in to the forward chain. So of you source-route a packet to the WAN interface with a destination that is not the router IP it will be forwarded not input. If the destination IP is the router IP it is input. If you request a new connection on a port that has dst-nat rule mapping to a different IP, you will see it in the forward chain. I will try to post example logs from my working routers when I have some workstation time later today.
Sent from my LG-D800 using Tapatalk