Mikrotik configuration for mail server

zuku · Sat May 06, 2017 12:44 pm

Hello, I need your advice about mikrotik configuration like NAT, DMZ, Firewall for internal mail server. Here is how it's looks:
LAN - 10.1.0.0/16 [SFp-sfpplus1]
DMZ - 10.10.14.0/24 [ETH5]
Mail server - 10.10.14.10
Domain server - 10.1.0.190
WAN - [sfp1]
WAN aliast IP x.x.x.60

Mail server will be accessible outside on one of WAN Alias IP address like X.X.X.60 and domain https://mail.mydomain.com. As I read I don't need hairpin nat like my DMZ is on another subnet.

NAT:

 ;;; masquerade all src-nat
chain=srcnat action=masquerade out-interface=sfp1 log=no log-prefix="" 
;;; dst-nat https, imaps, pop3s
chain=dstnat action=dst-nat to-addresses=10.10.14.10 to-ports=443 protocol=tcp dst-address=x.x.x.60 dst-port=443 log=no log-prefix="" 
chain=dstnat action=dst-nat to-addresses=10.10.14.10 to-ports=993 protocol=tcp dst-address=x.x.x.60 dst-port=993 log=no log-prefix="" 
chain=dstnat action=dst-nat to-addresses=10.10.14.10 to-ports=995 protocol=tcp dst-address=x.x.x.60 dst-port=995 log=no log-prefix="" 
;;; DMZ out using alias WAN IP
chain=srcnat action=src-nat to-addresses=x.x.x.60 src-address=10.10.14.0/24 log=no log-prefix=""

My domain DNS server pointing Mikrotik as Forwarder, and I would access my mail server from LAN by typing it's public domain name so: "mail.mydomain.com"
So I think I would create static DNS entry on mikrotik with this name and pointing to it's WAN alias IP x.x.x.60
1. First question is this good idea and if this will work, I mean accessing from LAN to internal mail server by it's public domain name. (I think is better solution for my because many of users working with laptops and often go outside to customers and then caching outside public DNS entries so their DNS cached entries would be the same - so no problems for them

2. How with setup like this view on mail server logs every user LAN IP - for troubleshooting and looking for spammers etc?
3. Is creation DNS static entry for LAN users with mail.mydomain.com - x.x.x.60 is good idea, or I should do it on Windows DSN server (2012)?

Firewall, (I skipped my INPUT rules)

 ;;; block invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

 1 XI  ;;; dmz, allow established, related
      chain=forward action=accept connection-state=established,related connection-type="" log=no log-prefix="" 

 2 XI  ;;; dmz, allow out for LAN, DMZ to outside WAN
      chain=forward action=accept out-interface=sfp1 log=no log-prefix="" 

 3 XI  ;;; dmz: allow from local networks, to DMZ
      chain=forward action=accept src-address-list=Local_Net out-interface=ether5 log=no log-prefix="" 

4  ;;; dmz: allow from DMZ Host access to LAN domain server  - users authentication
      chain=forward action=accept src-address=10.10.14.10 dst-address=10.1.0.190 in-interface=ether5 out-interface=sfp-sfpplus1 log=no log-prefix="" 

 5 XI  ;;; DMZ, allow dst-nat ports
      chain=forward action=accept connection-nat-state=dstnat protocol=tcp in-interface=sfp1 dst-port=22,443,993,995,3389,3390,3391 log=no 
      log-prefix="" 

6 XI  ;;; DMZ, block everything else
      chain=forward action=drop log=no log-prefix=""

4. If I have rule 5 with connection-nat-state=dstnat do I need specify in this rule dst-ports or my NAT redirection is enough?
5. My mail server on DMZ will need to contact my LAN domain server for users authentication - is rule 4 OK?
6. Is this firewall config enough to secure my lan and DMZ?

Big thanks for your help with my concerns.

Sob · Sat May 06, 2017 9:25 pm

