We want to do this:

Internet<->MikroTik in Bridge Mode with Firewall Filter<->Hosted Server

  1. The primary objective is to allow RDP and FTP in from the outside but block everything else from the outside. From the inside everything must go out.

  2. The problem we are running into is we add these rules and blocking outside to inside is working, but now the hosted server cannot access anything to the outside. The return TCP/IP from the outside is not port 3389 or port 80, but random.

/interface bridge filter> pr

Flags: X - disabled, I - invalid, D - dynamic 0 ;;; Accept ICMP for PING chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 ip-protocol=icmp

1 ;;; Accept FTP Transfer Port chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 dst-port=20 ip-protocol=tcp

2 ;;; Accept FTP Control Port chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 dst-port=21 ip-protocol=tcp

3 ;;; Accept RDP chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 dst-port=3389 ip-protocol=tcp

4 ;;; Log everything that is about to get dropped chain=forward action=log mac-protocol=ip dst-address=196.x.x.x/32 ip-protocol=tcp log-prefix="firewall_drop"

5 ;;; Drop everything chain=forward action=drop mac-protocol=ip dst-address=196.x.x.x/32 ip-protocol=tcp

Just FYI bridge is set to use firewall and connection tracking is on.

  • 1
    You enabled connection tracking? Needed - mark connection as ok. Second, why bridge mode? Get an extenrnal transfer IP, then route properly internally, like most do. – TomTom Feb 13 '12 at 12:33
  • Yes I enabled connection tracking. I don't understand "Needed - mark connection as ok". Do you have an example of "externally transfer IP, then route properly internally". Please bear in mind that I have public IPs externally and hosted server with public IPs "internally". – Eugene van der Merwe Feb 14 '12 at 6:35
  • It's been a year and we never succeeded in getting this working. In addition the MikroTik bridge/firewall occasionally stopped working (due to 100% CPU) completely blocking off our network. We're very close to abandoning this configuration. – Eugene van der Merwe Mar 9 '13 at 9:13
  • Consder hiring someone who knows what he is doing. Also consider whether your mikrotik simply is too small. I run that stuff - in a much larger and more complex scenario - without any issues. – TomTom Mar 9 '13 at 9:35
  • 1
    Don't bridge, route. – hookenz Dec 16 '13 at 21:49

I suggest to use local ip subnet for your server and have private LAN between mikrotik (router) and server. Also have mikrotik directly on public ip. Then do the ip src-nat for outgoing traffic (from server to internet). All incoming traffic should be port forwarded (dst-nat). Also you can use normal layer3 ip firewall and disable layer3 firewall for layer2 / bridge network.


This has something to do with connection tracking, but I don't know exactly how it works in a bridge. I would just add another rule to allow everything from inside with src-address or interface:

add chain=forward action=accept mac-protocol=ip src-address=196.x.x.x/32 ip-protocol=tcp place-before=4 
  • The problem with a bridge is that you don't really have a src-address or interface, you only have two bridged interfaces which are really all the same thing. It's not like a normal interface that actually has source and destination. Imagine a bridge like a single Ethernet cable but you can't really say which side is which. – Eugene van der Merwe Mar 9 '13 at 9:09
  • You can use src-address. There is also in-interface available but I'm not sure it works, because, as you've said it's like running an ethernet cable. Have you tried the above command? I think it should work. – Jure1873 Mar 10 '13 at 16:48

I agree with @Matt that bridging was a stupid idea and that we should have routed from the start. The entire reason why we bridged was because our border router was a legacy Cisco VXR 7206 with two interfaces, a WAN (ATM) and LAN (used for public) interface. We wanted to firewall stuff on public without re-sub-netting our network. Also, although @DJ_Kukky's suggestion of using DST-NAT is plausible that would have led to much more configuration and also we can't (or won't) give our clients private IPs as we're a public facing ISP.

We should have either implemented the firewall rules on the Cisco or replaced the technology (ATM). In the end we replaced the ATM with MetroEthernet and we were able to establish the outside interface on an Ethernet interface and as such use MikroTik. It's working really well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.