kiwistag
asked on
Postfix issues with spam/auth attempts under NAT
On my mailserver I have moved from a public I.P to a NATted interface. Since then any errors or connections from the web only show the router as the connection source.
Is there any way for me to sort it so that it can route back to the originator?
Obviously Fail2Ban can't do much to stop it if it can't see the originating I.P.
Jun 16 12:12:07 nphosting dovecot: pop3-login: Login: user=<validuser@domain.com>, method=PLAIN, rip=192.168.0.254, lip=192.168.0.68, mpid=7987
Jun 16 12:12:10 nphosting dovecot: pop3(validuser@domain.com): Disconnected: Logged out top=0/0, retr=4/114129, del=4/52, size=1166078
Jun 16 12:12:43 nphosting postfix/smtpd[7705]: connect from unknown[192.168.0.254]
Jun 16 12:10:09 nphosting postfix/smtpd[7705]: warning: unknown[192.168.0.254]: SASL LOGIN authentication failed: authentication failure
Jun 16 12:10:10 nphosting postfix/smtpd[7705]: lost connection after AUTH from unknown[192.168.0.254]
Jun 16 12:10:59 nphosting postfix/smtpd[7815]: connect from unknown[192.168.0.254]
Jun 16 12:11:00 nphosting postfix/smtpd[7705]: 250815F15A: client=unknown[192.168.0.254]
Is there any way for me to sort it so that it can route back to the originator?
Obviously Fail2Ban can't do much to stop it if it can't see the originating I.P.
ASKER
It's the internal address of my WAN router. It has mutiple internal VLANs and a secondary WAN connection on it as well.
Do you have external from Internet access to the postfix server?
How are the inter vlan access configured, are any nated?
Other than the log entries, what issues are you seeing?
How are the inter vlan access configured, are any nated?
Other than the log entries, what issues are you seeing?
ASKER
I have external access to the server if that's what you mean. Yes - inter-vlan is NATted.
Here is the question whether the reported error is from an inter-vlan device that is misconfigured/testing versus an externally originating from your network.
The issue I see is that an externally generated access attempt will reflect the external public IP as the source of the connection and not your internal IP.
Does your router/firewall include SMTP proxy and that might be part of that app that checks the availability of the port.
Check the log to see whether this even occurs on a regular basis consistently e dry 10 seconds, etc.
grep -i 'connect from unknown\[192\.168\.0\.254\ ]' /var/log/maillog
Does your system have VPN based users as well?
E firewall in an effort to capture/narrow down the source.....
The issue I see is that an externally generated access attempt will reflect the external public IP as the source of the connection and not your internal IP.
Does your router/firewall include SMTP proxy and that might be part of that app that checks the availability of the port.
Check the log to see whether this even occurs on a regular basis consistently e dry 10 seconds, etc.
grep -i 'connect from unknown\[192\.168\.0\.254\
Does your system have VPN based users as well?
E firewall in an effort to capture/narrow down the source.....
ASKER
No SMTP Proxy.
I'll have a look on the Router for any settings that may be causing the issues.
I'll have a look on the Router for any settings that may be causing the issues.
ASKER
I suspect that I.P masquerading is calling the issue.
Ip masquerading?
This seems as a check.
This seems as a check.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The unknown means there is no DNS revord for the ip meaning the system with the ip did not register the reverse pointer record.
Make sure this ip us not your monitoring setup that only tests whether the port responds.
It seems as though a connection is initiated and issues an initial notice and upon receiving an acceptable response drops the connection. Or the timeout setting on the check is not enough to complete.