IPSec VPN Problem

AwesomeDuke · Sun Feb 11, 2018 7:03 am

Hi Everyone,

I’ve come across an issue and I’m not sure I’ve solved it in the way it should be solved.

My issue is I have an IPSec VPN between two sites and the connection is established and I can ping from each location. Problem is when I want to HTTPS to a specific IP at the remote location through the VPN, the NAT rule applies and I’m forwarded to the IP address the NAT rule is set for. Also, when I try and open the VMWare vSphere Client to connect to the remote VMWare server, it is blocked.

To get around this I created the following NAT rule to circumvent the problem:

add action=accept chain=dstnat comment="Allow VPN Access" disabled=yes \
dst-port="" in-interface=iiNet-FTTN protocol=tcp src-address=\
192.168.8.0/24

As you can see it’s currently disabled, but if I enable it, everything works as expected and I can do everything I require. My concern is that that doesn’t look very secure and I’m concerned someone can spoof an IP address and gain full access to the network. Is there a better way? Ideally can I set a rule to say everything from this VPN connection can be safely accepted? Also, my understanding is that the rule should be a srcnat not dstnat and that is even more worrying hence why I haven't enabled the rule.

Basically I want the VPN at the remote location to be treated as if it’s part of the local network.

Many thanks for your time guys…

Duke

sindy · Sun Feb 11, 2018 2:13 pm

You haven't stated at which end of the VPN connection you had to apply your "suspicious" dstnat rule. And you're right, it is suspicious, because it doesn't actually dst-nat anything as the action is "accept" rather than "dst-nat", so it must be shadowing some other rule in the same chain (dstnat).

So please post the output of "/ip firewall export" (if there are any public addresses, replace each occurrence of a unique public address with a unique pattern systematically to preserve relationships), and state at which end (closer to the https client or closer to the https server) that firewall rules exist.

As for security: a "real" dst-nat rule should not affect security as it actually only redirects the packets, so if the new destination is secured, the fact that packets originally sent to some other destination are redirected to it should make no difference. Security of the redirecting box should be provided by rules in "filter" table, not rules in "nat" table.

But there is one risk associated with IPsec tunnel use which should be addressed - both packets which come directly to the interface and the packets decapsulated from IPsec tunnel are tagged with the same input interface. So if someone directly sends packet with a source address from the range of the other end of the IPsec tunnel, it cannot be distinguished from a apcket which came in via the tunnel neither by src-address nor by in-interface. Therefore, there is a rule matching condition "ipsec-policy". With value "in,ipsec" it matches packets which came in via an IPsec tunnel, with value "in,none" it matches packets which came in directly to the interface (including the transport packets of the ipsec tunnel!). So by carefully using accept and drop rules with this condition in ip firewall filter, you can prevent packets which come in from outside with source address pretending to be from the remote site range from being processed.

CZFan · Sun Feb 11, 2018 3:24 pm

seems fine to me

acruhl · Sun Feb 11, 2018 3:51 pm

You could set up routing of the private subnet between the VPN sites over a GRE tunnel possibly.

If you're worried about the private address space "leaking" out of a different interface (and it's a legit worry see viewtopic.php?f=2&t=129771&p=637561#p637561), you can put in firewall rules to specifically block that subnet from exiting where it shouldn't.

AwesomeDuke · Mon Feb 12, 2018 11:10 am

You haven't stated at which end of the VPN connection you had to apply your "suspicious" dstnat rule. And you're right, it is suspicious, because it doesn't actually dst-nat anything as the action is "accept" rather than "dst-nat", so it must be shadowing some other rule in the same chain (dstnat).

So please post the output of "/ip firewall export" (if there are any public addresses, replace each occurrence of a unique public address with a unique pattern systematically to preserve relationships), and state at which end (closer to the https client or closer to the https server) that firewall rules exist.

