Need help making a RB2011 pass outside IP address info to local LAN addresses

I have a RB2011UiAS-RM That has been configured for years and has been working well. However, I have a pesky little problem with some Linux based Asterisk servers on my local LAN needing to know what the outside IP address is of connections coming in…

I have a static outside IP address with a simple 192.168.1.x local LAN address scheme.

The Linux servers on my local LAN report something like “Remote connection from 192.168.1.1” (my gateway local LAN address) when I want it to report the actual real world outside IP address coming in so I know where it actually came from in my logs and proper operation…

I have googled until my eyes bled and I still have no clue how to “pass” the correct info to my LAN based Linux servers…

I am using mulitple Raspberry Pi Linux Asterisk boxes connected to ham radios that talk all over the globe. And those Asterisk boxes really want to hear where those outside IP addresses are coming from because that tells them what “nodes” are talking to it. For them to only hear my local 192.168.1.1 gateway address is unacceptable for them to know who they are really talking to…

I am hoping there is a simple configuration line in my filter rules I have inadvertently missed to make this work properly…

Any help would be appreciated!

Bill - N5MBM
www.n5mbm.net

My guess is that there’s some error in NAT rules, proper DST-NAT rules pass remote IP unchanged to internal host. But we’ll never know unless you post configuration export from RB2011 with sensitive data obfuscated.

I’m not sure how to do what you ask for… I am using Winbox to access my router and I don’t see an option to output my config to something that is readabl and editable - (that doesn’t mean it isn’t there, I just don’t know where it is…).

I wouldn’t be surprised if it is something that is fat fingered or misconfigured.

Bill

I’m not using Winbox, so I can’t give you direct advice. Console comand

/ip firewall export hide-sensitive

will export only firewall configuration.

Thanks, I ran the command and WOW, that’s a lot of info!

But here ya go…

Bill - N5MBM
configtext.txt (28.4 KB)

Some bad news - your configuration deserves some fixes due to security reasons (and some simplifications to make it more readable, too.)

First of all,

add action=accept chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=invalid in-interface=\
    all-ethernet

makes no sense (please note the line begins with “allow”, but there is “drop” in comment - solely this fact indicates that this line is nonsense), it should be:

add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether1

This will block any incoming unwanted traffic on ether1, and it will make your configuration’s “blacklist” and “attack” filters unnecessary. Now your current config is not effectively filtering incoming traffic and for example you winbox (tcp8291) port is fully accessible from the internet.

Using “blacklist” in your configuration is obscure, your router must be secured to be immune of attack from any IP, not only from a few blacklisted. (You have “china” blacklist, but not “DPKR” blacklist, do you really believe that there are no rogue hackers/bots in DPKR ? Obviously there are millions rogue IPs worldwide, it is not possible to blacklist them all.)

So, it is necessary to secure your firewall rules first.
Secondly, it will be possible to delete all the “blacklists”, which are quite ineffective, and only makes you configuration unnecessarily complicated and hard to read.
Then it would be possible to repair your NAT problem.

And some good news - the line which causes the issue you are asking for solution is

add action=masquerade chain=srcnat comment="Masquerade inbound" to-addresses=192.168.1.61

(this line causes all traffic to 192.168.1.61 to be masqueraded, so it seems to be from 192.168.1.1 ), but this line is the smallest problem in your configuration. Let’s fix the security and readability issues first.

Additional (randomly picked) errors and weird lines:

add action=dst-nat chain=dstnat comment="Email IMAP listener port" dst-address=209.112.233.252 dst-port=143 protocol=tcp to-addresses=192.168.1.67 \

allows port tcp/143 for unsecured/unencrypted IMAP. Are you sure you want to use unsecured IMAP on port 143 instead of secured 993 port ? (google “IMAP uses port 143, but SSL/TLS encrypted IMAP uses port 993”)

Thanks for your help szt!

I fixed the first line you mentioned with the first fix that you posted and everything is still up and running and nothing seems to be “broke” for the time being… So I am happy…

Honestly, I am not a MikroTik guy. I was trained on Cisco and Nortel gear – but that was a long time ago and my router skills aren’t what they used to be – (I’m retired!).

All that stuff with black lists and stuff was my desperate attempt at shutting the door on a BUNCH of traffic from overseas into my mail server several years ago. I was literally getting hammered SO hard that it was totally taking up my 8mbps internet connection. Strangling it to the point that even simple web cruising from here was a real pain in the assets…

So I made an admittedly clumsy attempt at blocking traffic from entire regions of the world – especially those that filled up my logs with failed attempts to login.

I am ALWAYS up for a much more simpler solution! Thank you!

As to you second posting about “the solution”, I am not following you on this…
“add action=masquerade chain=srcnat comment=“Masquerade inbound” to-addresses=192.168.1.61“

I have several VOIP servers that need to see the real world IP addresses coming in on my internet lan port… not just 192.168.1.61.

Also I had to leave port 143 open to be able to send email to gmail users after some issues we gave up and left that port open.

Thank you again for your help!

Bill – N5MBM

Thanks for your explanation and report, so let’s correct another bugs in your config.

add action=accept chain=input comment="defconf: drop all from WAN" in-interface=all-ethernet

is another buggy rule - first of all, like some rule mentioned in my previous post, this rule has also comment (drop) which does not corelate with the rule’s action (accept).

This rule accepts all input traffic from all ethernets (included ether1, which is WAN for you). And it is the third line in your input chain, just before any drop rule. So, it allows literally all incoming traffic from the internet. So, rule

add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether1

should be moved upwards just before mentioned rule, to take a chance to have some effect. (Please note that when Mikrotik processes the rules, it stops processing on first matching rule. Generally, any such benevolent (“accept all” type) rule should not be at the top of firewall chain.

To make your config more readable:

I understand that some of the “blacklist” are now obsolete, could you please delete all the obsolete lines from your config (but safely-only those you are 100% sure that they are obsolete now) ?
Could you please correct all the firewall rules comments to corelate the comments to the firewall rules itself ? (or add “???” to the comment string when unsure about the rule meaning) ?

Then please export actual config and post it here again.

About the

add action=masquerade chain=srcnat comment="Masquerade inbound" to-addresses=192.168.1.61“"

rule:

You have this line in your exported config (line 111), what is the intended meaning of this line (how do you understand this rule)? Or, theoretically, what do you expect to happen if you delete this line?

About port 143-IMAP protocol is protocol for reading email, not for email delivery. Additionally, gmail does not nowadays support unsecured IMAP at port 143 (see https://support.google.com/mail/answer/7126229?hl=en, it supports only 993), there is no link between gmail and unencrypted IMAP. So, gmail can not be the reason to keep port 143 open. Unencrypted service (e.g.IMAP) is such security risk that it deserves further investigation why is it necessary.

I changed the masquerade - if I remove it completely my internal network can’t resolve my own domains network addresses from the internet.

I also moved some of the disabled entries. They are now down at the bottom of things to make it more readable.

I hesitate to take out some of the country list blacklists as I am still seeing traffic hit the front end of the router from time to time… But not much lately.

Here’s the updated config output - please tell me what you think…

Bill - N5MBM
config08192018Test1.txt (30.6 KB)