Hello Everyone,

We deploy quite a few RB2011s in the field, mostly setup in Bridging Mode.. We utilize Eth10 as a DHCP Port that plugs back into the Customers Router and our units will run a script to communicate back to our server for updates, etc. Using this Pull Method, we can force updates to the Firewall rulesets, etc remotely when the firewall is bridged.

However like Firewalls setup in a more Managed way with a Wan IP assigned, we would like the same level of access when we deploy Firewalls in a Bridged Mode like a dedicated WAN IP (our support address allows this remote access). Would like to pop open WinBox, put in Clients IP and still manage it instead of waiting for the push/pull of our Centralized Server.

I tried setting up a src-net forwarding the Winbox Port 8291 to the DHCP IP but was no go unless I setup the rule incorrectly.. Wondering how we can accomplish the same level of remote control when we install these as Bridged Appliances vs WAN Configured IPs. More so I would like to use a non-standard port to forward to the Winbox Port from the outside if possible and to avoid local conflict if we want to use Winbox Internally and utlize the normal 8291 port.

Is this possible?

Can't you just add a management IP address to the bridge and then point to it?

How do you mean? In most configurations we use bridge to not interfere with say an ISP Modem uplinking to the the WAN on our device and then bridging the lan to customers WAN router or netgear, asus, dlink so the wan address goes to the customers device.

So if we put an ip on the bridge interface, would this kill that traffic or make it so it’s not plug and play for customers? Would it get dhcp and where would it get the ip from, cable modem or customers router? We would also need to ensure that this device could still get 80/443 access to run the management scripts to download from our management server so trying to understand what this would do.

Thanks!

I'm sorry, I wrongly assumed that you are also the ISP, so you would be able to add another network on top of the WAN access.

You can surely put an IP address in the bridge interface without it being cause of any problem, unless you put the same IP used in that network segment.

According to https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6 the src-nat should work given that you have enabled firewall on bridge. However you need to point to the IP assigned to the bridge.

Let me know if it's clear enough. And if it works

I will give this a test later today.. Assign a manual random IP out of scope of the Customers LAN to the Bridge Interface, I should be able to SRC-NAT the Winbox Port from External WAN IP to the Bridge IP for Winbox Access? That sound correct?

Thank you!

You should DST-NAT.
You have to change from the public IP of the customer router to the out of scope IP assigned to the bridge. Make sure to also check the return path.

So Im slightly confused, your first response was a SRC-NAT, but I need a DST-NAT?

How would the rule look?

Type: DST-NAT
SOURCE IP: WANIPOFCUSTOMER
DEST IP: 192.168.199.1 (Bridge IP)
PROTOCOL: tcp(6)
DST PORT: 8291

?

Also need to create a Firewall Rule in the ACL?
Input - Port 8291, From WANIP to 192.168.199.1?

I'm sorry, my fault. dst-nat is right.
And of course modify the firewall filter rules accordingly, input chain.

So I ran through a couple of tests - I was able to see the traffic hit both of the counters NAT and Firewall ACL, however would not connect for management via Winbox. The IP I assigned to the Bridge was 192.168.199.1/32. Any ideas/Seemed like we got closer since I can now NAT and see traffic hitting both ends.

Thanks for your help so far.

I think it's a matter of packet replies, or better: outgoing packets from router.
I am stuck because I can't think of a method to send the packets directly to the gateway from the bridge...
I will ponder about it but if anybody has other proposals they are welcome

So I'am reviving this thread to give an update on what we have done. From the Bridge Perspective, its working as design. We insert a Mikrotik between the cable modem or ISP router and the customers router or Firewall, and then take a port outside of that bridge for DHCP, which then gives it an Internal IP on the Customers Network.

We have came up with a SSTP Tunnel that tunnels out of the customers network over 443 to a CHR in the Cloud.. Added some Firewall ACLs to restrict the tunnel traffic to only the MGT IP on the other side (prevents the cust router from talking to other SSTP clients in the DHCP Pool) and to block the customers LAN network from routing over the SSTP MGT tunnel, we now have a working solution to manage "Bridged" Appliances as if they have a Public IP. We can connect to the CHR and SSH or Winbox into the customers Router that doesn't have a public IP. Was a pretty eloquent solution but works great. Later I am going to setup IPSEC from the CHR to our Corporate Firewall and then we wont even need to log into the CHR, except to find out the Clients "SSTP IP", which we will build a website to map the Identity of the Router to SSTP IP on the CHR which we would use to log into them.

We primarily use Mikrotik's as Firewall appliances due to the PSD, Tarpit and Dynamic list, so thats why this was important to us as we had no way to directly manage Bridged Appliances, except with a script that checks into our Central Management portal every so often for Threat Intel updates. This also meant if a customer needed something disabled, our Dev would build a patch and have to do the work to push it out to that customer only, so it could take some time if other tasks were in line. Hopefully other people find use in this post, we have a ton of CHR Licenses from Training and attending MUM so our real cost was only setup of the Virtual Server in the cloud and some time to test and tune SSTP. But realistically a company or ISP could do the same thing and setup a cloud box (or NAT'd at Corp) and manage all your routers behind customer firewalls from a central location via SSTP without NATs.. Just be sure to lock access to it down Since your not routing real traffic over it, the consumption of resources and bandwidth is basically NILL. The only time traffic should go over the SSTP tunnel is if an active connection is opened for Management Activities.