Mk, NAT Open Request [Help needed]

Lebzul · Thu May 02, 2019 4:46 am

Hi there,

I have been looking exhaustively for information regarding to have Open Nat at "multiple clients". I've seen UPnP, 1:1 (which I am doing to one client) with netmap.
But what I am looking is to open full ports so my devices could have Open Nat while playing online. So far, I know that it's possible but for one device. If I activate UPnP Nat type becomes 2 but moderate while playing.

My setup is like the following:
ISP ---> RB ---> Linksys Switch ----> LAN

Some lan devices are connected directly to the RB due to a DumbAP.

Any ideas will be appreciated. I have been going through this for almost two years and haven't found a concrete solution.

Sob · Thu May 02, 2019 6:13 am

NAT hides multiple addresses behind one and it works for outgoing connections. But if there's incoming connection to external address, router must decide where to send it. With NAT 1:1, everything to external address is sent to one internal address. Ports stay the same, only destination address changes, it's easy. UPnP is for selected ports. So internal device A tells router that it needs ports a, b, c forwarded to it, device B tell router that it needs x, y, z. And it also works, because if incoming connection is to port a, it goes to device A, if for port x, it goes to device B, also easy.

You want some magic where incoming connection to port x would go to device A and another incoming connection to same port x would go to device B. That's generally impossible, it could only work with other conditions, e.g. if you could tell that connections to port x that should go to device A will be from address X, while connections to port x that should go to device B will be from elsewhere. That would be possible. But you don't know from where it will come.

There's only one long-term solution and it's IPv6. It allows every device to have own public address, there's no NAT, so all NAT troubles go away.

Lebzul · Thu May 02, 2019 2:50 pm

NAT hides multiple addresses behind one and it works for outgoing connections. But if there's incoming connection to external address, router must decide where to send it. With NAT 1:1, everything to external address is sent to one internal address. Ports stay the same, only destination address changes, it's easy. UPnP is for selected ports. So internal device A tells router that it needs ports a, b, c forwarded to it, device B tell router that it needs x, y, z. And it also works, because if incoming connection is to port a, it goes to device A, if for port x, it goes to device B, also easy.
[...]

Thanks for the reply.
I see. The problem is that my ISP does not provide IPv6 yet.
Putting aside the destination stuff you've mentioning, when I dstnat all ports in tcp/udp for a given list of addresses, the thing does not work. It only works when I netmap one client but I am in the necessity to open more than one.
There relies the issue.

Sob · Thu May 02, 2019 4:23 pm

I understand what you want. But think about poor router. It has one external address, let's say 1.2.3.4. If a new connection comes to e.g. 1.2.3.4:5678, how can it know if it should send it to internal 192.168.88.10, 192.168.88.20, or some other one? It can't. It's like wanting to hit two completely different targets with one bullet.

Lebzul · Thu May 02, 2019 6:31 pm

I understand what you want. But think about poor router. It has one external address, let's say 1.2.3.4. If a new connection comes to e.g. 1.2.3.4:5678, how can it know if it should send it to internal 192.168.88.10, 192.168.88.20, or some other one? It can't. It's like wanting to hit two completely different targets with one bullet.

Yes, probably I haven't made me clear. The context is online gaming. PSN/XBOX sets NAT Type based on the network. If I connect the PS4/XBOX directly to the modem, they receive NAT Type 1 and in-game Nat Open.

If I connect those consoles through the RB, they receive NAT Type 2 and in-game Nat Moderate. Even if I open all ports with dst-nat ports 1-65535 due to mascarading.

If I assign that console's static IP with the Netmap to send the Public IP, I am able to get the same as connecting the console directly to the modem. The downside is that only one client is possible.

My main questions is: How can I do Netmapping to multiple clients (the ones who want open nat while playing online)?

anav · Thu May 02, 2019 7:04 pm

edit removed
Good question, what is going on with MT NAT that is different from a consumer router that just works for this scenari0?
I am thinking the extra granularity of MT should provide a config that works!!

Lebzul · Thu May 02, 2019 7:25 pm

edit removed
Good question, what is going on with MT NAT that is different from a consumer router that just works for this scenari0?
I am thinking the extra granularity of MT should provide a config that works!!

The thing is that I cannot open all ports to a few clients. If I assign Netmap to a client, I lose VPN of my MT and that's not the case.
The main concern is to have all ports open to a client (let's say a router) and that client assigns private IP to console with its DMZ to that console.
Like this:
MT-->Switch --> AP---AP <-- Router ---PS4

sindy · Fri May 03, 2019 6:50 pm

Do you say that when you connect two consoles to the modem directly (i.e. without Mikrotik in between the modem and the consoles) at the same time, both consoles indicate the same NAT type "open" and you can use both simultaneously (with two players playing the same online game each on one of those two consoles)?

anav · Fri May 03, 2019 8:08 pm

Good question Sindy, are you trying to establish if one gaming console is being used or two being used at the same time?
Q1: Does one gaming console work with normal consumer router to modem (or isp supplied combo router/modem)?
Q2: Do two gaming consoles work at the same time with normal consumer router to modem (or isp supplied combo router/modem)?
Q3: Does one gaming console work with MT router?
Q4: Do two gaming consoles work at the same time with the MT router?

Q5: In any scenario where both consoles are connected at the same time, are players at each console able to play the same game concurrently (online)?

Lebzul · Fri May 03, 2019 11:14 pm

Do you say that when you connect two consoles to the modem directly (i.e. without Mikrotik in between the modem and the consoles) at the same time, both consoles indicate the same NAT type "open" and you can use both simultaneously (with two players playing the same online game each on one of those two consoles)?

Hi,
Not both at the same time. The topic is for one at the time.

sindy · Fri May 03, 2019 11:32 pm

So you want Mikrotik to forward packets coming to its public address to the private one of the console on the LAN, but choose the right one depending on which console is connected at the time?

Because the DMZ approach (1:1 NAT) should be enough to make the console think that the NAT is the "open" type, and the private address can be updated using a script whenever one of the consoles gets an address from Tik's DHCP server. And the VPN access can be preserved using exceptions from the 1:1 dst-nat rule for the ports used for the VPN, unless the console uses the very same ports for its own purposes.

Lebzul · Fri May 03, 2019 11:59 pm

Good question Sindy, are you trying to establish if one gaming console is being used or two being used at the same time?
Q1: Does one gaming console work with normal consumer router to modem (or isp supplied combo router/modem)?
Q2: Do two gaming consoles work at the same time with normal consumer router to modem (or isp supplied combo router/modem)?
Q3: Does one gaming console work with MT router?
Q4: Do two gaming consoles work at the same time with the MT router?

Q5: In any scenario where both consoles are connected at the same time, are players at each console able to play the same game concurrently (online)?

A1: The gaming console should connect to internet just fine with a router even if assigned a private IP. Opened ports (directly to the modem) works best.
A2: Should work in a private IP environment. Not sure for public IP assignments. May depend on ISP.
A3: It works but if given an IP from the MT, it might say NAT moderate. Even if dsnat all TCP/UDP ports to that console's IP. (Might be MT's mistake).
A4: They do but the issue is not if they work but to have Open NAT behind another router.

Lebzul · Sat May 04, 2019 12:02 am

So you want Mikrotik to forward packets coming to its public address to the private one of the console on the LAN, but choose the right one depending on which console is connected at the time?

Because the DMZ approach (1:1 NAT) should be enough to make the console think that the NAT is the "open" type, and the private address can be updated using a script whenever one of the consoles gets an address from Tik's DHCP server. And the VPN access can be preserved using exceptions from the 1:1 dst-nat rule for the ports used for the VPN, unless the console uses the very same ports for its own purposes.

No need for VPN. MT > Linksys Router > PS4.
MT receives public IP. Linksys gives PS4 private.
Linksys should be in DMZ/1:1.

The problem is when I need more than one client in DMZ.

sindy · Sat May 04, 2019 3:18 pm

The problem is when I need more than one client in DMZ.

That is why I asked about two PS4s used simultaneously. You said you need just one PS4 but at the same time you say you need two clients in DMZ.