1) Yes, it will work and there's no problem with it.
2) If you don't do anything wrong, you'll see original source addresses (10.1.x.x).
3) You don't have to create extra static entry. If your public mail.mydomain.com points to x.x.x.60, LAN clients will simply use that. You could add local static entry for mail.mydomain.com pointing directly to 10.10.14.10, but I don't see any major advantage (it will stil go through same router and skipping NAT won't change much).
4) No. You can have one global allow rule for all connections with connection-nat-state=dstnat and it's safe, it won't allow anything you don't specifically dstnat. You don't even need in-interface=sfp1. In fact, if your LAN client will access mail server on x.x.x.60, you can't have it, because their connections will have in-interface sfp-sfpplus1, your current rule #5 would not allow them.
5) Yes. You may possibly limit it to only some required ports.
6) If your goal is to allow unlimited access from DMZ and LAN to internet, unlimited access from Local_Net addresses to DMZ, access from 10.10.14.10 to 10.1.0.190, forwarded ports (see point 4) and block the rest, then the answer is yes (if you enable disabled rules, obviously).

zuku · Sun May 07, 2017 11:19 am

First of all, even if LAN users will catch mail server thru Mikrotik WAN IP I want that all traffic stay locally on router not go out to internet and then return.
Something is unclear to me, if I point on domain DNS or Mikrotik DNS https://mail.mydomain.com to x.x.x.60 then traffic will flow like this:
LAN [sfp-sfpplus1] -> WAN [sfp1] - > DMZ [ETH5]
in this case my LAN will use NAT DST-NAT rules, and my five firewall rule can have statement:

in-interface=sfp1

otherwise:
if I point on domain DNS or mikrotik DNS https://mail.mydomain.com to 10.10.14.10 then traffic will go:
LAN [sfp-sfpplus1] - > DMZ [ETH5]
so then LAN won't be DST-NAT and my five rule must have

in-interface=sfp1

removed
I am right?

Sob · Sun May 07, 2017 3:33 pm

Nope, it's LAN [sfp-sfpplus1] -> DMZ [ETH5] in both cases.

Your dstnat rule catches packet as soon as it gets to router and when it matches dst-address=x.x.x.60 condition, it changes its destination to 10.10.14.10. And only after that is the decision where packet should go to (you can examine detailed packet flow diagram in manual).

And even without dstnat, if you were connecting to some service on router (to public x.x.x.60 address), it still wouldn't go sfp1. Part of routing decision is if destinatination is local or not. In this case, x.x.x.60 is local, so it would go directly to service with in-interface=sfp-sfpplus1 and the fact that x.x.x.60 is on sfp1 would not matter in any way.

zuku · Sun May 07, 2017 8:28 pm

so It's time to deploy this scenario, and we will see how it goes.
Thanks Sob I have rated your profile

zuku · Tue May 09, 2017 9:31 pm

have problems with this setup, after enabled rule:

61    
      chain=forward action=drop log=no log-prefix=""

I have lost on connection with my remote connected IPSEC networks, so I added:

16    ;;; dmz: allow from LAN to remote networks
      chain=forward action=accept src-address=10.1.0.0/16 dst-address-list=Remote_Networks log=no log-prefix="" 

17    ;;; dmz: allow from remote networks to LAN
      chain=forward action=accept dst-address=10.1.0.0/16 src-address-list=Remote_Networks log=no log-prefix=""

these rules are below rule:

11    ;;; dmz, allow established, related
      chain=forward action=accept connection-state=established,related log=no log-prefix=""

so do I need to add to these two rules connection-state=new as I have sometimes problems connecting to remote computers on these networks?

I have rule to allow L2TP subnet to access only some computers, and OUT WAN Interface:

3    ;;; allow: l2pt net to only some pc and OUT WAN
      chain=forward action=accept src-address=10.100.0.0/24 dst-address-list=VPN-Users out-interface=sfp1 log=no log-prefix=""

and at the end I have now:

61    
      chain=forward action=drop log=no log-prefix=""

so last rulle should block traffic elsewhere for l2tp subnet other than accepted in 3 rule, but this not work, this subnet can browse all my LAN.

