Port Forwarding without effecting Site to Site IPSEC Tunnel

RouterOS General
1

Hello,

I have successfully got my IPSEC tunnel function properly from my house to a local datacenter where my esxi server is. I have a VPN server running on the host in order to VPN into my network. This requires a number of ports to be forwarded, one of them being 443. I attempted making a NAT forwarding rule but when I do this it takes any traffic and forwards it to the server. This breaks my IPSEC Tunnel. When I connect to esxi, and idrac in chrome (this is over 433) I will not be able to connect with the rule active. The end result is I need to forward a number of ports to 192.168.89.4 without breaking the IPSEC tunnel. Below is the current rules I have setup in the router. Thank You.

/ip ipsec peer profile
add name=profile_1 nat-traversal=no
/ip ipsec proposal
set [ find default=yes ] lifetime=0s
add auth-algorithms=md5 enc-algorithms=aes-128-cbc,3des name=proposal1 pfs-group=none
add auth-algorithms=md5 enc-algorithms=3des name=proposal2 pfs-group=none
/interface l2tp-server server
set ipsec-secret=********* use-ipsec=yes
/ip address
add address=192.168.89.1/24 comment=defconf interface=ether2-master network=192.168.89.0
add address=208.x.x.x/24 interface=ether1 network=208.x.x.x
/ip cloud
set ddns-enabled=yes
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid interface=ether1
/ip dhcp-server network
add address=192.168.89.0/24 comment=defconf gateway=192.168.89.1 netmask=24
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip dns static
add address=192.168.89.1 name=router.lan
/ip firewall filter
add action=accept chain=input comment=winbox dst-port=8291 protocol=tcp
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.88.0/24 src-address=192.168.89.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat disabled=yes dst-address=208.x.x.x dst-port=443 protocol=tcp to-addresses=192.168.89.4 to-ports=443
add action=dst-nat chain=dstnat disabled=yes dst-address=208.x.x.x dst-port=4500 protocol=tcp to-addresses=192.168.89.4 to-ports=4500
/ip ipsec peer
add address=73.x.x.x/32 profile=profile_1 secret=**********
/ip ipsec policy
add dst-address=192.168.88.0/24 sa-dst-address=73.x.x.x sa-src-address=208.x.x.x src-address=192.168.89.0/24 tunnel=yes
/ip route
add distance=1 gateway=208.x.x.x
add distance=1 dst-address=192.168.88.0/24 gateway=bridge
2

Don’t be affraid to share more info (like clear description where each subnet is, how exactly is ipsec configured, or just your whole config to eliminate all need to guess things), it can only help.

3

I have updated the post with all the config information you should need. If there are any other questions please let me know. Thanks!

4

It’s better. So this is config from home router, it has LAN .89 and WAN 208.x, datacenter has LAN .88 and WAN 73.x, right?

Other than your firewall filter being useless (default action is accept, so just one accept rule doesn’t do anything useful and everything on router is wide open) and same for the first NAT rule (it looks like masquerade exception for tunneled traffic, but it’s not needed when masquerade rule has ipsec-policy=out,none), I don’t see any problem.

Both dstnat rules have dst-address=208.x, so they only apply to connections to this address and given ports. IPSec definitely doesn’t use tcp/443 and shouldn’t use tcp/4500 either. An udp/4500 is used for NAT traversal and while it seems that tcp/4500 might be possibly used too, I don’t remember seeing that.

5

Thank you so much for your response. You are almost correct. 208.x with .89 LAN is the Datacenter which is where the config is from and 73.x with .88 LAN is home.

I am not sure I completely follow what you are trying to say in the second paragraph. I have knowledge with some things but not others, would you mind elaborating?

The dstnat rules are intended to be unrelated to the IPSEC tunnel as they are needed for my VPN server which uses 443,4500 and some other porst as well. (VPN Server 192.168.89.4) When I turn that rule(s) on it takes any 443 traffic coming from 208.x - which seems to include the ipsec tunnel traffic - and forwards it to 192.168.89.4, as a result I am unable to access anything at the datacenter over 443 from my house because it is being forwarded to the VPN server. (for example when I connect to my esxi host via chrome that uses 443, it is unreachable when that rule is on) Hope this makes sense. Thanks again!

6

Let’s start with the easy part. If everything you have in “/ip firewall filter” is the single rule you posted, it’s as if you didn’t have anything there at all. When you take in account implicit behaviour (which is to accept anything not matched previous rules), your whole firewall is:

/ip firewall filter
add action=accept chain=input comment=winbox dst-port=8291 protocol=tcp
<add action=accept chain=input comment="default policy">
<add action=accept chain=forward comment="default policy">