As for security: a "real" dst-nat rule should not affect security as it actually only redirects the packets, so if the new destination is secured, the fact that packets originally sent to some other destination are redirected to it should make no difference. Security of the redirecting box should be provided by rules in "filter" table, not rules in "nat" table.

But there is one risk associated with IPsec tunnel use which should be addressed - both packets which come directly to the interface and the packets decapsulated from IPsec tunnel are tagged with the same input interface. So if someone directly sends packet with a source address from the range of the other end of the IPsec tunnel, it cannot be distinguished from a apcket which came in via the tunnel neither by src-address nor by in-interface. Therefore, there is a rule matching condition "ipsec-policy". With value "in,ipsec" it matches packets which came in via an IPsec tunnel, with value "in,none" it matches packets which came in directly to the interface (including the transport packets of the ipsec tunnel!). So by carefully using accept and drop rules with this condition in ip firewall filter, you can prevent packets which come in from outside with source address pretending to be from the remote site range from being processed.

Hi Sindy,

thanks for your response. I've tried a difference approach by using an address-list at both sides, but still not luck:

add action=accept chain=srcnat dst-address-list=Private src-address-list=\
    Private

As requested, here is the Local Export:

# feb/11/2018 13:26:44 by RouterOS 6.41
# software id = ABC123
#
# model = RouterBOARD 750G r3
# serial number = ABC123
/interface bridge
add name=LAN-WIFI
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=ISP \
    password=abc123 use-peer-dns=yes user=<UserName>
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-128-cbc,3des
add enc-algorithms=aes-256-cbc,aes-128-cbc,3des name=candc
/interface bridge port
add bridge=LAN-WIFI hw=no interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=192.168.8.1/24 interface=LAN-WIFI network=192.168.8.0
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.8.1 name=router
/ip firewall address-list
add address=192.168.0.0/16 list=Private
add address=10.0.0.0/8 list=Private
add address=172.16.0.0/12 list=Private
/ip firewall filter
add action=drop chain=input comment=\
    "log then drop NEW inbound connection from anyone on port 5060 udp" \
    connection-state=new dst-port=5060 log=yes log-prefix="Bad Sip : " \
    protocol=udp
add action=drop chain=forward comment="SET in-interface=wan PORT!! - Drop NEW \
    incoming non-dest-nat forward traffic from Outside world - ONLY ENABLE on \
    Home/Single WAN Connections" connection-nat-state=!dstnat \
    connection-state=new disabled=yes log=yes log-prefix=\
    "Bad New Incoming : "
add action=fasttrack-connection chain=forward comment="FastTrack established a\
    nd related connections - DO NOT USE if using Queues. Bypasses most Firewal\
    l processing" connection-state=established,related disabled=yes
add chain=forward comment="Accept established and related connections" \
    connection-state=established,related
add chain=input connection-state=established,related
add action=drop chain=forward comment="Drop invalid connections" \
    connection-state=invalid disabled=yes log=yes log-prefix="Invalid : "
add action=drop chain=input connection-state=invalid disabled=yes log=yes \
    log-prefix="Invalid : "
add action=reject chain=forward comment="Report on users using External DNS" \
    disabled=yes dst-address-list=!Private dst-port=53 log=yes log-prefix=\
    "External-DNS-Use - " protocol=tcp reject-with=icmp-admin-prohibited \
    src-address-list=Private
add action=reject chain=forward disabled=yes dst-address-list=!Private \
    dst-port=53 log=yes log-prefix="External-DNS-Use - " protocol=udp \
    reject-with=icmp-admin-prohibited src-address-list=Private
add action=drop chain=input comment=\
    "BLOCK new TCP Mikrotik Services Requests that are NOT internal" \
    connection-state=new dst-port=22,23,53,80,443,161,8080 log=yes protocol=\
    tcp src-address-list=!Private
add action=drop chain=input comment=\
    "BLOCK new UDP Mikrotik Services Requests that are NOT internal" \
    connection-state=new dst-port=53,123,161 log=yes protocol=udp \
    src-address-list=!Private