Sob · Wed May 10, 2017 3:29 am

In your previous post, you had rules #0 to #6, with last one being unconditional drop (rules are processed in order, so nothing could get beyond that) - 7 rules total. A nice simple config. Now you went up to #61, that's quite a difference.

It's hard to give advice, unless you post all rules (or even better whole config), because any of them can influence what happens. But with large config, just printed out, it's very easy to get lost in it or miss something. It's much better on live router, because you have counters, logging and everything.

When you have unconditional drop at the end, you need to specifically allow everything you want to work. It's enough to allow only one direction and "accept established & related" rule will take care of replies. You must also be careful to not allow too much, which it seems you did, otherwise your l2tp traffic would not go where it shouldn't.

Try to examine your rules one by one (remember, they are processed in order) what exactly they allow. Add extra logging rule for your l2tp traffic and move it around, until you find which rule allows it. You're looking for some accept rule. Packets will be visible all the way before it, but not after.

zuku · Wed May 10, 2017 8:59 pm

if You could a look at my firewall rules, I had to give some forward drop rules e.g. Facebook, MalwareDrop,Youtube.. on top of other forward allow rules because if these were below they didn't worked:

 0    ;;; block: DMZ invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

 1    ;;; block: block: 5-stage block brute force RDP, SSH
      chain=forward action=drop protocol=tcp src-address-list=rdp_ssh_blacklist dst-port=3389,3390,3391,22 log=no log-prefix="" 

 2    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdp_ssh_stage5 address-list=rdp_ssh_blacklist 
      address-list-timeout=0s dst-port=3389,3390,3391,22 log=no log-prefix="" 

 3    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdp_ssh_stage4 address-list=rdp_ssh_stage5 
      address-list-timeout=5m dst-port=3389,3390,3391,22 log=no log-prefix="" 

 4    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdp_ssh_stage3 address-list=rdp_ssh_stage4 
      address-list-timeout=5m dst-port=3389,3390,3391,22 log=no log-prefix="" 

 5    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdp_ssh_stage2 address-list=rdp_ssh_stage3 
      address-list-timeout=5m dst-port=3389,3390,3391,22 log=no log-prefix="" 

 6    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdp_ssh_stage1 address-list=rdp_ssh_stage2 
      address-list-timeout=5m dst-port=3389,3390,3391,22 log=no log-prefix="" 

 7    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp address-list=rdp_ssh_stage1 address-list-timeout=5m dst-port=3389,3390,3391,22 
      log=no log-prefix="" 

 8    ;;; block: addressListMalware
      chain=forward action=reject reject-with=icmp-network-unreachable dst-address-list=addressListMalware log=yes log-prefix="malwareIP" 

 9    ;;; block: malwareDNS
      chain=forward action=reject reject-with=icmp-network-unreachable dst-address=10.255.255.255 log=yes log-prefix="malwareDNS" 

10    ;;; block: Costomer1-L2TP to only some PC and WAN out
      chain=forward action=drop src-address=10.100.0.0/24 dst-address-list=!VPN-Users out-interface=!sfp1 log=no log-prefix="" 

11    ;;; block: P2P
      chain=forward action=drop p2p=all-p2p src-address=10.1.0.0/16 log=no log-prefix="" 

12    ;;; block: Facebook
      chain=forward action=drop src-address=10.1.0.0/16 src-address-list=!Exclusion dst-address-list=Facebook log=no log-prefix="" 

13    ;;; block: Youtube
      chain=forward action=drop protocol=tcp src-address=10.1.0.0/16 dst-port=80,443 content=youtube.com log=no log-prefix="" 

14    ;;; block: Coustomer2-L2TP only to DMZ network and WAN
      chain=forward action=drop src-address=10.10.14.250-10.10.14.254 dst-address=!10.10.14.0/24 out-interface=!sfp1 log=no log-prefix="" 

15    ;;; dmz, allow established, related
      chain=forward action=accept connection-state=established,related log=no log-prefix="" 