It allows absolutely everything. Any service running on router is reachable from anywhere if you didn’t disable it. Since you have remote DNS requests enabled, your router is open resolver (it’s bad). Forwarding is allowed from anywhere to anywhere. Probably not what you want either.

With srcnat, it’s nothing critical, just that fist rule is not really needed. It stops processing in srcnat chain, which means that packets from local .89 LAN to remote .88 LAN won’t reach following masquerade rule. But even if they did, it wouldn’t take them, because they match existing IPSec policy, so they don’t match ipsec-policy=out,none.

And now the main problem. I still don’t see it. This rule:

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=208.x dst-port=443 protocol=tcp to-addresses=192.168.89.4 to-ports=443

matches tcp traffic to 208.x.x.x:443 and that’s all. If you’re connecting to any 192.168.89.x:443, this rule won’t touch it. There must be something else.

7

Sob,

The first part of your reply doesn’t sound too good. What can we do to secure that?

As for the main issue, I went ahead and re added the rules and for some reason it worked this time. IPSEC tunnel traffice over 443 is no longer effected. I guess we will have to chalk that up to human error somewhere along the lines, but I honestly could not tell you where. I then added the neccessary NAT rules for the VPN server. I am successfully able to connect via 443 on my Win 10 Machine with the SoftEther Client installed on my machine. However, L2TP is being rejected. I went back to my phone and changed the IP to the local ip address and it connected successfully so I know there is a router misconfiguration somewhere I am just not sure where. Here are all the NAT Rules


chain=srcnat action=accept src-address=192.168.89.0/24  dst-address=192.168.88.0/24 log=no log-prefix="" 
;;; defconf: masquerade
 chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
chain=dstnat action=dst-nat to-addresses=192.168.89.4 to-ports=443  protocol=tcp dst-address=208.x.x.x dst-port=443 log=no log-prefix="" 
chain=dstnat action=dst-nat to-addresses=192.168.89.4 to-ports=500   protocol=tcp dst-address=208.x.x.x dst-port=500 
chain=dstnat action=dst-nat to-addresses=192.168.89.4 to-ports=992 protocol=tcp dst-address=208.x.x.x dst-port=992 
chain=dstnat action=dst-nat to-addresses=192.168.89.4 to-ports=4500 protocol=tcp dst-address=208.x.x.x dst-port=4500 
chain=dstnat action=dst-nat to-addresses=192.168.89.4 to-ports=1194 protocol=tcp dst-address=208.x.x.x dst-port=1194

I do have another question. I need access to a physcial network that is at the Datacenter. I am hoping to connect that network via an ethernet cable from the switch to my router. I will need to access this network over the IPSEC tunnel from my hosue. Is this possible or is there a better way this should be handled?

8

For first part, some firewall rules would help. I can never find config for default RouterOS firewall, so let’s take the following as source of inspiration instead. First access to router itself:

/ip firewall filter
add action=accept chain=input connection-state=established,related comment="allow established & related"
add action=drop chain=input connection-state=invalid comment="drop invalid"
add action=accept chain=input in-interface=ether2-master comment="allow access from LAN"
add action=accept chain=input protocol=icmp comment="allow icmp"
add action=accept chain=input dst-port=22,8291 protocol=tcp src-address-list=Admin comment="allow admin access"
add action=accept chain=input protocol=ipsec-esp src-address-list=IPSec
add action=accept chain=input dst-port=500,4500 protocol=udp src-address-list=IPSec
add action=log chain=input log-prefix="DROP" comment="log what will be dropped" 
add action=reject chain=input reject-with=icmp-admin-prohibited disabled=yes
/ip firewall address-list
add address=73.x.x.x list=Admin
add address=73.x.x.x list=IPSec

First two rules is standard config, check wiki for explanation of connections states, #3 allows access from LAN (it’s possible that you may want to further limit that), #4 allows icmp (good for debugging), #5 allows admin access from whitelisted addresses. Rules #6-7 allow IPSec traffic for your tunnel (since you have only one peer, you don’t need whole world probing those ports). Final rule should reject or drop everything else unconditionally, but to prevent the risk of blocking something you don’t want to block (and end up locked out), it’s better to start with only logging what would be blocked (#8) and only when you’re sure that you allowed everything you need, enable the last rule (#9). Forward has similar logic:

/ip firewall filter
add action=accept chain=forward connection-state=established,related comment="allow established & related"
add action=drop chain=forward connection-state=invalid comment="drop invalid"
add action=accept chain=forward in-interface=ether2-master out-interface=ether1 comment="allow access from LAN to internet"
add action=accept chain=forward ipsec-policy=in,ipsec out-interface=ether2-master comment="allow traffic from IPSec tunnel to LAN"
add action=accept chain=forward connection-nat-state=dstnat comment="allow forwarded ports"
add action=log chain=forward log-prefix="DROP" comment="log what will be dropped"
add action=reject chain=forward reject-with=icmp-admin-prohibited disabled=yes

