Can anyone point out what i have done wrong here? I have set up some dstnat rules to open specific ports to my server behind the firewall at 192.168.1.3.
These rules are working, but my server’s access logs report external access as being from the router’s own IP, eg. 192.168.1.1, instead of from the originating IP. Have I misconfigured dstnat somewhere?
Here is my config:
[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; default configuration
chain=srcnat action=masquerade out-interface=sfp1-gateway
1 ;;; default configuration
chain=srcnat action=masquerade out-interface=(unknown)
2 chain=srcnat action=masquerade out-interface=pppoe-out1
3 ;;; Port forwarding for external SSH into internal server
chain=dstnat action=dst-nat to-addresses=192.168.1.3 to-ports=22 protocol=tcp in-interface=pppoe-out1 dst-port=22
4 ;;; Port forwarding for external IMAPS into Dovecot
chain=dstnat action=dst-nat to-addresses=192.168.1.3 to-ports=993 protocol=tcp in-interface=pppoe-out1 dst-port=993
5 ;;; Port forwarding for external MTA transfer into Postfix
chain=dstnat action=dst-nat to-addresses=192.168.1.3 to-ports=25 protocol=tcp in-interface=pppoe-out1 dst-port=25
I also suggest you create a explicit drop rule on the forward chain.
Now you are allowing all traffic towards the inside of your network.
If you have created that block rule like this
/ip firewall filter
chain=forward action=blockyou should also create allow rules before the drop rule for the system that needs to be access from the outside.
Keep in mind that dst-nat will occur before filter, so your filter should contain the dst-nat rule to-address IP.
something like
chain=forward action=accept protocol=tcp dst-address=192.168.1.3 dst-port=22 in-interface=
Thanks very much for those replies! @SurferTim - I removed the masquerade line with the ‘unknown’ interface and now observe the correct originating IP in my server logs - so, original question sorted Thanks.
@Rudios - thanks also, I forgot that there should be an accompanying firewall rule for each NAT rule! This has helped me close a potentially nasty security hole!!
I had to add a forward accept rule on my local bridged interface (filter rule 7) before the drop all rule as my internal internet access stopped working for all ‘new’ connections. (I hope I have done this correctly). I’m lucky I didn’t get locked out at this point as I’m logging in remotely via SSH on my internal server!
What I can’t understand now is that port 25 is no longer open but 22 and 993 are (and accepting connections). I can’t see a reason for this!
Here is my edited config:
[admin@MikroTik] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; default configuration
chain=srcnat action=masquerade out-interface=sfp1-gateway
1 chain=srcnat action=masquerade out-interface=pppoe-out1
2 ;;; Port forwarding for external SSH into internal server
chain=dstnat action=dst-nat to-addresses=192.168.1.3 to-ports=22 protocol=tcp in-interface=pppoe-out1 dst-port=22
3 ;;; Port forwarding for external MTA transfer into Postfix
chain=dstnat action=dst-nat to-addresses=192.168.1.3 to-ports=25 protocol=tcp in-interface=pppoe-out1 dst-port=25
4 ;;; Port forwarding for external IMAPS into Dovecot
chain=dstnat action=dst-nat to-addresses=192.168.1.3 to-ports=993 protocol=tcp in-interface=pppoe-out1 dst-port=993
I am using this router in a SOHO environment. I had previously used the more ‘user friendly’ home routers but went for Mikrotik as I wanted a more customisable router… It sure is that! And i sure am learning a lot about networking in the process!
I’m a little confused about your outgoing interfaces.
Are you really having two gateways, the sfp and the pppoe interface?
I assume that you are using a pppoe interface. If so, do remove the sfp-related stuff.
Also I suggest to change the input chain rule for blocking from your incoming gateways.
Just create an accept rule with the in-interface assigned your local network, and after that, block everything.
And about your blocked port 25, did it work before you changed the rules, or is your ISP possibly blocking that port?
Also if you would like to be able to connect from the outside, allow the desired ports in your input chain!
Hi, Yes the SFP interface is not used, it was created by default. I have removed the filter rule. Should I delete it from the interfaces list as well?
Also I suggest to change the input chain rule for blocking from your incoming gateways.
Just create an accept rule with the in-interface assigned your local network, and after that, block everything.
Could you please give me an example of this?
Am I right in thinking my “local network” is the bridge-local interface? The bridge contains ether2,3,4,5,6. ether7-10 are slaved from ether6.
Port 25 was accessible with the previous config yesterday, but is not accessible today. I’m not sure if it’s after changing the rules or not. My ISP have assured me that they don’t block any ports at all. I tried changing the dstnat port (and filter rule) to 2525 and this was not accessible either!
Also if you would like to be able to connect from the outside, allow the desired ports in your input chain!
I assume you mean to administer the router itself? I would not normally want to do this from outside, so I am using SSH on my server as a terminal into my internal network. I didn’t see the point in opening up more avenues for attack.
You can’t delete it from interfaces, you can only disable it.
Also I suggest to change the input chain rule for blocking from your incoming gateways.
Just create an accept rule with the in-interface assigned your local network, and after that, block everything.
Could you please give me an example of this?
Am I right in thinking my “local network” is the bridge-local interface? The bridge contains ether2,3,4,5,6. ether7-10 are slaved from ether6.
…
I have created rules like this
/ip firewall filter
chain=input action=accept src-address= in-interface=<your local network interface, indeed bridge-local>
chain=input action=dropIn between the two rules, I have some accept rules for traffic from outside, but as your story goes, that is not needed.
Hello again,
I seem to be getting there now! One day hopefully this will be as trivial to me as it is to you! @Rudios, I followed your advice, but found new internet connections from inside failed. It became apparent that this was because DNS requests were not being allowed via the router. (If I did an nslookup and specified a DNS server, the request was successful, but failed if I did not explicitly specify a DNS server).
I found rules 2 and 7 (below) to be necessary, but can do without rule 3.
Also, given that rule 12 is an indiscriminate drop, is rule 11 redundant?
Still no luck forwarding port 25. It worked again, briefly, but is not doing now. I have not made any changes to the dstnat rules. Yesterday I could telnet to it, but an nmap scan was not showing it at all? Strange.
[admin@MikroTik] /ip firewall> /ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=input action=accept protocol=icmp
1 chain=input action=accept src-address=192.168.1.0/24 in-interface=bridge-local
2 chain=input action=accept connection-state=established
3 chain=input action=accept connection-state=related
4 chain=input action=drop
5 chain=forward action=accept connection-state=established
6 chain=forward action=accept connection-state=related
7 chain=forward action=accept in-interface=bridge-local
8 chain=forward action=accept protocol=tcp dst-address=192.168.1.3 in-interface=pppoe-out1 dst-port=22
9 chain=forward action=accept protocol=tcp dst-address=192.168.1.3 in-interface=pppoe-out1 dst-port=25
10 chain=forward action=accept protocol=tcp dst-address=192.168.1.3 in-interface=pppoe-out1 dst-port=993
11 chain=forward action=drop connection-state=invalid
12 chain=forward action=drop
See below for a complete set of my rules.
/ip firewall filter
add action=drop chain=input comment=“Drop invalid connections” connection-state=invalid
add chain=input comment=“Accept established connections” connection-state=established
add chain=input comment=“Accept related connections” connection-state=related
add chain=input comment=“Allow access from local network” in-interface=br-PrivateNetwork src-address=192.168.25.0/24
add chain=input comment=“Allow access from guest network for DNS” dst-port=53 in-interface=br-GuestNetwork protocol=udp src-address=192.168.125.0/24
add action=log chain=input comment=“Log everything else” disabled=yes log-prefix=“IPv4 Drop input RR:”
add action=drop chain=input comment=“Drop everything else”
add action=drop chain=forward comment=“Drop invalid connections” connection-state=invalid
add chain=forward comment=“Accept established connections” connection-state=established
add chain=forward comment=“Accept related connections” connection-state=related
add chain=forward comment=“Allow traffic from Local network” in-interface=br-PrivateNetwork src-address=192.168.25.0/24
add chain=forward comment=“Allow Guest network going outside” in-interface=br-GuestNetwork out-interface=pppoe-***** src-address=192.168.125.0/24
add action=log chain=forward comment=“Log everything else” disabled=yes log-prefix=“IPv4 Drop forward RR:”
add action=drop chain=forward comment="Drop everything else"As you can see, I have two networks inside. A private network and a guest network.
On the input chain my private network is allowed everywhere, and the guest network is only allowed to do dns requests.
On the forward chain my private network is allowed to go everywhere, and the guest network is only allowed to go outside on my pppoe client interface. So my private stuff is protected from being accessed from a guest system.
The accept rules for established and related traffic are per recommendation found all over the internet. The related rule is not always used, but eg FTP protocol uses that. It initiates on 21, for control, but data will travel on port 22, which will than be related and so port 22 for ftp doesn’t need to be opened explicitly. It is automatically opened only when initiated from a ftp session.
Last question you asked about your rule 11 and 12, if you do it in that order. Yes, that’s a little bit of redundant. As you can see on my list, the block invalid is on the top.
PS. regarding the NAT.
I did create some NAT rules myself and did not specify my in-interface but since I have a static IP I specified the dst-address. I can not imagine that that is causing the non working port 25, since the other 2 do work, but it’s just a thought.
Ah thanks very much! This illustrates an answer to all my questions perfectly. It also covers the guest network topology which I might want to setup at a later date.
I guess having the drop-invalid rule at the beginning is more efficient, rather than trying to match all the other rules first. All this is perfectly logical, but not intuitive (to me at least!)
I do have a static IP from my ISP. It is assigned by DHCP, (via pppOE) but is guaranteed fixed. I will try specifying the dst-address instead. I had done this at one point, but reading some routeros guides, it seemed the wrong way to do it.
Now, I have tried opening some other ports… Tried 587 (for SMTP) and this did not work. I tried 80 (to forward my web page, temporarily) and this did work. However, running nmap from outside gives conflicting results. I have never seen port 25 open and I did not see port 80 open, despite being able to visit the web page! I really don’t understand what could be happening here!
Rudios, I have added some very well deserved Karma!