16    ;;; dmz, allow OUT LAN DMZ to Internet
      chain=forward action=accept out-interface=sfp1 log=no log-prefix="" 

17    ;;; dmz: allow L2TP to LAN
      chain=forward action=accept in-interface=all-ppp log=no log-prefix="" 

18    ;;; dmz: allow from lan to dmz
      chain=forward action=accept src-address=10.1.0.0/16 in-interface=sfp-sfpplus1 out-interface=ether5 log=no log-prefix="" 

19    ;;; dmz: allow from dmz to domain server
      chain=forward action=accept src-address=10.10.14.5 dst-address=10.1.0.190 in-interface=ether5 out-interface=sfp-sfpplus1 log=no log-prefix="" 

20    ;;; dmz: allow from LAN to IPSEC networks
      chain=forward action=accept src-address=10.1.0.0/16 dst-address-list=Remote_Networks log=no log-prefix="" 

21    ;;; dmz: allow from IPSEC networks to Lan 
      chain=forward action=accept dst-address=10.1.0.0/16 src-address-list=Remote_Networks log=no log-prefix="" 

22    ;;; dmz, allow: DST-NAT 
      chain=forward action=accept connection-nat-state=dstnat log=no log-prefix="DST-NAT" 

23    ;;; allow: established, related
      chain=input action=accept connection-state=established,related log=no log-prefix="" 

24    chain=input action=accept protocol=ipsec-esp log=no log-prefix="" 

25    ;;; allow: ipsec IKE
      chain=input action=accept protocol=udp dst-port=500 log=no log-prefix="" 

26    ;;; allow: ipsec NAT-T
      chain=input action=accept protocol=udp dst-port=4500 log=no log-prefix="" 

27    ;;; allow: ipsec L2TP
      chain=input action=accept protocol=udp dst-port=1701 log=no log-prefix="" 

28    ;;; allow: PPTP
      chain=input action=accept protocol=tcp dst-port=1723 log=no log-prefix="" 

29    ;;; allow: GRE
      chain=input action=accept protocol=gre log=no log-prefix="" 

30    ;;; allow: pingi
      chain=input action=accept protocol=icmp limit=50/5s,2 log=no log-prefix="" 

31    ;;; allow: RADIUS
      chain=input action=accept protocol=tcp dst-port=1812,1813 log=no log-prefix="" 

32    ;;; allow: Winbox Mac Discovery
      chain=input action=accept protocol=udp dst-port=5678 log=no log-prefix="" 

33    ;;; allow: Winbox
      chain=input action=accept protocol=tcp src-address-list=Winbox dst-port=8291 log=no log-prefix="" 

34    ;;; allow: Winbox from DDNS
      chain=input action=accept protocol=tcp src-address-list=host****.no-ip.**** dst-port=8291 log=no log-prefix="" 

35    ;;; allow: DNS Query
      chain=input action=accept protocol=udp in-interface-list=!WAN dst-port=53 log=no log-prefix="" 

36    chain=input action=accept protocol=tcp in-interface-list=!WAN dst-port=53 log=no log-prefix="" 

37    ;;; allow: DHCP
      chain=input action=accept protocol=udp dst-port=67-68 log=no log-prefix="DHCP" 

38    ;;; allow: SNMP
      chain=input action=accept protocol=udp src-address=10.1.0.210 in-interface=sfp-sfpplus1 dst-port=161-162 log=no log-prefix="" 

39    ;;; allow: OSPF
      chain=input action=accept protocol=ospf log=no log-prefix="" 

40    ;;; allow: OPENVPN, 1196 1195 are redirected to 1194
      chain=input action=accept protocol=tcp dst-port=1194,1195,1196 log=no log-prefix="" 

41 XI  ;;; block: allow only SMTP OUT to known smtp servers
      chain=forward action=drop protocol=tcp dst-address-list=!Smtp_Servers SMTP dst-port=25,587,465 log=no log-prefix="" 

42    ;;; DMZ, block forward all
      chain=forward action=drop log=no log-prefix="" 