add chain=forward comment=Trusted dst-address-list=trusted
add chain=forward src-address-list=trusted
add chain=input src-address-list=trusted
add chain=output dst-address-list=trusted
add action=reject chain=forward comment=\
    "BLOCK Youtube unless in YouTube allow list" disabled=yes dst-address=\
    202.69.181.204/30 log=yes log-prefix=youtube_ reject-with=\
    icmp-admin-prohibited src-address-list="!youtube access"
add action=reject chain=forward comment=\
    "BLOCK Facebook unless in facebook allowed list" disabled=yes \
    dst-address-list="Facebook IP ranges" log=yes log-prefix=facebook_ \
    reject-with=icmp-admin-prohibited src-address-list="!facebook access"
add action=reject chain=forward comment=\
    "BLOCK Twitter  unless in twitter allowed list" disabled=yes \
    dst-address-list="Twitter IP ranges" log=yes log-prefix=twitter_ \
    reject-with=icmp-admin-prohibited src-address-list="!twitter access"
add action=reject chain=forward comment=\
    "BLOCK MusicServices unless in MusicServices allowed list" disabled=yes \
    dst-address-list="MusicServices IP ranges" log=yes log-prefix=\
    MusicServices_ reject-with=icmp-admin-prohibited src-address-list=\
    "!MusicServices access"
/ip firewall mangle
add action=change-dscp chain=postrouting comment="NBN blocks DSCP - CLEAR DSCP\
    \_- this allows Mik to still queue from here now however" disabled=yes \
    dscp=!0 new-dscp=0 passthrough=yes src-address-list=Private
add action=change-dscp chain=output comment="NBN blocks DSCP - CLEAR DSCP - th\
    is allows Mik to still queue from here now however" disabled=yes dscp=!0 \
    new-dscp=0 passthrough=yes src-address-list=Private
add action=clear-df chain=prerouting comment="Clear the DF TCP bit due to RPC/\
    HTTPS Protocol and others setting DF . LEAVE AS RULE 0 !!" passthrough=\
    yes src-address-list=Private
/ip firewall nat
add action=accept chain=srcnat dst-address-list=Private src-address-list=\
    Private
add action=masquerade chain=srcnat dst-address-list=!Private \
    src-address-list=Private
add action=dst-nat chain=dstnat dst-port=25 in-interface=ISP protocol=\
    tcp to-addresses=192.168.8.5 to-ports=25
add action=dst-nat chain=dstnat dst-port=443 in-interface=ISP protocol=\
    tcp to-addresses=192.168.8.10 to-ports=443
add action=dst-nat chain=dstnat dst-port=80 in-interface=ISP protocol=\
    tcp to-addresses=192.168.8.2 to-ports=80
/ip firewall raw
add action=drop chain=prerouting comment="Drop Blacklist IN or OUT" log=yes \
    log-prefix=BlackListed_ src-address-list=blacklist
add action=drop chain=prerouting dst-address-list=blacklist log=yes \
    log-prefix=BlackListed_
add chain=prerouting comment="Forward all private to private" \
    dst-address-list=Private src-address-list=Private
/ip firewall service-port
set sip ports=5060,5061,5080,5081 sip-direct-media=no
/ip ipsec peer
add address=<RemoteIP>/32 comment="C and C" dh-group=modp1024 \
    enc-algorithm=aes-256,aes-128,3des local-address=<LocalWAN-IP> \
    nat-traversal=no secret=abc123
/ip ipsec policy
add comment="C and C" disabled=yes dst-address=192.168.10.0/24 \
    sa-dst-address=<RemoteIP> sa-src-address=<LocalWAN-IP> src-address=\
    192.168.8.0/24 tunnel=yes
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-name=Australia/ACT
/system identity
set name=Mikrotik
/system ntp client
set enabled=yes primary-ntp=13.55.50.68 secondary-ntp=103.76.40.156
/system ntp server
set broadcast=yes enabled=yes
/system routerboard mode-button
set enabled=no on-event=""

