I have a cloud core setup in a apartment complex. We are only given 15 public IP’s from the ISP. We have 200 apartments in this hotel. I have vlan the network out and set up private ip ranges on each vlan to help the tenants get online. When I have a tenant that would like a public IP I just setup a 1 to 1 nat. In the past this has worked fine. I now have a tenant who is trying to setup his xbox one behind a router and he is complaining about a strict nat type with the above setup.
Basic Solution:
Does the masquerade action have a match criteria that limits it to packets going out the WAN interface?
If not, then it seems that new connections from the Internet to the user’s public IP would get masqueraded to appear as if they are from the Mikrotik’s internal IP address. Most users don’t see this because reply packets on existing sockets don’t go through the chains, state tracking maps them back automatically.
Remember that packets will go through both the source and destination NAT chains.
MacGuyver solution:
If making the masquerade rule more strict doesn’t fix things, then you could always try to forward it directly to them in stead:
Change the dstnat/srcnat rules:
– src-address=xxx.xxx.xxx.xxx action = accept (pass the public IP through w/o NAT)
– dst-address=xxx.xxx.xxx.xxx action = accept (ditto)
Static route xxx.xxx.xxx.xxx/32 next-hop = LanInterfaceName
WAN interface, set arp=proxy-arp
LAN interface, set arp=proxy-arp
After doing all of that, the user can actually put their static IP address directly on their equipment, and you won’t be doing any NAT for them. They should set their netmask / default GW to be the same as the Mikrotik uses.
If you want to keep other users from stealing their public IP, you can add a static ARP entry with the correct users’ MAC address.
Specific nat rules for specific customers with specific public IP mappings come first.
Then yes, one last rule for 10.0.0.0/8 will work for all 212 vlans.
Remember - all of these attributes are just “things which must be true in order to do the action of this rule”
I would personally not use the src addresses at all -
I would just say “out-interface=wan” as the only criteria.
This way, vlan23 <> vlan198 does not masquerade. If such traffic happens, you would rather see the real source IP and not get a call “your router is trying to hack my laptop!!!”
To block all 212 vlans from talking to each-other in four rules:
Of course, if customer in vlan38 has a server with a public IP, you’ll need to create an exception after out-interface=wan rule but before action=drop rule. so that other customers can reach the server just like the rest of the internet can.
Just incase I have to go this way the rules I assume would be
/ip firewall nat
add action=dst-nat dst-address=xxx.xxx.xxx.xxx action=accept
add action=src-nat src-address=xxx.xxx.xxx.xxx action=accept (this should be public ip correct?)
Yes, the public IP you want to assign to the customer.
Example - say the IP is 190.0.2.22 and the interface that the customer is on is ether4:
/ip route add dst-address=190.0.2.22/32 gateway=ether4
I’m going to read back over this thread now - I don’t think the MacGuyver solution is required - it’s just cool because it lets the customer have the IP actually on their own gear directly.
See if this helps your situation.
You could keep from turning it on everywhere by just adding the external interface and the one interface towards this customer.
Double NAT is also mentioned as a problem, so if pushing the “yes to UPnP” button doesn’t fix everything, then consider how you can eliminate double NAT (if he is in fact behind 2 or more NATs, that is…)