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,

@ditonet

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

@rkau045

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.

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.

@BenCo

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?

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'

ros code

/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=invalid

HTH,

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.

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.

No, I accept established and related connections only and drop invalid.

Any packet sent to your router with any destination address that is not the router address will be forwarded.

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:

ros code

/ip firewall filter
add action=drop chain=forward comment="default configuration - drop invalid" connection-state=invalid

Did 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?

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.

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)

No, I accept established and related connections only and drop invalid.

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.

IMHO this packet is dropped by rule:

ros code

/ip firewall filter
add action=drop chain=forward comment="default configuration - drop invalid" connection-state=invalid

Did you ever test this???

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.

does not describe the State=new. Packets to initiate a connection you allow?

This is quite correct according to the rules posted above.

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)

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

@rkau045

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.

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

Sorry to double post, but I got a free minute.

This is a dropped packet on the input of my WAN for a non forwarded port: And here is a DST-NAT'ed: I put my log capture rules at the top of my firewall for this test to ensure that the logs would be generated before any filters were applied.

Notice that the DST-NAT'ed connection appears in the FORWARD chain, while the connection with no NAT is in the INPUT chain.

@rkau045
Your logs clearly shows what I wrote in my previous post.

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.

Maybe we misunderstood each other because english is not my native language .
At the moment I'm unable to check if this sentence:

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.

is true or not. But I'm curious, I'll try to make some tests and let you know results.

Regards,

The fallacy in your post is that the packet is only checked in the input chain IF the dst-nat does NOT change the destination to an address that is different from the router IP.

If dst-nat does change the destination IP then the packet never touches the INPUT chain.

Edited to add:
No DST-NAT = INPUT
DST-NAT = FORWARD


Sent from my LG-D800 using Tapatalk

No DST-NAT = INPUT
DST-NAT = FORWARD

This is obvious for me and always was, read my posts.
Few posts earlier I asked you with example:

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.

Can you confirm that packet with dst-address 5.6.7.8 will flow through 'forward' chain???

Regards,

All you need to do to test this yourself is to connect a PC to the uplink port on your MikroTik device, set it's gateway to be the IP address on the uplink port, and send a packet to any address that is not the router. Capture the forward logs, and your will see the packet route out.

So, yes, that is what I am saying.

Sent from my LG-D800 using Tapatalk

I was hoping that this feature will correct MikroTik.
And from it was the only answer that it works how it works .

@rkau045
I made test and you are right.
Now I'm considering what to do to protect 'forward' chain in case of dynamic UPnP NAT rules.

Regards,

Learned a lot from this thread.
Thank you for testing Ditonet and reporting back. Good discussion.

I too have noticed, having a proper firewall setup blocking all and allowing certain traffic makes UPnP useless.

...

I just wanted to revisit this because I think MikroTik has a solution for this problem now.
With RouterOS 6.22rc7 you can have a forward chain accept rule for only dst-natted connections.
They added a "Connection NAT State" matcher for dstnat, srcnat or both. I only want my game console to use UPnP so I have this rule now. My game console has IP 192.168.111.13. My WAN IP is dynamic so I use in-interface=ether1