And here is the Remote Script:

# feb/11/2018 13:37:41 by RouterOS 6.41.1
# software id = ABC123
#
# model = RouterBOARD 3011UiAS
# serial number = ABC123
/interface bridge
add name=LAN-WIFI
/interface ethernet
set [ find default-name=ether1 ] name=Fibre
/interface pppoe-client
add add-default-route=yes default-route-distance=2 disabled=no interface=\
    ether2 name=RemoteISP password=abc123 use-peer-dns=yes user=\
    <Username>
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-128-cbc,3des
/interface bridge port
add bridge=LAN-WIFI interface=ether5
/ip address
add address=192.168.10.1/24 interface=LAN-WIFI network=192.168.10.0
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=Fibre
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip firewall address-list
add address=192.168.0.0/16 list=Private
add address=10.0.0.0/8 list=Private
add address=172.16.0.0/12 list=Private
/ip firewall filter
add action=drop chain=input comment=\
    "log then drop NEW inbound connection from anyone on port 5060 udp" \
    connection-state=new dst-port=5060 log=yes log-prefix="Bad Sip : " \
    protocol=udp
add action=drop chain=forward comment="SET in-interface=wan PORT!! - Drop NEW \
    incoming non-dest-nat forward traffic from Outside world - ONLY ENABLE on \
    Home/Single WAN Connections" connection-nat-state=!dstnat \
    connection-state=new disabled=yes log=yes log-prefix=\
    "Bad New Incoming : "
add action=fasttrack-connection chain=forward comment="FastTrack established a\
    nd related connections - DO NOT USE if using Queues. Bypasses most Firewal\
    l processing" connection-state=established,related disabled=yes
add chain=forward comment="Accept established and related connections" \
    connection-state=established,related
add chain=input connection-state=established,related
add action=drop chain=forward comment="Drop invalid connections" \
    connection-state=invalid disabled=yes log=yes log-prefix="Invalid : "
add action=drop chain=input connection-state=invalid disabled=yes log=yes \
    log-prefix="Invalid : "
add action=reject chain=forward comment="Report on users using External DNS" \
    disabled=yes dst-address-list=!Private dst-port=53 log=yes log-prefix=\
    "External-DNS-Use - " protocol=tcp reject-with=icmp-admin-prohibited \
    src-address-list=Private
add action=reject chain=forward disabled=yes dst-address-list=!Private \
    dst-port=53 log=yes log-prefix="External-DNS-Use - " protocol=udp \
    reject-with=icmp-admin-prohibited src-address-list=Private
add action=drop chain=input comment=\
    "BLOCK new TCP Mikrotik Services Requests that are NOT internal" \
    connection-state=new dst-port=22,23,53,80,443,161,8080 log=yes \
    log-prefix="HTTP Block:" protocol=tcp src-address-list=!Private
add action=drop chain=input comment=\
    "BLOCK new UDP Mikrotik Services Requests that are NOT internal" \
    connection-state=new dst-port=53,123,161 log=yes protocol=udp \
    src-address-list=!Private
add chain=forward comment=Trusted dst-address-list=trusted
add chain=forward src-address-list=trusted
add chain=input src-address-list=trusted
add chain=output dst-address-list=trusted
add action=reject chain=forward comment=\
    "BLOCK Youtube unless in YouTube allow list" disabled=yes dst-address=\
    202.69.181.204/30 log=yes log-prefix=youtube_ reject-with=\
    icmp-admin-prohibited src-address-list="!youtube access"
add action=reject chain=forward comment=\
    "BLOCK Facebook unless in facebook allowed list" disabled=yes \
    dst-address-list="Facebook IP ranges" log=yes log-prefix=facebook_ \
    reject-with=icmp-admin-prohibited src-address-list="!facebook access"