If anything is not clear, read more about it or ask.

Then your forwarded ports. I assume you mean L2TP/IPSec, which means that you probably don’t want to forward tcp 500 and 4500, but udp. Slight problem is that those are also needed for your manual IPSec tunnel. But you can easily exclude your 73.x.x.x peer:

/ip firewall nat
chain=dstnat action=dst-nat to-addresses=192.168.89.4 protocol=udp dst-address=208.x.x.x dst-port=500 src-address-list=!IPSec
chain=dstnat action=dst-nat to-addresses=192.168.89.4 protocol=udp dst-address=208.x.x.x dst-port=4500 src-address-list=!IPSec

I think you don’t need to forward ESP packets, because if the server is behind NAT, it should only use udp on port 4500.

The last question, do you mean 192.168.89.0/24 or another network connected behind same router?

9

Do you have FastTrack enabled on your router?

If so, follow this article: https://saputra.org/threads/mikrotik-fasttrack-with-ipsec.34/

10

Sob,

Sorry it has been a while. The network has evolved a little since we last spoke. I am now using an OpenVPN server, so we no longer have to worry about L2TP traffic. Here is my current firewall config

/ip firewall filter> print
chain=input connection-state=established,related
chain=input action=drop connection-state=invalid log=no 
chain=input action=accept protocol=icmp log=no
chain=input action=accept protocol=tcp src-address-list=Admin dst-port=22,8291
chain=input action=accept protocol=ipsec-esp src-address-list=IPSec log=no
chain=input action=accept protocol=udp src-address-list=IPSec dst-port=500,4500 log=no
chain=input action=drop protocol=tcp in-interface=ether1 dst-port=53 log=no
chain=input action=drop protocol=udp in-interface=ether1 dst-port=53 log=no

/ip firewall nat> print
chain=srcnat 192.168.88.0/24 log=no
chain=dstnat action=dst-nat to-addresses=192.168.89.6 to-ports=1194 protocol=udp dst-port=1194
chain=srcnat action=masquerade out-interface-list=WAN log=no

/ip firewall address-list
Admin 73.x.x.x
IPSec 73.x.x.x

When I am connect to the VPN I am given a 192.168.90.0/24 address, which is great. I am able to get to the internet and access anything on the 192.168.89.0/24 network. Furthermore, I can ping devices on the 192.168.88.0/24 network but I cannot connect over RDP to my local machine. I believe this could be because the .88.1 router has no idea where to send .90 traffic back to, which should be back over the IPSec tunnel to 192.168.89.6. Any thoughts on how to fix this?

I added the log rule and have looked at the traffic. A good amount of the traffic is running on random ports so that is ok to be dropped. However, it also looks like there is traffic running to 1194 which is import to the vpn to work properly. Do you think this is unimportant traffic or would it cause problems with the vpn?

You also had LAN access rules which I have never had before. My LAN works just fine besides this .90 traffic issue. When I go to add that rule I get an error message “-- in/out-interface matcher not possible when interface (ether2-master) is slave -use master instead (bridge)”’
I did not want to switch it to bridge and possible break something, but will if that is what’s needed.

I only have the input chain rules in there currently. Do i still need to add the forward rules?

Thank you for your help so far. It is greatly appreciated.

11

On the hXX product line, /system default-configuration print always gives you the default firewall rules of that ROS release (among a lot of other things of course) which you can copy-paste. If all you have handy are boxes for real men, you’re out of luck and have to compose it from scratch as you did :slight_smile:

12

Yes, it’s been a while, I already forgot everything about this, so sorry if there will be anything missing or wrong.

Your firewall is still pretty much useless, because you drop only packets with connection-state=invalid and access to DNS resolver from internet. Everything else is still allowed by implicit (and invisible) action=accept at the end.

If you can ping devices on .88 network, you should also be able to connect to anything on same network. Routing applies the same way to ping, RDP and everything else. On the other hand, your theory about routes also makes sense, you need specific routes to any destination if it’s not reachable via default route. If you are aware of missing route, add it.

Port 1194 is used by OpenVPN. So if you’re going to block the rest, you need accept rule for this in input chain.

Forward rules may not be critical, because attempts to access your internal network will be most likely filtered by ISP. But it’s better to have them, they don’t do any harm and why not have complete protection when you can.

The ether2-master was LAN interface when you posted original config. If you changed it, use the new one. It’s possible that it was changed automatically, if you originally had older RouterOS and you upgraded to newer version, because it removed master port and replaced it with bridge.

@sindy: I meant ideally some MikroTik’s page with current default firewall that I could just link to. If I should export firewall from some device, I can as well take it from some backups I have and it’s even easier.