I run several neighborhood relay stations, each consisting of a Routerboard, a backhaul radio, and a neighborhood AP radio.
My standard configuration is a neighborhood AP at 192.168.3.N, with CPE radios at each subscriber location. Each subscriber’s CPE is configured to a known static address 192.168.3.[A,B,C,etc.] to simplify administration and trouble detection, and is directly addressable from our NCC.
Each CPE unit is itself a router, handing out LAN addresses in the 192.168.10.0/24 range to devices within the building.
Our next relay station is going to be hosted by a property owner who also wants to use the service. (Oddly, this situation has never previously arisen!)
In place of the CPE that everyone else gets, we just want to have him plug into the POE ethernet port that is going to be running into his house anyway. I’ve configured the POE port as 192.168.10.1 and set up an appropriate DHCP server to hand addresses out to his personal devices. However, I want his traffic to be NATted through a unique identifying address 192.168.3.P (just like every other subscriber) and then NATted again out the backhaul just as everybody else’s traffic is.
I can’t quite wrap my brain around how to do this double-NATting inside the same node. I think the proper configuration command is:
If you have a separate ethernet port available, you can simply connect the owner’s LAN to this port.
Assign to the interface an ip address like 192.168.10.1/24, setup a DHCP server for class 192.168.10.0/24, gateway 192.168.10.1, preferred DNS, and so on.
Add a NAT masquerading rule (src-nat): from that interface, ip range 192.168.10.0/24 to something like 192.168.3.y (your first NAT level).
This way, the owner LAN will act exactly like any other customer: you will see it as a unique address 192.168.3.y.
Perhaps. Yet my queues, traffic algorithms, firewall filters, activity meters, and other functions are all keyed to addresses in the 192.168.3.x range. The easiest way to handle this user just like all our other users is to assign him an address in this range. If he were hooking up just one computer, I’d just assign some address in that range to the POE port. But he will be installing a switch inside his house to hook up multiple devices, so I have to simulate that level of router as well. I’d be happy just to provide him a physical SOHO router, but it’s a battle I don’t want to start if I don’t need to. I figured that the Mikrotik OS certainly must have the brains to do this job, assuming I can match its brains myself.
It seems to me you are saying exactly the same thing I said in my original post. Now I hope I can get you to confirm more positively whether or not the configuration command I provided will do the desired job, or (if not) which others I will be needing to add. The problem is that a literal “nat masquerading” rule needs an output interface specified, but 192.168.3.y isn’t an actual interface, just a manufactured IP address sort of hanging in midair. Hence, I tried a variant rule in hopes it would accomplish what was needed.
You cannot do that. http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Source NAT happens only in the postrouting chain, which is only hit when the router has determined the interface to route the packet out of. You cannot source NAT to one IP address when the packet enters the router, have it processed with the modified header, and then source NAT to a second IP address when the packet leaves the router. Packets simple don’t flow through the router in a way that makes that possible.
I would deploy a router for his house. Not only will it make him a normal customer as far as configuration goes, you will also retain a clear demarc. Backbone equipment shouldn’t connect to customers directly so that the CPEs can be configured to protect the backbone from malicious customer traffic, be it accidental or intentional.
Thank you for the clear explanation. The “packet flow” diagram has always hurt my head, so I still don’t intuitively understand it, but I know I will have to conquer it someday before I can achieve guruhood.
Looks like I will just toss in a preconfigured wired router inside his building and tell him it’s a standard part of the interface equipment.
The ip firewall rule you wrote before seems to be correct.
Of course you also have to assign the IP address 192.168.3.y to the WAN interface (or bridge interface used to bridge together wlan and ethernet).
Moreover, you have to specify a default route available for 192.168.3.y (same ip class).
I know this is an ancient thread, but I did achieve what I wanted to do and it was much simpler than I thought. I wanted to post the solution for people who may be searching through the archives to solve the same problem.
I reserved the address 192.168.3.254 to represent the customer hosting the router, and assigned 192.168.3.254/24 to the AP interface (for clarity / OSPF purposes).
This makes the customer look to the rest of the system like he is just a standard wireless customer with a CPE at 192.168.3.254, and he gets routed, queued, QOSsed, and bandwidth-limited just like any other customer.
The major mental leap was that I didn’t have to use masquerade at all, just src-nat.