add action=reject chain=forward comment=\
    "BLOCK Twitter  unless in twitter allowed list" disabled=yes \
    dst-address-list="Twitter IP ranges" log=yes log-prefix=twitter_ \
    reject-with=icmp-admin-prohibited src-address-list="!twitter access"
add action=reject chain=forward comment=\
    "BLOCK MusicServices unless in MusicServices allowed list" disabled=yes \
    dst-address-list="MusicServices IP ranges" log=yes log-prefix=\
    MusicServices_ reject-with=icmp-admin-prohibited src-address-list=\
    "!MusicServices access"
/ip firewall mangle
add action=clear-df chain=prerouting comment="Clear the DF TCP bit due to RPC/\
    HTTPS Protocol and others setting DF . LEAVE AS RULE 0 !!" passthrough=\
    yes src-address-list=Private
add action=mark-packet chain=forward comment=Throttle dst-address-list=\
    !Private new-packet-mark=Throttle passthrough=yes src-address-list=\
    Throttle
add action=mark-packet chain=forward dst-address-list=Throttle \
    new-packet-mark=Throttle passthrough=yes src-address-list=!Private
/ip firewall nat
add action=accept chain=srcnat dst-address-list=Private src-address-list=\
    Private
add action=masquerade chain=srcnat dst-address-list=!Private \
    src-address-list=Private
add action=masquerade chain=srcnat comment="Masquerade for Internet Access" \
    disabled=yes
add action=dst-nat chain=dstnat comment="Allow HTTPS to DSVR" dst-port=443 \
    in-interface=Fibre protocol=tcp to-addresses=192.168.10.2 to-ports=\
    443
add action=dst-nat chain=dstnat comment="Allow HTTP to DSVR" dst-port=80 \
    in-interface=Fibre protocol=tcp to-addresses=192.168.10.2 to-ports=\
    80
/ip firewall raw
add action=drop chain=prerouting comment="Drop Blacklist IN or OUT" log=yes \
    log-prefix=BlackListed_ src-address-list=blacklist
add action=drop chain=prerouting dst-address-list=blacklist log=yes \
    log-prefix=BlackListed_
add chain=prerouting comment="Forward all private to private" \
    dst-address-list=Private src-address-list=Private
/ip ipsec peer
add address=<RemoteIP>/32 dh-group=modp1024 enc-algorithm=\
    aes-256,aes-128,3des local-address=<LocalWANIP> nat-traversal=no secret=\
    abc123
/ip ipsec policy
add dst-address=192.168.8.0/24 sa-dst-address=<RemoteIP> sa-src-address=\
    <LocalWANIP> src-address=192.168.10.0/24 tunnel=yes
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-name=Australia/ACT
/system identity
set name=CandCMikroTik
/system ntp client
set enabled=yes primary-ntp=13.55.50.68 secondary-ntp=103.76.40.156
/system ntp server
set broadcast=yes enabled=yes

Thanks for any guidance in advance...

Duke

sindy · Mon Feb 12, 2018 11:44 am

Please provide the mapping between "local" and "remote" on one hand and "https server side" and "https client side" on the other one.

AwesomeDuke · Mon Feb 12, 2018 1:25 pm

Please provide the mapping between "local" and "remote" on one hand and "https server side" and "https client side" on the other one.

Mapping is trying access HTTPS from local to the Remote. You can access HTTPS from local to remote, but because the NAT takes hold of the connection, you are forwarded to the pre-existing port 443 NAT not the intended connection. So using this example, trying to access a HTTPS connection on 192.168.10.112 sends you to 192.168.10.2.

The other issue as outlined is the total inability to connect to to the VMware via the vSphere Client to the remote location on 192.168.10.12.

I hope this is what you're asking.

sindy · Mon Feb 12, 2018 1:48 pm

grrr... I haven't written that "hide-sensitive" should be given as a parameter to the "/export" because I've told you to export only the firewall rules. So I hope you have modified the secrets before posting as otherwise you have to modify them now to stay secure once you've leaked them here.