43    ;;; block: input all
      chain=input action=drop log=no log-prefix=""

with this firewall setup, I can't more connect from my LAN to remote IPSEC lans using eg. remote desktop or other services.

Sob · Fri May 12, 2017 4:58 am

There are these accept rules:

#15 - allows established & related - that can't be it, it won't allow new connection
#16 - allows anything to WAN - that can't be it either
#17 - allows anything from all-ppp to anywhere - this will allow anything from L2TP clients not previously blocked

And the blocking would be done by:

10    ;;; block: Costomer1-L2TP to only some PC and WAN out
      chain=forward action=drop src-address=10.100.0.0/24 dst-address-list=!VPN-Users out-interface=!sfp1 log=no log-prefix=""

So if L2TP client has address from 10.100.0.0/24 and destination address is not in VPN-Users list and interface is not sfp1, it will drop the packet. It's not the best approach, because if client would happen to somehow get different address (not from 10.100.0.0/24), this rule would not match and everything would be allowed by rule #17. But if VPN clients do have addresses from 10.100.0.0/24 and VPN-Users list does contain only the right addresses that should be accessible and not more, then it should work.

zuku · Wed May 31, 2017 7:23 pm

Sob you told me earlier that if my LAN users go to my webmail server on DMZ using FQDN so Public WAN IP, then data flow is like: LAN [sfp-sfpplus1] -> DMZ [ETH5]
I can't agree with you, because when I'm trying access from LAN to webserver on DMZ to its management port let say: http://mail.mydomain.com:1005, I can't access it until I configure DST-NAT from Public WAN IP to internal webserver IP - so data flow going through LAN [sfp-sfpplus1] -> WAN [sfp1] {DST-NAT}- > DMZ [ETH5]
I can access from LAN to webserver management IP by its local IP 10.10.14.10:1005 even if this DST-NAT isn't configured, so answer is simple here.

Sob · Wed May 31, 2017 8:57 pm

You're free to disagree.

But remember that IP address and interface are two different and in a way independent things.

If you want to connect from LAN to mail.mydomain.com:1005, where this hostname points to your public address, then of course you need dstnat rule, otherwise the connection would go to router itself, which most likely has nothing running on port 1005. But if you're connecting from LAN, then in-interface for this connection will be LAN.

Do a simple test, set log=yes for your dstnat rule, connect to this port from LAN and check the log:

19:53:14 firewall,info dstnat: in:<guess which interface will be here> out:(none), src-mac xx:xx:xx:xx:xx:xx, proto TCP (SYN), <LAN client address>:<random port>-><public address>:1005, len xx

zuku · Wed May 31, 2017 10:18 pm

21:10:16 firewall,info MAIL-ADM dstnat: in:sfp-sfpplus1 out:(none), src-mac 74:d0:2b:2c:24:4d, proto TCP (SYN), 10.1.1.12:51238->X.X.X.60:1005, len 52

So if connection flow would really be: LAN [sfp-sfpplus1] -> WAN [sfp1] {DST-NAT}- > DMZ [ETH5], then originating interface would be in:sfp1 [wan] ?

Sob · Thu Jun 01, 2017 12:04 am

I guess you can say it like that. It's about how the whole thing is implemented. In any case, it would not actually send the packet to the other interface and catch it again, that would not make sense. So it's a matter of presentation.

In RouterOS, interfaces and IP addresses are related, but for routing, it doesn't matter very much where the address is. Router cares only about if it's local or not. If it is, packet will go to router (some service running on it). If not it, it will go somewhere else (determined by routing table). In-interface is simply the one from where the packet came to router.

I can imagine that some other system could approach this differently, tie interfaces and IP addresses more closely together and would show in-interface as the one with target IP address. This may be usable too, but it would require different thinking. Right now, I can't really tell what problems or advantages it would bring. But unless you'd be going to design RouterOS competitor, it doesn't really matter.

Mikrotik configuration for mail server

Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Re: Mikrotik configuration for mail server

Who is online