In NAT environment, 1:1 NAT is the best approximation of a DMZ you can get. When a device on a private IP checks how the NAT behaves in particular, it checks with the server whether the server has received the initial request for a connection from the same port from which the client has sent it; this is what Mikrotik normally does unless another client device sends a request to the same remote socket from the same port, as in such case, all the fields used to identify a connection (address:port of the server and address:port of the Mikrotik's WAN) would be identical for both connections so it would not be possible to decide to which of the two connection a packet received at WAN belongs.

For incoming communication requests, where the device on a private side of the NAT acts as a server, the situation is even more hopeless - the address of the remote client cannot be used to choose the required one out of the two addresss on the private side, so you simply cannot have more than a single device in DMZ behind a NAT unless each of them would listen on a different set of ports.

anav · Sat May 04, 2019 8:19 pm

Introducing a second router in the mix is I suspect going to be problematic regardless of which user console is going to be used..........
Have you tried connecting the consoles directly to the MT router??

Lebzul · Sun May 05, 2019 2:46 pm

The problem is when I need more than one client in DMZ.
That is why I asked about two PS4s used simultaneously. You said you need just one PS4 but at the same time you say you need two clients in DMZ.

In NAT environment, 1:1 NAT is the best approximation of a DMZ you can get. When a device on a private IP checks how the NAT behaves in particular, it checks with the server whether the server has received the initial request for a connection from the same port from which the client has sent it; this is what Mikrotik normally does unless another client device sends a request to the same remote socket from the same port, as in such case, all the fields used to identify a connection (address:port of the server and address:port of the Mikrotik's WAN) would be identical for both connections so it would not be possible to decide to which of the two connection a packet received at WAN belongs.

For incoming communication requests, where the device on a private side of the NAT acts as a server, the situation is even more hopeless - the address of the remote client cannot be used to choose the required one out of the two addresss on the private side, so you simply cannot have more than a single device in DMZ behind a NAT unless each of them would listen on a different set of ports.

I agree.
Can this be bypassed by having an address list to DMZ?

Lebzul · Sun May 05, 2019 2:48 pm

Introducing a second router in the mix is I suspect going to be problematic regardless of which user console is going to be used..........
Have you tried connecting the consoles directly to the MT router??

That router is remotely connected through a wireless CPE so, it is necessary to have a router because that CPE is bridged and the end user needs to connect multiple devices.
Connecting directly to the MT and UPnP works but that's not the scenario.

sindy · Sun May 05, 2019 3:14 pm

Can this be bypassed by having an address list to DMZ?

If you mean an address list of the sources in the internet, then yes. You can forward packets for wan.add.re.ss:port to private.add.ress.1:port if they come from a source on address-list "list1", and to private.add.ress.2:port if they come from a source on address-list "list2", and to private.add.ress.3:port if they come from a source which is not on any address list.

Or you can forward the packets to private address chosen up to the destination port.

But you cannot decide which of the three internal addresses to choose if you do not know in advance on which port it listens (or if all of them listen on the same port) or from where the request will come.

It is not a matter of configuration, it is a matter of common sense. If you do not have any information in the packet itself which would tell you where to send it, there is nothing you could use to choose a forwarding (dst-nat) rule.

But I am still wondering about your overall topology. Do the PS4 games send packets between players directly, i.e. not via a gaming server? Because the only scenario I can imagine where you need a real DMZ is that you have two PS4s behind the same public IP, and a third one behind another public IP, and they all participate in the same game to the third one needs to send direct packets to both the first and second one. Only in this case there is a conflict because when the first PS4 seizes a particular port on the public IP of the WAN interface for a connection with the third one, the second PS4 cannot seize the same port for connection with the third one because the packets coming from the third PS4 to that port would be forwarded to the first console.

So maybe we were not clear enough in the example with two PS4, where you want to have one connected directly to Mikrotik's LAN and the other one connected to the LAN of the Linksys but it also gets to internet via the same Mikrotik like the first one, and we've simplified it to just 2 PS4 on Mikrotik's LAN, approximating the tunnel via Linksys by just a cable?

Lebzul · Mon May 06, 2019 11:09 pm

Can this be bypassed by having an address list to DMZ?
If you mean an address list of the sources in the internet, then yes. You can forward packets for wan.add.re.ss:port to private.add.ress.1:port if they come from a source on address-list "list1", and to private.add.ress.2:port if they come from a source on address-list "list2", and to private.add.ress.3:port if they come from a source which is not on any address list.

Or you can forward the packets to private address chosen up to the destination port.

But you cannot decide which of the three internal addresses to choose if you do not know in advance on which port it listens (or if all of them listen on the same port) or from where the request will come.

It is not a matter of configuration, it is a matter of common sense. If you do not have any information in the packet itself which would tell you where to send it, there is nothing you could use to choose a forwarding (dst-nat) rule.

But I am still wondering about your overall topology. Do the PS4 games send packets between players directly, i.e. not via a gaming server? Because the only scenario I can imagine where you need a real DMZ is that you have two PS4s behind the same public IP, and a third one behind another public IP, and they all participate in the same game to the third one needs to send direct packets to both the first and second one. Only in this case there is a conflict because when the first PS4 seizes a particular port on the public IP of the WAN interface for a connection with the third one, the second PS4 cannot seize the same port for connection with the third one because the packets coming from the third PS4 to that port would be forwarded to the first console.

So maybe we were not clear enough in the example with two PS4, where you want to have one connected directly to Mikrotik's LAN and the other one connected to the LAN of the Linksys but it also gets to internet via the same Mikrotik like the first one, and we've simplified it to just 2 PS4 on Mikrotik's LAN, approximating the tunnel via Linksys by just a cable?

Thanks Sindy for giving your opinion in this topic. Probably, we have gone so deep into this and I would like to clarify the main point here.

PS4 needs open ports to play fine. That's basically it. When the PS4 is connected to a router (MT>Router>PS4) it is receiving a double NAT. Then, if I activate UPnP in the router, nothing happens. There is no register of petitions of ports at the MT level from the router on behalf the PS4. I don't know if I am making myself understood or doing this correctly. I know it's child's play but not for me at this point. I have been reading for months and no solution.

Then, if I dstnat all 1-65535 ports to that router, it's not working for some reason. Much less if I have to consoles (XBOX and PS4) in my network.

How can we have all ports open for a given client? That's the issue.

Sob · Mon May 06, 2019 11:33 pm

If you'd have:

MT>Router>(PS4#1,PS4#2,...)

then NAT 1:1 from MT to Router and UPnP on Router should work fine (edit: although maybe not, I'm not sure if client gets public address from UPnP server, it wouldn't be public in this case, if it does). But if it would be anything like:

MT>Router1>PS4#1
MT>Router2>PS4#2
MT>PS4#3

i.e. not all consoles behind same router, it's probably impossible. You'd either need to configure consoles to each use different port range and configure such port forwarding on routers (I have no idea if it's possible; probably not, because average user would not be able to configure it anyway). Or there would have to be some UPnP proxy on Router that would receive requests from clients, open ports as usual, and additionally send own UPnP port opening request to upstream router. I don't know if anything supports this (RouterOS surely doesn't).

sindy · Mon May 06, 2019 11:42 pm

How can we have all ports open for a given client? That's the issue.

For a single client that's no issue, the dst-nat rule may translate just the destination address and ignore protocol & port completely. So instead of specifying dst-port=1-65535, just leave the dst-port out from the rule completely, much like the default action=masquerade rules in chain=srcnat do. And this way, you can have a triple and quadruple NAT and still nothing happens.

The dst-nat rules are even evaluated before the decision whether the received packet is for the router itself or needs forwarding, so a dst-nat rule forwards even the ports on which the router itself eventually listens.

The trouble starts when there is some other equipment behind the same NAT and that equipment talks from the same ports to the same remote destination like the first one.

That's why I talked about a single PS4 connected directly on Mikrotik's LAN (and with UPnP disabled); if it works to your satisfaction, Mikrotik's handling of 1:1 NAT is not the issue. Have you tried this simplified scenario as a diagnostic step?

A single PS4 behind a Mikrotik and Linksys, each with 1:1 NAT configured, should also not be an issue even with UPnP disabled.

Two PS4 (or one PS4 and something else talking to the same remote services) behind the same public IP will always be a problem no matter whether directly on Mikrotik's (or any other NATing router's) LAN or behind yet another 1:1 NAT device.

sindy · Tue May 07, 2019 12:04 am

One more idea - if you can extend Mikrotik's LAN to the other site using an L2 tunnel, the PS4 will be able to talk UPnP with the Mikrotik, so you could have two or more (provided that the PS4 accepts a replacement port from the router if the requested one is already occupied).

Sob · Tue May 07, 2019 12:21 am

Or another idea (not really a serious one, just for fun), there's a standard for opening ports through double NAT (RFC 6970). So if your other router supports it (or you'd be able to convince manufacturer to add it if not), and you'd be able to convince MikroTik to add PCP server to RouterOS, it would (ok, should) work. The tough question is if one should invest the time and energy in this or better into convincing the world to finally advance with IPv6. Both seem to be long-term projects.

Lebzul · Tue May 07, 2019 12:58 am

If you'd have:

MT>Router>(PS4#1,PS4#2,...)

then NAT 1:1 from MT to Router and UPnP on Router should work fine (edit: although maybe not, I'm not sure if client gets public address from UPnP server, it wouldn't be public in this case, if it does). But if it would be anything like:

MT>Router1>PS4#1
MT>Router2>PS4#2
MT>PS4#3

i.e. not all consoles behind same router, it's probably impossible. You'd either need to configure consoles to each use different port range and configure such port forwarding on routers (I have no idea if it's possible; probably not, because average user would not be able to configure it anyway). Or there would have to be some UPnP proxy on Router that would receive requests from clients, open ports as usual, and additionally send own UPnP port opening request to upstream router. I don't know if anything supports this (RouterOS surely doesn't).

That is a very likely scenario. I'd like to have my consoles with all ports open. There are 3 and that's the problem.
With UPnP and PS4 connected directly to MT, works flawlessly. The problem comes when a router is introduced. I use to use OpenWRT in most of my routers.

Lebzul · Tue May 07, 2019 4:33 am

How can we have all ports open for a given client? That's the issue.
That's why I talked about a single PS4 connected directly on Mikrotik's LAN (and with UPnP disabled); if it works to your satisfaction, Mikrotik's handling of 1:1 NAT is not the issue. Have you tried this simplified scenario as a diagnostic step?

When that is done (UPnP: Off), PS4 shows NAT restricted.

A single PS4 behind a Mikrotik and Linksys, each with 1:1 NAT configured, should also not be an issue even with UPnP disabled.

Could you please explain a little bit more of 1:1? Is that for a single device or for the entire LAN? How is that done?

Two PS4 (or one PS4 and something else talking to the same remote services) behind the same public IP will always be a problem no matter whether directly on Mikrotik's (or any other NATing router's) LAN or behind yet another 1:1 NAT device.

Well, the MT is handling a public IP dynamically for worse so I have auto routes.

Unfortunately, there is no IPv6 yet in here.

Sob · Tue May 07, 2019 7:35 am

If you have OpenWRT on the other router, it may not be completely hopeless, because you can install additional stuff. So if someone made a proxy like I described:

Or there would have to be some UPnP proxy on Router that would receive requests from clients, open ports as usual, and additionally send own UPnP port opening request to upstream router.

Then you should be able to install it. I don't know if such thing exists, but the idea is logical and not even complicated (well, on first sight at least). So try to look around, maybe you'll be lucky.

sindy · Tue May 07, 2019 8:49 am

How can we have all ports open for a given client? That's the issue.
That's why I talked about a single PS4 connected directly on Mikrotik's LAN (and with UPnP disabled); if it works to your satisfaction, Mikrotik's handling of 1:1 NAT is not the issue. Have you tried this simplified scenario as a diagnostic step?

When that is done (UPnP: Off), PS4 shows NAT restricted.

OK, so this is the place to start from.

When the only enabled rules in your /ip firewall nat are as shown just below, is it still true that the PS4 reports a restricted NAT when UPnP is disabled?

action=dst-nat chain=dstnat in-interface-list=WAN to-addresses=the.internal.ip.of.ps4
action=masquerade chain=srcnat out-interface-list=WAN
(or, if you don't have the interface list configured, replace in-interface-list=WAN and out-interface-list=WAN by in-interface=your-wan-interface-name and out-interface=your-wan-interface-name respectively).

But regardless the result (which only tells us whether Mikrotik's NAT behaves the way I always believed it did or not), getting all three PS4 to the LAN of the Mikrotik and enabling UPnP is the only way to make them all be happy which doesn't require development or denial of logic.

Sob · Tue May 07, 2019 11:48 am

@sindy: I have one more idea about UPnP and double NAT, but I'm lacking knowledge about one needed part, maybe you know something about it. I'm not sure how much it can help OP, but let's assume that I want to do it with two RouterOS devices. Both under my control, but for some reason there must be different subnets.

To open port using UPnP, first there's SSDP discovery (UDP to 239.255.255.250:1900), it returns location of UPnP server, and the rest is easy, because it's just HTTP. But discovery is the interesting part. What if client received IP address of primary router as UPnP server (i.e. from different subnet)?

RouterOS happily accepts completely different internal address as destination for open port (e.g. client 192.168.88.10 can request port forwarded to 192.168.222.22 and RouterOS doesn't complain). So I guess it wouldn't complain either if 192.168.222.22 (i.e. address from non-local subnet) was the client (but I didn't test this part yet). Client could also accept UPnP server from remote subnet, I don't see anything clearly wrong with that, but of course it would depend on client.

The critical part is how to make discovery return the right server address. And this is where I'm lost. The 239.255.255.250 is multicast and it should be somehow possible to forward it between interfaces, but I'm ashamed to admit that I've never done anything with multicast before, so I don't even know where to start. Do you know more than I do about this? Not necessarily all details, mainly just if it's completely wrong way or not.

sindy · Tue May 07, 2019 12:05 pm

I've never done anything with multicast before, so I don't even know where to start. Do you know more than I do about this?

Just a small bit which doesn't help here. But unless you expect the inner NAT to be a 1:1 one again, I think it's not important because in case of stacked NATs, the client would have to be aware of the existence of stacked NAT and use UPnP to request ports at the inner NAT and then, based on the result, request a port on the outer NAT in the name of the inner one. Or, as you've suggested before, the inner NAT would have to act as UPnP client, request a port at the outer NAT, and based on that inform the client about the outer IP and port he's got. So it is probably a scriptable thing if you dive into UPnP enough, but the inner NAT must be able to run scripts, and its UPnP server functionality would have to be fully replaced by the script (in terms that it would receive the requests from the actual client, convert them into outgoing requests to the outer NAT, and create according rules in its own firewall).

As for the multicast routing, it is basically that when one of router's neighbors subscribes for some multicast group, the router should subscribe to the same group on its other interfaces, and then forward whatever comes for this group (= to this multicast address) to the original subscriber (or more thereof). On Mikrotik, a package called multicast must be installed for that.

Sob · Tue May 07, 2019 3:00 pm

Oops, sorry, I wrote double NAT, but I guess what I actually meant was just different routed subnet. Well, I started thinking about double NAT, but I got somehow lost in it.

anav · Tue May 07, 2019 4:19 pm

Don't feel bad i got lost at least 5 posts ago LOL.........

Sob · Tue May 07, 2019 6:00 pm

I'm not lost, I just took a wrong turn.

Btw, this looks like the proxy I thought about: https://github.com/tomaszmrugalski/portproxy (but I didn't test it).

sindy · Tue May 07, 2019 11:42 pm

I'd say you've just switched on the wrong winker rather than actually taken a wrong turn

Judging by this self-answered topic on another forum that Google has yielded it seems that configuration of multicast on Mikrotik is none of an issue.

Sob · Wed May 08, 2019 2:51 am

Uff, I had a look at multicast package and let's say that I'm starting to understand how @anav sometimes feels about things.

Or in other words, I'll keep that one for long winter nights, there's so many things and for multicast beginner it's not clear at all.

But for the record, I solved my UPnP for routed subnet (without NAT on second router). Even though I was able to forward multicast SSDP packets through the router, and I got replies back, for some reason client ignored them. But often when fine tools fail, hammer will do the job. So I just enabled UPnP on both routers and since RouterOS seems to always use tcp port 2828, I just added dstnat from <second router's LAN IP>:2828 to <first router's LAN IP>:2828. Client thinks that it talks to the router it's connected to, but all requests go to upstream router. It's a hack, but works like a charm here. Downside is that port 2828 doesn't seem to be any standard, from what I found, it can be anything, so interoperability with devices from other manufacturers could be a problem. But as long as the other router would use static port for own UPnP (even if it was different), and it would be configurable enough to be able to add required dstnat rule, it should work too.

There's still problem if second router has NAT. But I'm wondering, in this case:

That router is remotely connected through a wireless CPE so, it is necessary to have a router because that CPE is bridged and the end user needs to connect multiple devices.

Is NAT on second router absolutely necessary? Couldn't there be just a routed subnet? I don't know what exactly it is, if some serious ISP network, it could be a problem, but in some hobby network it could be ok.

sindy · Wed May 08, 2019 8:30 am

It largely depends on that wireless CPE's capabilities whether NAT can be switched off on it.

I didn't get the part about the client's ignoring of responses being resolved by port-forwarding its requests (is it 2828 on the multicast address or on the unicast one?), nor why UPnP must be enabled on the Tik adjacent to the client to make the port-forwarding work. Maybe it's because I'm not reading it at 2 AM?

Sob · Wed May 08, 2019 8:02 pm

2AM is not mandatory, it still makes sense now.

There are two parts. First is SSDP discovery (from client to udp 239.255.255.250:1900) and router sends back response containing address of control endpoint http://<router>:2828 (I'm not sure how it's officially called). I was able to get the discovery through router with multicast package, I saw the response on client with Wireshark, but for some reason client didn't like it, because no further communication followed. When I enable UPnP on second router, the only goal is to make SSDP discovery work. Client accepts response from second router, gets http://<second router>:2828, but all requests sent there are dstnatted to <first router>:2828. And because UPnP (as least in RouterOS) in first router doesn't care from what clients requests are, or what is requested target address for forwarded ports, it works.

sindy · Thu May 09, 2019 12:41 am

... I saw the response on client with Wireshark, but for some reason client didn't like it, because no further communication followed. When I enable UPnP on second router, the only goal is to make SSDP discovery work. Client accepts response from second router, ...

Okay, at third reading it clicked after all (well, 2 AM is not so far away). When you replace the word "second" by "the closer one to the client" or "inner", things start making sense. So the client likely ignores service discovery responses indicating a unicast address in non-connected subnet (what else could be the reason), so you satisfy it by giving it a response from a device in a connected subnet, and then steal the requests for that address and deliver them where you really need them to go. Cool. It means that you actually don't need the muticast routing at all provided that the "closer to the client" router supports UPnP and port forwarding in LAN -> WAN direction, and that the "outer" or "closer to internet" router doesn't mind getting client requests from a non-connected subnet.

Sob · Thu May 09, 2019 2:37 am

That's it. Sorry for confusing terms.

... the "closer to the client" router supports UPnP and port forwarding in LAN -> WAN direction, ...

The latter disqualifies all simple consumer routers I've ever seen.

Lebzul · Tue May 14, 2019 3:06 am

https://ibb.co/rw50dGW
Even if the Xbox is statically connected and with all ports "open", it still shows NAT restricted at the console level.

CZFan · Tue May 14, 2019 3:34 am

I think it is time you pride the config, in terminal window,
Export file=YourFileName hide-sensitive and either attach the file here or copy and paste the contents between source code brackets

Lebzul · Fri May 17, 2019 3:25 pm

I think it is time you pride the config, in terminal window,
Export file=YourFileName hide-sensitive and either attach the file here or copy and paste the contents between source code brackets

Modem > MT > Switch
UPnP: On

NAT
chain=srcnat action=masquerade out-interface=WAN1 PoE log=no 
      log-prefix=""

Filter
 ;;; DMZ Gaming
      chain=forward action=accept connection-nat-state=dstnat 
      in-interface=WAN1 PoE log=no log-prefix=""

So far this is what I have aside from DNS redirection and QoS.

sindy · Fri May 17, 2019 3:31 pm

So there is no chain=dstnat action=dst-nat in-interface=WAN1 to-addresses=the.ip.of.the.console rule in /ip firewall nat?

Lebzul · Sat May 18, 2019 3:48 am

So there is no chain=dstnat action=dst-nat in-interface=WAN1 to-addresses=the.ip.of.the.console rule in /ip firewall nat?

If I do that, the rule only works for one of the two consoles when connected directly to MT. If I want both, I need to activate UPnP. But, the problem is when I have the console behind another router.

Lebzul · Sat Oct 26, 2019 7:18 am

Retaking this unfinished threat:

If I do:

add action=dst-nat chain=dstnat comment=Console dst-port=1-65535 in-interface=WAN1 \
    protocol=tcp to-addresses=10.50.10.245 to-ports=3074
add action=dst-nat chain=dstnat dst-port=1-65535 in-interface=WAN1 protocol=udp \
    to-addresses=10.50.10.245 to-ports=3074

Game says OpenNAT but everybody else says Moderate or Strict. How can we have OpenNAT for a segment of IPs (multiple video game consoles) with the same WAN and avoiding UPnP?

Is this too much for RouterOS?

sindy · Sat Oct 26, 2019 9:32 am

Game says OpenNAT but everybody else says Moderate or Strict. How can we have OpenNAT for a segment of IPs (multiple video game consoles) with the same WAN and avoiding UPnP?
Is this too much for RouterOS?

Not only it is too much for RouterOS, it is too much for logic alone. Imagine two packets, both coming from the same address X.X.X.X in the internet to the single public (wan-side) address W.W.W.W of your router. Given that these two addresses are the only pieces of information you can use to decide whether to forward the packet to LAN-side address L.L.L.1 or to LAN-side address L.L.L.2, which L.L.L.? will you choose for each of the two packets, and why?

Lebzul · Sat Oct 26, 2019 2:39 pm

Not only it is too much for RouterOS, it is too much for logic alone. Imagine two packets, both coming from the same address X.X.X.X in the internet to the single public (wan-side) address W.W.W.W of your router. Given that these two addresses are the only pieces of information you can use to decide whether to forward the packet to LAN-side address L.L.L.1 or to LAN-side address L.L.L.2, which L.L.L.? will you choose for each of the two packets, and why?

Thanks for adding more light. Then, how do Wisps do? Do they assign a public IP to each client so they can have OpenNAT? What if they have like 100 clients?

sindy · Sat Oct 26, 2019 3:13 pm

Thanks for adding more light.

Actually, I have just simplified to the bare bone what I already wrote weeks ago.

Then, how do Wisps do? Do they assign a public IP to each client so they can have OpenNAT? What if they have like 100 clients?

Yes, exactly. Only those WISP's clients who have got a public IP can ever have "OpenNAT".

The good (for gamers) or bad (for overall security) news is that there is a way to let two devices, each behind a restricted NAT, to talk to each other via their respective NATs without any intermediate forwarding device staying in the path. This is only possible if any outgoing connection of each of these devices is always NATed to the same public IP (which is the case for almost all SOHO setups), and if the source port is preserved. If these pre-requisites are met, a broker device (the gaming server) learns the public IPs of both the devices, informs them both about the opposite one's address and tells them which ports to use for direct connection. So device A sends a UDP packet from port A to the public IP of the firewall/NAT of device B to port B. Hence A's firewall/NAT creates a pinhole expecting a response to its public IP and port A from B's public IP and port B. This first packet of the direct connection doesn't make it through device B's firewall/NAT from the internet to device B, but as device B has been instructed by the broker what to do, it nevertheless sends a packet from its port B to the public IP of A's firewall/NAT and port A. So B's firewall/NAT thus creates its own pinhole and forwards this packet to A's firewall/NAT, which treats it as a "response" to its own "request" packet (although it is actually not a response because the trigger event was not a reception of a request). Then, A sends another packet to B using the same source and destination port, which is treated as a "response" by B's firewall/NAT. As there is no actual state information in UDP, the firewalls have no chance to distinguish this from a normal initiation of an UDP exchange between a client on the private side of a firewall/NAT and a server in the internet, except if they would remember for a while each unsuccessful connection coming from outside and during that while, block matching packets from inside which it would otherwise let through.

Google for STUN if you are interested in more details.

Lebzul · Sat Oct 26, 2019 3:25 pm

Actually, I have just simplified to the bare bone what I already wrote weeks ago.

Yes, I noted that after I wrote this. Because that day it was too much for my layman's knowledge.

Yes, exactly. Only those WISP's clients who have got a public IP can ever have "OpenNAT".

I have 2. How can I have one for normal devices and the other one for 4 consoles? Can I send one Public IP to an entire subnet and the other one to the other?

Google for STUN if you are interested in more details.

Will read about it

sindy · Sat Oct 26, 2019 4:04 pm

Yes, I noted that after I wrote this. Because that day it was too much for my layman's knowledge.

It is normal that a correct information is useless until you get sufficient context.

How can I have one for normal devices and the other one for 4 consoles?

You cannot, still for the same reason. You can have as many consoles with "open NAT" as you have public IPs, not more.

Can I send one Public IP to an entire subnet and the other one to the other?

Theoretically, you could dst-NAT an incoming unicast packet (i.e. with a destination address matching a single device) to a broadcast address (at which all devices in a whole subnet are supposed to listen). But even if it worked (it actually doesn't because only few processes in the devices' operating systems actually listen at the broadcast address), it would still not be very useful because the packets from the same remote console would be received by all lccal consoles and they would all respond to them, causing a confusion at the remote console.

So it could be done like this, but the console developers would have to implement a matching behaviour:

each packet would have to carry an unambigous identification of the source in its payload (like the serial number or MAC address of the console), so that packets coming from the same public IP and port could be properly related to a stream at the receiving end.
the consoles would have to listen on a group address (broadcast or multicast, see below).

And console developers are unlikely to do this before the bulk of firewall/NAT developers implements the possibility to dst-NAT to broadcast addresses.
And none of this is going to happen - imagine the WISP case where 1000 or so SOHO routers are connected behind the same public IP on the private or "shared" addresses (from the 100.64.0.0/10 subnet), and the WISP has to broadcast the complete incoming traffic to that public IP to all of them because there is no way to tell which traffic is for consoles and which traffic is a "normal" one. So it would require an industry standard to be agreed on, and to use multicast addresses instead of broadcast ones, as you can selectively subscribe to multicast traffic whereas you cannot prevent broadcast traffic from being sent to you.

So the amount of effort spent and cooperation required is too high compared to the potential benefit for the vendors involved.

anav · Sat Oct 26, 2019 6:30 pm

Just to be clear, a single console behind the MK as the router, with UPNP on, should provide a full on-line gaming capability (not restricted in any way)??
or does one also need to include a specific destination NAT rule for that IP as well?

Sob · Sat Oct 26, 2019 8:03 pm

With UPnP enabled, device can open ports (= add dstnat rules) by itself as it needs them, no static dstnat rules are needed.

There are two possible problems:

- If the device has its mind set on exact port number and it's already taken by something else, it won't work.
- Device needs to be connected directly to router with public address, not behind some other router(s), because in that case it opens port on the one it's connected to, but upstream router won't know anything about it.

-

But the main problem is that people don't understand what being connected to internet means. Device truly connected to internet has public IP address. Not somewhere else, shared with several other devices, but one (or more) directly on itself.

Very simply, if every device in your network has public IP address (every single one that needs internet access), you're connected to internet, that's how it should be, it's grade A. If you get at least one public address from ISP and it's directly on your router, the whole thing is already half broken, but mostly usable, grade B (in relation to this thread, it's relatively ok as long as you have small network, but add few more distant subnets and you'll have problems with UPnP). If you get public IP address using NAT 1:1, it's grade C, it's bad but better than nothing. If you don't get any public IP address at all, it's grade D. It's like restaurant selling pizza chewed and spat out by previous customer. It's not all bad, it will fill you up, give you energy and everything. But would you really like a bite?

But there are not enough IPv4 addresses for everyone, right? That's correct, it was the reason why they invented IPv6 and it does have enough for everyone. More than twenty years ago that was. And rather then implementing it, we're still trying to find ways how to punch holes through NAT. There are ISPs who didn't even start with it yet. It's like treating broken arm with ointments. You can go to doctor and have it fixed properly, but why, when last month the honey extract made it feel a little better, surely with the right ingrediens there must be the way!

Rant over.

anav · Sat Oct 26, 2019 8:16 pm

Thanks so it should work with UPNP properly configured.
For internal interface should one identify the VLAN of that device, the IP of the device, the bridge its on etc???
External interface could be the Wan-interface-list or the primary WAN i suppose.

Another thought I have a cable connection which provides a single wanip address but I have connected the modem to two different routers (switch in between) and received two separate IP addresses.
I imagine I could
a. connect cable modem to switch
b. switch to current secondary ISP etherport on my MT router ie maintain current config
+++++++++++++++++++++++++++++++++++++++++++++++++
Then
c. switch direct to console device (but how does the device pull an IP directly from the modem).
OR
d. switch to unused etherport on MT router and somehow pass that onto the device directly 1:1 ?????? I get kinda vague at this point)

sindy · Sat Oct 26, 2019 8:40 pm

@anav, all of your suggestions are valid, but they rely on the ability of two consoles to coexist behind the same IP address. As @Sob has pointed out, if both insist on using the same port on the public IP, the slower one will fail.

If they are flexible, they don't need to care about NAT type as each of them will create its own pinhole (or a set thereof) by controlling the NAT behaviour using UPnP rather than adjusting their behaviour to an existing one. With the limitations outlined by @Sob - L2 transparency between the NAT device and all its UPnP clients.

IPv6 really means a "public" IP for each device ("private" IPv6 address ranges exist too but there is no real need to use them except for test purposes), but that's just one part of the thing. As soon as you want to use a firewall, you're back where you began, because to allow connections to your LAN devices to be initiated from outside, you have to know in advance to what ports to permit incoming connections statically, or have some protocol allowing the LAN device to tell it to the firewall dynamically, or permit full access to a particular LAN side device from outside, but in the latter case it is highly recommendable to isolate that device from the rest of your network so that it cannot spread the bug if infected.

anav · Sat Oct 26, 2019 8:49 pm

Hi Sindy, Im going to frame that positive feedback LOL.
In my selfish case there is one console in the house and thus I do not have dual console issues.
The upnp method I tried awhile back and it didnt work
I put the console on its own vlan it didnt work
I tried all kinds of route contortions including VRFF etc didnt work.

So I am desperate to try anything, so I am keen to try option B above where I connect cable modem, to switch
to unused port on MT router, I pull a WANIP but dont want to NAT it to my VLAN for that device, I want to 1:1 it so to speak, how do I do that??
(remember I already have another cable from the switch going to the router from that cable modem as my SECONDARY ISP for the WAN, the new connection would be a different WANIP strictly intenteded for the console on its own vlan).

If you want to freak me out recommend table main route rules LOL.

sindy · Sat Oct 26, 2019 9:40 pm

The upnp method I tried awhile back and it didnt work

That sounds like a misconfiguration to me. Normally there is not much to go wrong with UPnP function-wise; it is a security hole (but that's 1:1 dst-NAT too) but it is no rocket science to set up.

I put the console on its own vlan it didnt work

That's not needed for the required functionality, but having the console alone in a dedicated VLAN&subnet is a good way to protect the rest of your network from the console if it gets infected.

I tried all kinds of route contortions including VRFF etc didnt work.
...
If you want to freak me out recommend table main route rules LOL.

All that (VRF) is/would be (route rules, mangle rules) an overkill. As @Lebzul has already pointed out, it is enough to use a single dst-nat rule to forward anything that comes from outside to the console's private IP, and a single masquerade (or src-nat) rule for anything leaving through the WAN to be src-nated to that WAN's public IP. This setup is often referred to as a "DMZ" (De-Militarized Zone) one, but to deserve such name, the important part is that there is also a "protected zone", i.e. that the equipment in the DMZ doesn't have an unrestricted access to the rest of your internal network, i.e. that the DMZ and the protected zone are in distinct (V)LANs and subnets, and the firewall rules control which L3 traffic can pass between these two zones, not just the traffic between the internet and the LANs as a whole.

Sob · Sat Oct 26, 2019 9:44 pm

If you want to use UPnP, the key is to have public address on the same router which works as UPnP server. If it's there, then the interface with it is external for UPnP and the one with (directly) connected console is internal. In case there would be other address(es) on same external interface (probably not in this case), you'd need to specify correct public address as Forced External IP.

Sob · Sat Oct 26, 2019 10:18 pm

[IPv6]..., you have to know in advance to what ports to permit incoming connections statically, or have some protocol allowing the LAN device to tell it to the firewall dynamically, or permit full access to a particular LAN side device from outside, but in the latter case it is highly recommendable to isolate that device from the rest of your network so that it cannot spread the bug if infected.

There's PCP (Port Control Protocol) for dynamic configuration. Unfortunately, it's the same chicken & egg problem as with basic IPv6, level 2. Clients don't support it, so routers don't implement it. Routers don't support it, so clients don't implement it either. At least you have the last option, simply allow everything and isolate the device. There's so many addresses in IPv6 that each device can easily have a subnet for itself. Well, as long as ISP is not <insert your favourite rude word> who believes that one /64 must be enough for everyone.

anav · Sat Oct 26, 2019 10:34 pm

If you want to use UPnP, the key is to have public address on the same router which works as UPnP server. If it's there, then the interface with it is external for UPnP and the one with (directly) connected console is internal. In case there would be other address(es) on same external interface (probably not in this case), you'd need to specify correct public address as Forced External IP.

Okay I will go back to the basic UPNP attempt and looks like below.........

# oct/26/2019 16:06:00 by RouterOS 6.45.6
/interface ethernet
set [ find default-name=ether5 ] comment=Port5 name=Bell_eth5 speed=100Mbps
set [ find default-name=ether1 ] comment=Port1 name=Eastlink_eth1 speed=\
    100Mbps
set [ find default-name=ether4 ] comment=PI_DNS_RESOLVER name=eth4-PI
set [ find default-name=ether2 ] comment=LAN1-Home speed=100Mbps
set [ find default-name=ether3 ] comment=LAN1-Home speed=100Mbps
/interface bridge
add admin-mac= auto-mac=no comment=defconf name=HomeBridge \
    vlan-filtering=yes
/interface vlan
add interface=HomeBridge name=PS4_V55 vlan-id=55
add interface=Bell_eth5 name=vlanbell vlan-id=35
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add name=VLANSwInt
/ip pool
add name=dhcp-PS4 ranges=192.168.55.5-192.168.55.10
/ip dhcp-server
add address-pool=dhcp-PS4 disabled=no interface=PS4_V55 lease-time=1d name=\
    PS4-server
/ip dhcp-server network
add address=192.168.55.0/24 dns-server=8.8.8.8,1.0.0.1 gateway=192.168.55.1
/ip address
add address=192.168.55.1/24 interface=PS4_V55 network=192.168.55.0
/interface bridge port
add bridge=HomeBridge comment=defconf ingress-filtering=yes interface=ether2
add bridge=HomeBridge comment=defconf ingress-filtering=yes interface=ether3
/ip settings
set allow-fast-path=no icmp-rate-limit=100 rp-filter=loose
/interface bridge vlan
add bridge=HomeBridge tagged=HomeBridge,ether2 vlan-ids=\
  .....55,.....
/interface list member
add comment=defconf interface=Eastlink_eth1 list=WAN
add interface=vlanbell list=WAN
add interface=PS4_V55 list=VLANSwInt
add interface=PS4_V55 list=LAN
/ip dhcp-client
add add-default-route=no comment=defconf dhcp-options=hostname,clientid \
    disabled=no interface=Eastlink_eth1 use-peer-dns=no use-peer-ntp=no
add default-route-distance=255 dhcp-options=hostname,clientid disabled=no \
    interface=vlanbell script=":if (\$bound=1) do={ /ip route set [find commen\
    t=\"BellFibre\"] gateway=(\$\"gateway-address\") disabled=no; :log warning\
    \_(\"New ISP1 gateway: \".(\$\"gateway-address\")) }" use-peer-dns=no \
    use-peer-ntp=no 
/ip dns
set allow-remote-requests=yes servers=192.168.31.41 comment=pi-resolver
/ip dhcp-server lease
add address=192.168.55.5 client-id= comment=PS4 \
    mac-address= server=PS4-server
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related" \
    connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="Allow ADMIN to Router" \
    in-interface-list=RBwin log-prefix=AdminAccess src-address-list=\
    adminaccess
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
    connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
    connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="DROP ALL ELSE" log-prefix=\
    "INPUT DROP ALL"
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, " connection-state=\
    established,related
add action=drop chain=forward comment=\
    "Drop invalid/malformed packets" connection-state=invalid \
    log-prefix=INVALID
add action=accept chain=forward comment="allow VLANS  to WAN " \
    in-interface-list=VLANSwInt out-interface-list=WAN
add action=accept chain=forward comment=\
    "Allow Port Forwarding -  DSTNAT" connection-nat-state=dstnat \
    connection-state=new in-interface-list=WAN
add action=drop chain=forward comment=\
    "DROP ALL other  FORWARD traffic" log-prefix="FORWARD DROP ALL"
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN - Cable" \
    ipsec-policy=out,none out-interface=Eastlink_eth1
add action=masquerade chain=srcnat comment="SCR_NAT FOR LAN - FibreOP" \
    out-interface=vlanbell
/ip route
add check-gateway=ping distance=3 gateway=1.0.0.1
add distance=10 gateway=24......
add comment=BellFibre distance=3 dst-address=1.0.0.1/32 gateway=142...... \
    scope=10
add comment=Email_bypass distance=1 dst-address=24.222.0.20/32 gateway=\
    24.........
/ip upnp interfaces
add interface=vlanbell type=external
add interface=PS4_V55 type=internal

Lebzul · Sun Oct 27, 2019 6:21 am

Theoretically, you could dst-NAT an incoming unicast packet (i.e. with a destination address matching a single device) to a broadcast address (at which all devices in a whole subnet are supposed to listen). But even if it worked (it actually doesn't because only few processes in the devices' operating systems actually listen at the broadcast address), it would still not be very useful because the packets from the same remote console would be received by all lccal consoles and they would all respond to them, causing a confusion at the remote console.

So it could be done like this, but the console developers would have to implement a matching behaviour:
each packet would have to carry an unambigous identification of the source in its payload (like the serial number or MAC address of the console), so that packets coming from the same public IP and port could be properly related to a stream at the receiving end.

the consoles would have to listen on a group address (broadcast or multicast, see below).

And console developers are unlikely to do this before the bulk of firewall/NAT developers implements the possibility to dst-NAT to broadcast addresses.
And none of this is going to happen - imagine the WISP case where 1000 or so SOHO routers are connected behind the same public IP on the private or "shared" addresses (from the 100.64.0.0/10 subnet), and the WISP has to broadcast the complete incoming traffic to that public IP to all of them because there is no way to tell which traffic is for consoles and which traffic is a "normal" one. So it would require an industry standard to be agreed on, and to use multicast addresses instead of broadcast ones, as you can selectively subscribe to multicast traffic whereas you cannot prevent broadcast traffic from being sent to you.

So the amount of effort spent and cooperation required is too high compared to the potential benefit for the vendors involved.

I see. It's a time-consuming task. I think @Sob mentioned it, IPv6 is the way to go in order to avoid the mess. Unfortunately, where I live, I think it's years ahead. Maybe with ISP that offers fiber here but they charge like 300.00USD a month.

Lebzul · Sun Oct 27, 2019 6:26 am

Just to be clear, a single console behind the MK as the router, with UPNP on, should provide a full on-line gaming capability (not restricted in any way)??
or does one also need to include a specific destination NAT rule for that IP as well?

Well, for my personal console it's like target shooting. Sometimes I get OpenNAT in game and sometimes not. Public IP must be in the main MT. Dynamic entires from UPnP are like this one:

add action=dst-nat chain=dstnat disabled=no dst-port=3074 in-interface=WAN1 \
    protocol=udp to-addresses=10.50.10.122 to-ports=3074 comment="upnp 10.50.10.122: DemonwarePortMapping"

At least most PlayStation Network games require port 3074UDP to be opened in order to give pass to OpenNAT. Otherwise, will say Moderate.

Lebzul · Sun Oct 27, 2019 6:48 am

While I was playing with the dsnat I managed to get a TPlink router which is connected to MT LAN (IP 10.50.10.xxx), I was receiving OpenNAT in the game from the private IP (3rd port) of that TPlink router (Like: MT>---10.50.10.xxx--<TPLINK>---<192.168.1.xxx=PS3). I would like to know if by adding that router to a VLAN instead, and providing that VLAN a secondary Public IP, will the console receive again the OpenNAT characteristic by being in that "VLAN_Console subnet"?

If one client in MT with the proper dsnat rule used to get the OpenNAT to its DHCP-ed client (PS3), wouldn't it be the same to create a rule for the entire VLAN Pool? (Not sure if @sindy explained this. Sorry if yes), assuming if it was a normal router.

I believe that aside from UPnP, there should be a scape route. UPnP sometimes causes problems like for example in VRRP. I noted when second MT is Master and some Dynamic rules are requested, they are kept in the second MT, even if the real Master turns on again. I am not completely sure if this breaks the whole purpose of UPnP for video games because I just saw it but didn't test it.

sindy · Sun Oct 27, 2019 9:47 am

While I was playing with the dsnat I managed to get a TPlink router which is connected to MT LAN (IP 10.50.10.xxx), I was receiving OpenNAT in the game from the private IP (3rd port) of that TPlink router (Like: MT>---10.50.10.xxx--<TPLINK>---<192.168.1.xxx=PS3). I would like to know if by adding that router to a VLAN instead, and providing that VLAN a secondary Public IP, will the console receive again the OpenNAT characteristic by being in that "VLAN_Console subnet"?

If one client in MT with the proper dsnat rule used to get the OpenNAT to its DHCP-ed client (PS3), wouldn't it be the same to create a rule for the entire VLAN Pool? (Not sure if @sindy explained this. Sorry if yes), assuming if it was a normal router.

I wonder what in the words chosen by RouterOS authors, or in my own vocabulary, prevents you from understanding the same thing in multiple cases. Maybe the parameter name to-addressses? Yes, to-addresses in the nat rules is a pool, but for each connection, just a single address from that pool is chosen. The packet's header has space for a single destination IP address only, and the packets are not multiplicated by the firewall during the NAT operation.

So you can reserve a DHCP lease of an IP address for the console in the "VLAN_Console subnet" (use of "make static" command on an existing lease is the easiest way to do that), and use that reserved IP address as to-addresses in your dst-nat rule for that console (i.e. for packets arriving to port 3074 of your second public IP). So you'll have one rule per each public IP, each doing a dst-nat to one of the consoles' individual private addresses.

I believe that aside from UPnP, there should be a scape route. UPnP sometimes causes problems like for example in VRRP. I noted when second MT is Master and some Dynamic rules are requested, they are kept in the second MT, even if the real Master turns on again. I am not completely sure if this breaks the whole purpose of UPnP for video games because I just saw it but didn't test it.

That's again what I told you - VRRP only provides hardware redundancy for an IP address, aiming at the gateway role of the device currently running that IP address for the subnet for which it serves as a gateway. But VRRP knows nothing about UPnP and UPnP knows nothing about VRRP; you'd need a complete synchronisation of configuration and runtime context between the two routers on top of VRRP, and this is something not provided by RouterOS these days.

Sob · Sun Oct 27, 2019 8:54 pm

@anav: UPnP is service (server) running on your router. If it should work, client device must be able to connect to it. With your current firewall it can't (if it's not in adminaccess list, which I assume it isn't). I don't remember what ports are used, but I'm sure you'll find them (they may even be mentioned in this long thread). Or just enable all access with in-interface=PS4_V55 for testing and you can fine tune it later.

Lebzul · Sun Oct 27, 2019 9:37 pm

I wonder what in the words chosen by RouterOS authors, or in my own vocabulary, prevents you from understanding the same thing in multiple cases. Maybe the parameter name to-addressses? Yes, to-addresses in the nat rules is a pool, but for each connection, just a single address from that pool is chosen. The packet's header has space for a single destination IP address only, and the packets are not multiplicated by the firewall during the NAT operation.

Sorry for not getting it beforehand. Keep in mind that English is not my mother tongue, routing/networking is not my field and I just have like one year into this whole world. I haven't been receiving formal instruction on this, just trial and error (days and days of struggle sometimes) trying to figure out what I want. I have been like swimming against the flow of the river. Most of the time if I read about how these things work, I can get stuck in a simple sentence because up to now, I am not able to visualize "flows" of data/packets and all that "stuff"as they are explained here by the gurus. I am like trying to solve calculus problems with basic algebra knowledge. Anyhow, I appreciate so much the time you have given for explaining things so far.

So you can reserve a DHCP lease of an IP address for the console in the "VLAN_Console subnet" (use of "make static" command on an existing lease is the easiest way to do that), and use that reserved IP address as to-addresses in your dst-nat rule for that console (i.e. for packets arriving to port 3074 of your second public IP). So you'll have one rule per each public IP, each doing a dst-nat to one of the consoles' individual private addresses.

I was trying to do that but couldn't make it work. I don't know yet how to create a VLAN that works with the LAN so clients may receive IP addresses and internet. I managed to have them with IP but they didn't have internet. (I have this as a "knowledge wishlist")

That's again what I told you - VRRP only provides hardware redundancy for an IP address, aiming at the gateway role of the device currently running that IP address for the subnet for which it serves as a gateway. But VRRP knows nothing about UPnP and UPnP knows nothing about VRRP; you'd need a complete synchronisation of configuration and runtime context between the two routers on top of VRRP, and this is something not provided by RouterOS these days.

I just pointed this out because it was curious to me and I couldn't find any info for this case. I was thinking in having like scripts for removing those Dynamic UPnP entries but I did see today that the console kept OpenNAT while using the backup MT. So, no need for scripts or impossible things.

At the end, I just wanted to have my console, my brother's, and my cousin's OpenNAT all time with same WAN but it is not possible because the way it works. Because when one requests through UPnP for having OpenNAT, the other one loses it and so forth.

One question, does anybody know how WISPs solve the issue if they have just like a Comcast Cable Modem (one WAN)? How would they solve if 12 clients want public IPs?

anav · Mon Oct 28, 2019 5:11 am

@anav: UPnP is service (server) running on your router. If it should work, client device must be able to connect to it. With your current firewall it can't (if it's not in adminaccess list, which I assume it isn't). I don't remember what ports are used, but I'm sure you'll find them (they may even be mentioned in this long thread). Or just enable all access with in-interface=PS4_V55 for testing and you can fine tune it later.

The VLAN in question is included in forward rule with all other VLANs with access to the internet. Dont understand your ports comment??

sindy · Mon Oct 28, 2019 8:37 am

The VLAN in question is included in forward rule with all other VLANs with access to the internet. Dont understand your ports comment??

UPnP is a way for the LAN host to tell the router itself what nat and forward rules to add to the firewall.
So the incoming connection from the console to the router itself must be permitted in chain=input of /ip firewall filter.

As for the ports, UPnP is a service like SSH or HTTP, so the router listens for incoming UPnP connections on UDP port 1900. So you have to permit connections to UDP port 1900 which come in through the Tik's interface representing the console's (V)LAN. Do not restrict the rule to any address, just to in-interface and dst-port.

anav · Mon Oct 28, 2019 1:47 pm

The VLAN in question is included in forward rule with all other VLANs with access to the internet. Dont understand your ports comment??
UPnP is a way for the LAN host to tell the router itself what nat and forward rules to add to the firewall.
So the incoming connection from the console to the router itself must be permitted in chain=input of /ip firewall filter.

As for the ports, UPnP is a service like SSH or HTTP, so the router listens for incoming UPnP connections on UDP port 1900. So you have to permit connections to UDP port 1900 which come in through the Tik's interface representing the console's (V)LAN. Do not restrict the rule to any address, just to in-interface and dst-port.

you have lost me big time SINDY.
I thought UPNP replaced the need to do port forwarding and if the vlan is already permitted access to the WAN, then it should be good to go.
Now it seems your saying that on top of the above I need to.
a. create a firewall rule (input) allowing the IP address of the Console (lan) or the vlan interface to the router itself very bizarre~~
b. something about port 1900, why not just add that to a. and the input rule??
(does playstation use port 1900 or something why 1900, in my case its an X-box console).

Remember I have already told the upnp service what the internal an external interfaces are, why are more rules needed..................

sindy · Mon Oct 28, 2019 3:02 pm

I thought UPNP replaced the need to do port forwarding and if the vlan is already permitted access to the WAN, then it should be good to go.

UPnP is a way how a device on the private side of the firewall can tell the firewall device (the Tik in our case) which ports it wants to have forwarded to itself, instead of you setting those port forwards manually. Some devices may ask for tens of ports, so if you can take the associated risks, it is more convenient to manually set a single rule permitting access to the UPnP service than to manually set tens of rules to permit port forwarding from outside.

Now it seems your saying that on top of the above I need to.

as said, it is not on top, it is instead of (for the gaming console, that is - you may still have to keep other port forwards configured, for other private side devices which do not support UPnP)

a. create a firewall rule (input) allowing the IP address of the Console (lan) or the vlan interface to the router itself very bizarre~~
b. something about port 1900, why not just add that to a. and the input rule??
(does playstation use port 1900 or something why 1900, in my case its an X-box console).

You probably don't want the console (or any other device in your LAN) to have permanent complete access to all management services of your Tik (WinBox, SSH, ...). Hence you restrict it to a single UDP port 1900, which is the port at which Tik expects UPnP requests from private side devices.

Remember I have already told the upnp service what the internal an external interfaces are, why are more rules needed..................

UPnP configuration is UPnP configuration and firewall configuration is firewall configuration. I agree that some other applications do dynamically add rules to the firewall, but there it always has some added value in it (dynamic values in the match conditions must be included in those rules). For UPnP in particular, you may e.g. not want to permit access to UPnP to all devices connected via the "internal" interfaces. Hence the firewall is set separately. If you didn't mind devices in that VLAN to have full access to all Tik's services, you wouldn't set the firewall to block such access, would you?

anav · Mon Oct 28, 2019 5:05 pm

Im am feeling particularly dense today.

Please confirm to get Console working properly behind my MT (and Console is on its own vlan for security and simplicity)
Also assuming XBOX is upnp friendly.

a. UPNP service setup, internal vlan interface, external wan interface (takes care of port forwarding)
b. Filter rule 'FORWARD' VLAN to WAN (to allow traffic outbound and associated return traffic)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Plus Maybe??????
c. Filter rule 'INPUT" from vlan interface (or console) to router for what I dont get???????????????
/ip firewall filter
add chain=input action=accept ???????????????????????????????????????????????????

Sob · Mon Oct 28, 2019 6:00 pm

When you configure UPnP (enable it and set interfaces), it starts a service on router which listens to port opening requests from clients. But it's the same kind of service like any other (http, ssh, ...), they need access to their ports allowed, otherwise clients won't be able to connect and tell it their wishes.

/ip firewall filter
add chain=input in-interface=PS4_V55 connection-state=new protocol=udp dst-port=1900 action=accept comment="for UPnP"
add chain=input in-interface=PS4_V55 connection-state=new protocol=tcp dst-port=2828 action=accept comment="for UPnP"

xvo · Mon Oct 28, 2019 6:15 pm

c. Filter rule 'INPUT" from vlan interface (or console) to router for what I dont get???????????????
/ip firewall filter
add chain=input action=accept ???????????????????????????????????????????????????

For UPnP service on UDP 1900

You console needs a communication channel with the router for asking router to open some ports for it.
That rule is opening that channel.

anav · Mon Oct 28, 2019 9:20 pm

Thanks fella's for your patience, for some reason I keep forgetting that MT does not do anything extra on the programmers behalf, it all has to be manually programmed and assumes the idiot admin (me) actually knows what he is doing. I am curious though about TCP 2828?? (see below, found it).
Thanks to Sob for making me look that up LOL...........
https://wiki.mikrotik.com/wiki/Manual:IP/Services

Sob · Mon Oct 28, 2019 9:55 pm

Correction it's "paranoid idiot admin", simple "idiot admin" would not block any access from LAN.

Lebzul · Tue Oct 29, 2019 4:05 am

Thanks fella's for your patience, for some reason I keep forgetting that MT does not do anything extra on the programmers behalf, it all has to be manually programmed and assumes the idiot admin (me) actually knows what he is doing. I am curious though about TCP 2828?? (see below, found it).
Thanks to Sob for making me look that up LOL...........
https://wiki.mikrotik.com/wiki/Manual:IP/Services

Yes, it is like that. In fact, @Sob mentioned it here.
I was also missing that one. That's why UPnP was not working as intended. Because you're using VLAN, you don't need to point a list of addresses to it but to use instead the interface, am I right, right ?

Lebzul · Tue Oct 29, 2019 4:40 am

/ip firewall filter
add chain=input in-interface=PS4_V55 connection-state=new protocol=udp dst-port=1900 action=accept comment="for UPnP"
add chain=input in-interface=PS4_V55 connection-state=new protocol=tcp dst-port=2828 action=accept comment="for UPnP"

Sob, if I have a rule to "Accept Established, Related, and Untracked Connection Packets" in input, do I still have to add connection-state to the UPnP rules?

anav · Tue Oct 29, 2019 1:52 pm

Yes, I suppose i could use the address of the console but the vlan interface also works in this case.

The rest is purely a wild assed guess..................
As for NEW connection I think SOB is being politically correct and that dropping the new will not have any substantial affect.
Its more for the person reading the config to understand that the rule is trapping the first connection the rest handled by the established rule.
I included it because I dont want to disappoint him/her the next time I expose my config LOL.

Sob · Tue Oct 29, 2019 3:39 pm

It was special made for anav's firewall, to go with the rest of rules where connection-state is included. But otherwise, if you deal with established, related, untracked and invalid, then new is the only one left and you don't have to include it.

Lebzul · Tue Oct 29, 2019 4:47 pm

It was special made for anav's firewall, to go with the rest of rules where connection-state is included. But otherwise, if you deal with established, related, untracked and invalid, then new is the only one left and you don't have to include it.

Yes, I have a rule to accept only established, related, untracked and one for dropping invalid. Why is it not necessary to add new to the UPnP rule? (Keeping in mind that I have 2 gaming consoles)

sindy · Tue Oct 29, 2019 5:36 pm

Why is it not necessary to add new to the UPnP rule? (Keeping in mind that I have 2 gaming consoles)

Because, as @Sob wrote:

if you deal with established, related, untracked and invalid, then new is the only one left and you don't have to include it.

[me@MyTik] > ip firewall filter add connection-state=[Tab]
established invalid new related untracked

To say the in different (and more) words - as I wrote in this supercharged introduction into how the firewall works, the rules are checked against each packet top to bottom, and processing of a packet in a rule chain stops at the first rule to whose match conditions the packet fully complies (to be precise, it is also necessary that that rule's action is a final one - e.g. log or passthrough are not final actions so these do not stop the packet processing by the rule chain).

So if the first rule of your firewall chain accepts (established, related or untracked) ones, and the second one drops invalid ones, only new packets ever make it to the rest of the rules in that chain.

Lebzul · Tue Oct 29, 2019 7:30 pm

/ip firewall filter
add action=accept chain=input comment=\
    "Accept Established, Related, and Untracked Connection Packets" \
    connection-state=established,related,untracked
add action=accept chain=input comment="Allow ICMP" protocol=icmp
add action=accept chain=input comment="Allow OVPN VPN" dst-port=0000 protocol=\
    tcp
add action=accept chain=input comment="Allow L2TP VPN" dst-port=0000,0000 \
    protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=ipsec-ah
add action=accept chain=input comment="Allow PPTP VPN" dst-port=0000 protocol=\
    udp
add action=accept chain=input protocol=gre
add action=accept chain=input comment="Allow Web Proxy" dst-port=0000 protocol=\
    tcp
add action=accept chain=input comment=" Allow UPnP-TCP" dst-port=2828 \
    log-prefix=UPnP protocol=tcp src-address-list=UPnP_Devices
add action=accept chain=input comment=" Allow UPnP-UDP" dst-port=1900 \
    log-prefix=UPnP protocol=udp src-address-list=UPnP_Devices
add action=drop chain=input comment="Block Invalid Packets" connection-state=\
    invalid
add action=drop chain=input comment="Block Web Cache Attacks" dst-por
    in-interface=WAN1 protocol=tcp
add action=drop chain=input comment="Block DNS Attacks" dst-port=53 \
    in-interface=WAN1 protocol=tcp

Yes, I wanted to clarify my setup and making sure that UPnP will work as it is intended. I got the accept ones as first but I have read that drop rules should be after all input ones. But also, I have seen that rules for accepting "Established, Related, and Untracked Connection Packets" they have the drop one just after as you're explaining.

Then, it comes to my mind:
1- Keep it as I have it right now.
2- Keep Input and drop afterwards and everything else as in the example.

Which one is the best approach?

Sob · Tue Oct 29, 2019 7:57 pm

- Rules are processed in order from top to bottom
- Default action (if no rule matches) is accept

Knowing that, you can see that most of your current firewall is useless, because what you accept would be accepted anyway at the end. And if you did that in order to block other stuff, then bad news, it isn't blocked now. Only those three drop rules block something.

One popular approach is to end firewall with unconditional drop at the end ("/ip firewall filter add chain=input action=drop" as very last rule), which will block everything not specifically allowed before. If you do that, your accept rules will make sense. And you also won't need your other drop rules anymore (except the one for connection-state=invalid, put that right after accepting established & friends), because all that will be blocked by the last rule. Just be careful before you add and enable this unconditional drop, you could easily lock yourself out. At first add only logging rule ("/ip firewall filter add chain=input action=log log-prefix=block") and watch what it logs. Try to connect to router again and make sure that this connection is not logged as to be blocked. It will be, because I don't see any rule to allow admin access. So add accept rule for that (preferably limited only to trusted addresses). Only then enable the actual drop rule.

sindy · Tue Oct 29, 2019 10:44 pm

In your post, I found two places which bother me:

I got the accept ones as first but I have read that drop rules should be after all input ones.

2- Keep Input and drop afterwards and everything else as in the example.

Whereas accept and drop are actions of a rule, input is a name of the chain to which the rule belongs (which, for embedded chains, matches the path of the packet through routing and firewall). So first of all, did you actually have accept in mind where you wrote input at the two places above, or is the concept of chains not clear to you?

Other than that, drop rules may be interleaved with accept rules; it depends on the match conditions of the individual rules whether the result will make sense or not. I think everything about this is in the post I've linked today, but just as a brief example of what you might place after the obligate "accept established,related,untracked, drop invalid" pair:

1. drop incoming traffic to port 22 from address range 192.168.1.1-192.168.1.5
2. accept any incoming traffic from subnet 192.168.1.0/24
3. drop everything

This means that any incoming traffic will be accepted from any address in the whole subnet 192.168.1.0/24 - rule 2, except ssh traffic coming from the range 192.168.1.1-192.168.1.5 (which is a subrange of that subnet) - rule 1, and nothing else will get through in general - rule 3. Like most of the illustrative examples, this one has also little practical usability, but more practical and less illustrative uses of "exceptions from exceptions from exceptions" do exist.

Lebzul · Wed Oct 30, 2019 1:00 am

I am sorry for making you be annoyed but right now, if I tell you that I know what is input or forward or how do they work, I would be lying. I might read and maybe understand a few things, but do not comprehend at all most of the time.

What I have been doing this year (my profile here says when I started this Mikrotik world from 0) long is researching, testing, and seeing if what I've done is working. (Like swimming against the flow because I don't have any another option. I don't have anybody to whom I could count on and discuss things like these rather than here).

It would be easier for me that someone at least make my mistakes in bold so I can start figuring out the fix click on-click back. I feel like, the kid who wants to know how much is 1+2 and the teacher comes with the etymological explanation of arabic numbers and the conception of 0s and 1s in ancient Egypt in order to explain the result. I really appreciate all the effort and time put into those lines explaining everything here, but my knowledge does not reach those kind of explanations (in addition that English is not my mother tongue and that adds another layer of complexity).

I did this, this may be wrong for sure. I would like just to know what is wrong and what is correct. (Like this is right, this is not; This is right, this one no).

/ip firewall filter
add action=accept chain=input comment=\
    "Accept Established and Related Connection Packets" connection-state=\
    established,related
add action=drop chain=input comment="Block Invalid and Untracked Packets" \
    connection-state=invalid,untracked
add action=accept chain=forward comment=\
    "Forward Accept Established and Related Connection Packets" \
    connection-state=established,related,untracked
add action=drop chain=forward comment=\
    "Forward Block Invalid and Untracked Packets" connection-state=\
    invalid,untracked
add action=accept chain=input comment="Allow ICMP" protocol=icmp
add action=accept chain=input comment="Allow OVPN VPN" dst-port=0000 protocol=\
    tcp
add action=accept chain=input comment="Allow L2TP VPN" dst-port=0000 \
    protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=ipsec-ah
add action=accept chain=input comment="Allow PPTP VPN" dst-port=0000 protocol=\
    udp
add action=accept chain=input protocol=gre
add action=accept chain=input comment="Allow Winbox from OVPN" dst-port=0000 \
    protocol=tcp src-address=10.50.25.50-10.50.25.60
add action=accept chain=input comment="Allow Winbox from L2TP" dst-port=000 \
    protocol=tcp src-address=10.50.20.50-10.50.20.60
add action=accept chain=input comment="Allow Winbox from PPTP" dst-port=0000 \
    protocol=tcp src-address=10.50.15.50-10.50.15.60
add action=accept chain=input comment="Allow Web Proxy" dst-port=0000 protocol=\
    tcp
add action=accept chain=input comment=" Allow UPnP-TCP" dst-port=2828 \
    log-prefix=UPnP protocol=tcp src-address-list=UPnP_Devices
add action=accept chain=input comment=" Allow UPnP-UDP" dst-port=1900 \
    log-prefix=UPnP protocol=udp src-address-list=UPnP_Devices
add action=drop chain=input comment="Block Web Cache Attacks" dst-port=8080 \
    in-interface=WAN1 protocol=tcp
add action=drop chain=input comment="Block DNS Attacks" dst-port=53 \
    in-interface=WAN1 protocol=tcp
add action=drop chain=input dst-port=53 in-interface=WAN1 protocol=udp
add action=reject chain=forward comment="Adblock - TCP-Reset" connection-state=\
    new dst-address=240.0.0.1 log=yes log-prefix=ADBLOCK protocol=tcp \
    reject-with=tcp-reset
add action=reject chain=forward comment="Adblock - UDP-Unreachable" \
    connection-state=new dst-address=240.0.0.1 log=yes log-prefix=ADBLOCK \
    protocol=udp reject-with=icmp-network-unreachable

Sob · Wed Oct 30, 2019 2:20 am

Few points to get you started:

1) Packets to router itself (e.g. when you connect to WinBox, or when VPN client connects to VPN server on router) go to chain=input. Packets passing through router (traffic from LAN to internet, traffic from internet to internal server using dstnat, traffic from VPN tunnels to LAN, ...) go to chain=forward. It's always one or the other.

2) Default action is accept. You can imagine that your firewall has these two rules at the end:

/ip firewall filter
add chain=input action=accept comment="accept everything (implicit invisible rule)
add chain=forward action=accept comment="accept everything (implicit invisible rule)

You don't see them, but it behaves as if they were there. So it's not that your firewall would be completely wrong, you just didn't account for this.

3) Just a small one, untracked state is good one, you want to accept it. The name may sound dangerous, but packets will become untracked only when you tell them to be (in /ip firewall raw), so it's nothing to worry about (and you probably won't do anything with that anyway, at least at the beginning).

-

It's really good idea to understand how firewall works, in what order things happen. You can get some info from post linked by sindy. Or if you're more into images, there are some in manual (https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6). But it's scary stuff, so here's beginner-friendly version:

routing.png

Packet coming to router (from LAN, internet or anywhere) starts at (I). The others are (L) for packets leaving the router and (K) for packets from local process and (J) for packets to local process (both are moved to right circle in simplified version). Rectangular boxes (prerouting, input, forward, output, postrouting) consist of multiple steps and you can see them in next image:

routing2.png

Look at it, follow the arrows, think about it. It's not difficult at all. Right, anav?

Who is online