Hi Support,
I have problem with sending email from my client device (UPS) to outside. I`m using my gmail account and enable it in gmail settings.
I setup according google manual for POP.
Does anyone know how to do it or how to properly NAT?
This is my conf.
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
8 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=no log-prefix=“”
9 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1 log=no log-prefix=“”
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=“”
Firstly, I feel I need to correct something here as I have seen a couple of people throw out their toys when they do not get a response or did not like the response they get. This is not Mikrotik “Support”, most of the people that respond / reply on here is not part of Mikrotik and does so in their own, personal free time capacity. So if you get any or no support here, keep in mind how much you paid for it.
Then, with the info you provided, I do not see anything that will cause the GMail on your UPS not to work, I suspect the problem is between your config on your device and GMail, not Mikrotik related at all
I would agree with @CZfan with one single exception. Your masquerade rule works if the packets from the LAN are sent to the internet via ether1. So if this is not true (e.g. you use PPPoE instead of having the IP address directly on ether1), this rule may not match the packets.
But the ultimate test is - if you can browse the web with this configuration from the machine which fails to download your e-mails from gmail, the issue is not caused by any of the Mikrotik firewall rules you’ve pasted here.
Or, if you want it hi-tech, if “/ip firewall nat print stats” shows some matches on the masquerade rule, the rule works fine.
Google has some configurable security policies which allow to “disable access from devices with lower security” (whatever that may mean), so maybe you have to lower the security requirements for POP3 (I hope you do use the TLS version of POP3, I haven’t seen the Google manual you refer to).
[quote=Kackele post_id=642978 time=1518794259 user_id=115363]
without all that crap
[/quote]
Which of those firewall rules you consider crap? What I can see is the default set of firewall rules with added https access from the whole world (which implies that Stanko is not a total beginner as https doesn’t run out of the box, and which also implies he’s unlikely to waste time setting that part up again) and restriction of Winbox access to a single IP on LAN. Yes, the functionality of these two rules is duplicated by the “/ip service” subnet list, but in the firewall they are visible at first glance.
Hi All,
I would like to apologize if I hurt someone with my statement “Support”
I realy meen that all of You in forum are support for us who are beginners in Mikrotik routers.
According to Yours suggestions,I`ll try with lower google security.
I`m wondering also what You mean crap rules?
I copy this rules from this forum guru guys, as default security for beginners and home use.
If You have any other suggestion for NAT and filter rules I would like to hear from You guys better suggestions.
Hi All,
You were right…it was problem in google configuration.
Google have two step verification security. But If You want to use your account on some app, You have to setup app permissions, to generate special password for this app only.
And it works.
But I would like Your opinion for my configuration. Its for home purpose only?
As you haven’t published anything but the firewall rules, I assume you want an opinion on that.
Your rule 3 actually does not restrict acces to the Winbox port of the Mikrotik only to our PC’s IP address because nothing in the filter chain “input” drops anything that comes from LAN. So rule 3 is an exception from a drop rule which either does not exist or you haven’t included it to the output.
As @Kackele has suggested in his specific manner, you can reach your declared goal (“Winbox u lokalu samo za moj racunar”) e.g. using the following:
ip service set [find where name=winbox] address=192.168.1.4
Or, if you don’t want to spend hours trying to understand in a year from now what the heck in the firewall prevents the WinBox access from other address then 192.168.1.4, while it would actually be the setting above, you can add the missing “chain=input action=drop” rule as the very last one in chain “input”. But in such case, you would have to create some other exceptions from such “drop the rest” rule for devices in your LAN, as they should probably all be able to access the DNS, NTP and DHCP services of the Mikrotik.
Your rule 4 permits access to Mikrotik’s https interface from anywhere in the IPv4 world as it constitutes an exception from the “drop all from WAN” rule in chain “input”. I assume this is what you wanted and so far TLS is considered secure so I cannot see anything crappy in it. You should just think again whether it makes any sense to restrict WinBox access to a single IP while access to WebFig is open for any source address while the user accounts and passwords are the same for both protocols and anything you can do using WinBox can also be done using WebFig.
Rule 8 comes from Mikrotik’s default configuration and I assume it is there to protect some weak network stacks of devices in the LAN from packets which do not match a current connection state (such as another SYN packet in an already established TCP session), so I wouldn’t dare to call it crappy.
Rule 9 also comes from Mikrotik’s default configuration and protects devices in LAN from getting packets sent to their address via WAN. The masquerade rule ensures that packets sent out via WAN (ether1 in your case) by devices in the LAN subnet will be forwarded to the internet with ether1’s own IP address as source, but it does not prevent packets coming in via WAN with destination address matching a device in the LAN subnet from being forwarded, so e.g. an attacker using the same ISP like you could gain access to a device in your LAN if this rule was not there. So it is definitely there on purpose.
More about the firewall filter concept in this and this post if the manual is not sufficient.
