Community discussions

MikroTik App
 
DJLucas
just joined
Topic Author
Posts: 7
Joined: Sun Aug 21, 2011 7:03 am

Problem setting up a DMZ (and other minor questions)

Sun Aug 21, 2011 9:15 am

Hi guys and gals, new user of MikroTik products, and trying to wrap my head around the rules and capabilities of this device.

So, I have (what I believe to be) a rather simple setup that I want to achieve, but I'm not exactly sure how to get there. Basically, I have two internal networks, 192.168.142.0/24 and 192.168.143.0/24. The 142 subnet is intended to be what is referred to as a firewalled DMZ by other devices -- ie: no connections from the "WAN" interface can initiate connections on the "LAN1" interface (private 143 network), nor is the "DMZ" (142) allowed to initiate connections into "LAN1" (143). I'm fairly confident that I have dstnat and masquerading setup correctly for both subnets, but I can't for the life of me find a good example of how to isolate the the "DMZ" interface. Here are a couple of configuration snips to help paint a better picture:
[admin@MikroTik] > ip f e
# aug/21/2011 00:32:42 by RouterOS 5.6
# software id = XXXX-XXXX
#
/ip firewall connection tracking
set enabled=yes generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s \
    tcp-close-wait-timeout=10s tcp-established-timeout=1d \
    tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s \
    tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-syncookie=no \
    tcp-time-wait-timeout=10s udp-stream-timeout=3m udp-timeout=10s
/ip firewall filter
add action=drop chain=input disabled=no in-interface=WAN
/ip firewall nat
add action=masquerade chain=srcnat disabled=no dst-address=0.0.0.0/0 \
    src-address=192.168.143.0/24
add action=masquerade chain=srcnat disabled=no dst-address=0.0.0.0/0 \
    src-address=192.168.142.0/24
add action=dst-nat chain=dstnat disabled=no dst-port=25 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=80 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=21 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=443 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=587 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=993 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=8080 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=8080 in-interface=WAN \
    protocol=udp to-addresses=192.168.142.225
add action=dst-nat chain=dstnat disabled=no dst-port=10022 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.225 to-ports=22
add action=dst-nat chain=dstnat disabled=no dst-port=10025 in-interface=WAN \
    protocol=tcp to-addresses=192.168.142.240 to-ports=22
/ip firewall service-port
set ftp disabled=no ports=21
set tftp disabled=no ports=69
set irc disabled=no ports=6667
set h323 disabled=no
set sip disabled=no ports=5060,5061 sip-direct-media=yes
set pptp disabled=no
[admin@MikroTik] > 
Notes on above: IIUC, I could make the 2 masquerade rules a single rule, but I like the idea of being able to shut it down quickly without affecting internet access for the 143 network if needs be. I am using 'in-interface=WAN' for the dst-nat rules because WAN address is assigned via DHCP in my (home) testing environment. Also, I'm assuming that the nat rules take prescience over the filter rules. I wasn't able to find this documented, and while I haven't done an exhaustive search, I see that my nat rules work as expected, but port 69 does not respond from the outside.

Now my best guess was '/ip firewall filter add action=drop chain=input disabled=no in-interface=DMZ'. While I haven't actually tried it, I don't think it would work because I do need to initiate connections from LAN1 to DMZ and there are no nat rules to circumvent the filter's 'drop' action (this based on the assumption in the above paragraph).
[admin@MikroTik] > in pr       
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                             TYPE               MTU L2MTU  MAX-L2MTU
 0  R  WAN                              ether             1500  1524       1524
 1  R  LAN1                             ether             1500  1524       1524
 2     LAN2                             ether             1500  1524       1524
 3     LAN3                             ether             1500  1524       1524
 4  R  DMZ                              ether             1500  1524       1524