AwesomeDuke · Mon Feb 12, 2018 2:17 pm

grrr... I haven't written that "hide-sensitive" should be given as a parameter to the "/export" because I've told you to export only the firewall rules. So I hope you have modified the secrets before posting as otherwise you have to modify them now to stay secure once you've leaked them here.

All the secrets have been modified. Thanks for checking though. Did it make sense what I posted previously and was that the info you're after?

sindy · Mon Feb 12, 2018 3:10 pm

All the secrets have been modified

OK, fine.

Did it make sense what I posted previously and was that the info you're after?

Yes, I simply wanted to put the all chips at right places to avoid losing time by searching from where to start.

To the topics - as I've expected initially and as you've even stated initially but in a hard to understand (at least for me) manner and confirmed recently, your "suspicious" dstnat rule at the "remote" site helps because it shadows another dstnat rule in place - the first one below in particular.

/ip firewall nat
...
add action=dst-nat chain=dstnat comment="Allow HTTPS to DSVR" dst-port=443 \
    in-interface=Fibre protocol=tcp to-addresses=192.168.10.2 to-ports=\
    443
add action=dst-nat chain=dstnat comment="Allow HTTP to DSVR" dst-port=80 \
    in-interface=Fibre protocol=tcp to-addresses=192.168.10.2 to-ports=\
    80

If you look at these rules, you can see that their matching part only checks in-interface, protocol and dst-port, it does not care about dst-address. As I've written in one of my previous posts, albeit with regard to security:

there is one risk associated with IPsec tunnel use which should be addressed - both packets which come directly to the interface and the packets decapsulated from IPsec tunnel are tagged with the same input interface.

So the rule above, unless shadowed by the "suspicious" one, steals any https connection incoming through interface Fibre and redirects it to DSVR (whatever is is), regardless whether it has arrived to the address assigned to that interface or via an IPsec tunnel passing through that interface.

So you may modify that rule by adding "ipsec-policy=in,none" to let the rule match only packets which did not come via the IPsec tunnel. If the same IP address is assigned to the interface systematically, although using DHCP, you may also use "dst-address=x.x.x.x" to make the rule match only on direct packets and ignore the tunnelled ones.

Or you may instead put your "suspicious" rule before the one above, simplified to just "chain=dstnat ipsec-policy=in,ipsec action=accept". Such rule will prevent any dstnat on anything that comes in via the IPsec tunnel but will not "protect" packets incoming directly from the rules following it.

However, the fact that the packets coming in via IPsec tunnel will avoid being dstnat'ed does not prevent the firewall filter rules from eventually dropping them. So if the ip firewall address-list "trusted", referred to by some ip firewall filter rules, exists and contains the subnet of the "local" site, the IPsec-tunnelled packets will get through due to those rules in "forward" chain referring to that address-list.

But here the security concern I've expressed earlier comes into play - if someone spoofs a packet which has a source address matching that list, such packet will get through, regardless from where it has arrived. The eventual response to such packet will be in most cases sent to the spoofed address so the attacker will not be able to establish a connection, but there may be exceptions to that rule if the payload of such packet would contain the actual IP of the attacker and the receiving application would use that one to route the response. And in such case, the firewall would treat such connection as initiated from the protected side and let it establish.

So I would rather use a similar rule as above also in the "forward" chain of the "ip firewall filter" table: "chain=forward ipsec-policy=in,ipsec action=accept" than adding the subnets from "local" site to the "trusted" address-list in "remote"'s firewall.

Overall I do not like the general firewall concept you use, which is "allow everything, deny exceptions". In my vision of the world, the safe approach is "deny everything, allow exceptions". If you forget about an "allow" exception, the unhappy users will let you know quickly. If you forget about a "deny" exception, the happy "users" will let you know never

E.g. both your "input" and "forward" chains have several deny rules for specific types of traffic, but there is no "deny the rest" rule in the end. While some firewalls can define the default handling (allow or deny) using a separate configuration item, Mikrotik allows everything by default unless you put an "unconditional drop" as the last rule of a chain.