[admin@MikroTik] > 
Also, one other thing I noticed in this configuration is that 139 and 445 show up (closed) while all other ports seem to be stealth when running a port scan (with the obvious exception of the nat'd ports). I don't have an explanation for this. Finally, if you have any other suggestions based on the above, I'm very eager to learn from those more experienced than I.

Thanks in advance.

-- DJ Lucas
Last edited by DJLucas on Tue Aug 23, 2011 5:20 am, edited 2 times in total.
 
tjc
Member Candidate
Member Candidate
Posts: 276
Joined: Sun Jul 10, 2011 3:08 am

Re: New RB450G - some (probably basic) questions

Sun Aug 21, 2011 5:20 pm

Did you take the DMZ port out of the local switch group? If not, this:
interface ethernet print
will show the master port as ether2 (your LAN1) and traffic between them will bypass the firewall.
 
DJLucas
just joined
Topic Author
Posts: 7
Joined: Sun Aug 21, 2011 7:03 am

Problem setting up a DMZ

Mon Aug 22, 2011 5:50 pm

Did you take the DMZ port out of the local switch group? If not, this:
interface ethernet print
will show the master port as ether2 (your LAN1) and traffic between them will bypass the firewall.
Thanks for the pointer tjc. Yes, I have actually set them separate, at least I believe this is the correct setting:
[admin@MikroTik] /interface> ethernet print
Flags: X - disabled, R - running, S - slave
 #    NAME        MTU MAC-ADDRESS       ARP        MASTER-PORT      SWITCH
 0 R  WAN        1500 00:0C:42:B0:C2:5F enabled
 1 R  LAN1       1500 00:0C:42:B0:C2:60 enabled    none             switch1
 2  S LAN2       1500 00:0C:42:B0:C2:61 enabled    LAN1             switch1
 3  S LAN3       1500 00:0C:42:B0:C2:62 enabled    LAN1             switch1
 4 R  DMZ        1500 00:0C:42:B0:C2:63 enabled    none             switch1
Other suggestions? I put a full export on pastebin for review if that is useful to anybody.
http://pastebin.com/6KdRZQe1

Again, thanks.

-- DJ Lucas
 
tjc
Member Candidate
Member Candidate
Posts: 276
Joined: Sun Jul 10, 2011 3:08 am

Re: Problem setting up a DMZ (and other minor questions)

Tue Aug 23, 2011 4:50 am

Adding some filter rules would probably help. Just off the top of my head anything coming from the DMZ to the LAN side should be filtered in the forwarding chain to allow only established or related connections and drop everything else. I'd also limit connections from the DMZ port to the input chain, maybe allow services like DHCP, DNS and NTP but anything else should probably be dropped.

One of the fulltime pros like fewi can probably make more specific recommendations.
 
DJLucas
just joined
Topic Author
Posts: 7
Joined: Sun Aug 21, 2011 7:03 am

Re: Problem setting up DMZ

Tue Aug 23, 2011 5:00 am

Thanks once again tjc. That is exactly what I needed, but I'm still a little bit stuck. So reading more on the filter rules and various other threads, what "I think" I want is below:
# 0 Allow established connections to maintain a connection on all interfaces
/ip firewall filter add chain=forward action=accept connection-state=established 

# 1 Allow related connections to occur on all interfaces (ex: ftp and ftp-data)
/ip firewall filter add chain=forward action=accept connection-state=related 

# 2 Allow hosts on LAN1 interface to establish connections through both DMZ and WAN interfaces
/ip firewall filter add chain=forward action=accept out-interface=LAN1 

# 3 Allow hosts on DMZ interface to initiate connections through the WAN interface
/ip firewall filter add chain=forward action=accept in-interface=WAN out-interface=DMZ 

# 4 Drop inbound connections through WAN interface that do not match rules above or dst-nat rules
/ip firewall filter add chain=input action=drop in-interface=WAN

# 5 Do not allow hosts on DMZ interface to connect to hosts on LAN1 interface
# This rule is the one that breaks everything
/ip firewall filter add chain=forward action drop in-interface=LAN1 out-interface=DMZ

My expectation was that rule 2 above should match when the host on LAN1 makes the connection to the host on DMZ, then rule 1 would allow the response from DMZ to LAN1, finally rule 0 always matches. What actually happens when rule 5 is added is that all communication stops on both LAN1 and DMZ. I was expecting a logical AND there, not OR. But even still, I don't understand why the first three rules do not match and keep this from happening. Obviously my understanding is flawed, but I've been over the filtering docu on the wiki many times and I can't seem to see what it is that I'm missing.

Thanks in advance for pointers or explanations.

-- DJ Lucas
 
tjc
Member Candidate
Member Candidate
Posts: 276
Joined: Sun Jul 10, 2011 3:08 am

Re: Problem setting up DMZ

Tue Aug 23, 2011 5:33 am

It looks like your src/dst are backward here:
# 2 Allow hosts on LAN1 interface to establish connections through both DMZ and WAN interfaces
/ip firewall filter add chain=forward action=accept out-interface=LAN1 
# 3 Allow hosts on DMZ interface to initiate connections through the WAN interface
/ip firewall filter add chain=forward action=accept in-interface=WAN out-interface=DMZ 
:
# 5 Do not allow hosts on DMZ interface to connect to hosts on LAN1 interface
# This rule is the one that breaks everything
/ip firewall filter add chain=forward action drop in-interface=LAN1 out-interface=DMZ
In #2 you probably mean "in-interface=LAN1"
In #3 in-interface=DMZ out-interface=WAN
in #5 in-interface=DMZ out-interface=LAN1

That will probably get you a lot closer but I'm not sure it'd be right. Stepping back here's another spin at what we're trying to do using the implicit accept:

For the input chain; allow established and related, drop invalid, drop anything from WAN or DMZ, implicitly allow new from LAN1

For the forwarding chain; allow established and related, drop invalid, drop anything else from DMZ to LAN1, drop anything else from WAN to LAN1, implicitly allow new from LAN1 to anywhere, and DMZ to/from WAN

That looks something like this:
/ip firewall filter
add chain=input action=accept protocol=icmp comment="Allow ping and the like"
add chain=input action=accept connection-state=established comment="Allow established connections"
add chain=input action=accept connection-state=related comment="Allow related connections"
add chain=input action=drop connection-state=invalid comment="Drop invalid connections"
add chain=input action=drop in-interface=WAN comment="Drop anything else aimed at the router from outside"
add chain=input action=drop in-interface=DMZ comment="Drop anything else aimed at the router from the DMZ"
# The rule above may block router services needed by the machines in the DMZ...
# Implicitly allow anything else to get to the router.

add chain=forward action=accept connection-state=established comment="Allow established connections"
add chain=forward action=accept connection-state=related comment="Allow related connections"
add chain=forward action=drop connection-state=invalid comment="Drop invalid connections"
add chain=forward action=drop in-interface=WAN out-interface=LAN1 comment="Drop anything else from outside"
add chain=forward action=drop in-interface=DMZ out-interface=LAN1 comment="Drop anything else from the DMZ"
# Implicitly allow anything else to be forwarded
 
DJLucas
just joined
Topic Author
Posts: 7
Joined: Sun Aug 21, 2011 7:03 am

Re: Problem setting up DMZ

Tue Aug 23, 2011 6:01 am

It looks like your src/dst are backward here:
Bingo! I had assumed the in/out terminology to mean out=source and in=destination, as in traversal. It had not occurred to me to look at it from the router's (or maybe CPU is more accurate) point of view (IN to the CPU from source and OUT of the CPU to the destination). I had simply glossed right over them a thousand times in the wiki:
in-interface (name) - interface the packet has entered the router through
...
out-interface (name) - interface the packet will leave the router through
<snip suggestions for brevity>

Thank you so much! I was getting so frustrated as the logic seemed so simple. :-) I'll implement your alternate proposal (which looks to be almost perfect!).

-- DJ Lucas

Who is online

Users browsing this forum: baragoon, frengo, InfraErik and 72 guests