This is best seen at your (only) rule in the "output" chain of "ip firewall filter" - if you disable or remove it, nothing will change.

AwesomeDuke · Tue Feb 13, 2018 4:56 am

Sindy that is one amazing reply. Thank you so much for your attention to detail and taking the time. I can confirm that add this to the NAT table works:

add action=accept chain=dstnat comment="This Works" \
dst-address-list=Private ipsec-policy=in,ipsec src-address-list=Private

I'm a bit concerned that you think that there is a better way to setup the device from a security perspective. Would you mind sharing your preferred setup script so I can take a look?

Once again, a truly impressive and comprehensive reply of which I'm most appreciative.

Thanks

Duke

sindy · Tue Feb 13, 2018 11:49 am

Would you mind sharing your preferred setup script so I can take a look?

Have a look at the "ip firewall filter" part in the output of "/system default-configuration print":

/ip firewall

filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
                       
filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf:  drop all from WAN not DSTNATed"

You can see that in this default configuration, the last rule in each of the two chains is almost "drop the rest" - actually with some exceptions in order to limit the total number of rules, but that does not change the concept. Before that last rule, there are some exceptions saying what to accept.

So basically, you can convert your current firewall filter into a "deny all, permit exceptions" one the following way:

put before all existing rules in both "input" and "forward" chains a rule for "connection-state=related,established" (leaving aside fasttracking for the moment as you seem not to use anyway) without any additional conditions ("action=accept" is the default action)
in both chains, put right below it a "drop" rule for "connection-state=invalid"
in chain "input", put right below it two rules accepting management access and DNS access from LAN:
"chain=input in-interface-list=LAN protocol=tcp dst-port=22,23,53,80,443,161,8080" ("action=accept" the default action)
"chain=input in-interface-list=LAN protocol=udp dst-port=53,161" ("action=accept" is the default action)

By doing that you make sure that when you later add the rule with "action=drop" and no conditions as the very last one in both chain, you won't lose management access from LAN.
Now you put right below these new rules listed above a list of "action=accept" rules for everything you want to permit (this will probably include a duplicate of the two last rules above with "ipsec-policy=in,ipsec" instead of "in-interface-list=LAN"). Next, you list "action=reject" and eventually "log=yes" rules for whatever want to deny with a reject (informing the sender about the rejection using icmp) and eventually log that you did so, next, you list "action=log" rules for whatever you want to silently drop and log that you did so, and as the very last rule you put "action=drop" with no conditions.

After doing so, you can delete those old rules which you haven't reused as new ones.

CZFan · Tue Feb 13, 2018 5:15 pm

I will add 8291 to rule below to allow winbox

"chain=input in-interface-list=LAN protocol=tcp dst-port=22,23,53,80,443,161,8080" ("action=accept" the default action)

sindy · Tue Feb 13, 2018 6:42 pm

I will add 8291 to rule below to allow winbox

"chain=input in-interface-list=LAN protocol=tcp dst-port=22,23,53,80,443,161,8080" ("action=accept" the default action)

Well, I have basically copied the port list from the existing firewall rule:

add action=drop chain=input comment=\
    "BLOCK new TCP Mikrotik Services Requests that are NOT internal" \
    connection-state=new dst-port=22,23,53,80,443,161,8080 log=yes protocol=\
    tcp src-address-list=!Private

But you are right that as the original rule is a "drop" one, the intention may have been to permit Winbox (8291) from anywhere so the fact that it is missing in the "accept" rule could cause trouble if the OP is using Winbox.

AwesomeDuke · Mon Feb 19, 2018 12:34 am

Sindy,

Thank you so much. Sorry it has taken a while for me to get back to you, but I've been away.

I will give these rules a go when I get an opportunity. Thank you so much again.

Duke

IPSec VPN Problem

IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Re: IPSec VPN Problem

Who is online