So I'm having a little trouble getting L4xNAT working. Keep in mind that I'm using our failover server for testing, which currently exists on a public IP address alongside our live server, which I eventually want to add to this server cluster. We're trying to upgrade our current live servers to a failover cluster using Zen, so it's probably a little trickier than normal. This is how my first attempt has worked out so far:
Default gateway for our network: 192.168.0.1 Zen IP: 192.168.0.7 Failover server IP: 192.168.0.22 Live server IP (currently unused and not part of any pool): 192.168.0.4 - create a new IP address at 192.168.0.30 on the Zen loadbalancer. - create new farm named "Mail" with the Profile "L4xNAT". - Protocol type is ALL - NAT type is DNAT - Load Balance algorithm is by Weight - Persistence mode is IP persistence (we'll need this later for POP because reasons) - Persistence time limit is 600 - Farm Virtual IP is 192.168.0.30 and virtual port is * for all. Then I add the first real IP server: Address 192.168.0.22, port *, weight 5, priority 1. On that failover server, I've removed the host's normal default gateway from the network settings and replaced it with 192.168.0.7. Again, to reiterate, the entire 192.168.0.0/24 network is actually our public class C IP network. 192.168.0.7 is actually the public, outside interface of the Zen loadbalancer, and I don't have a separate private IP network behind the loadbalancer like you'd see with regular NAT. I expect that this is necessarily what needs to happen, since ultimately the client is supposed to talk directly to the server after forwarding, is it not? Or do I have to set up a separate, private IP address space behind the Zen loadbalancer, like one would usually do with a NATed network? I'm a little unsure about how we'd manage to smoothly migrate our mail customers to the new cluster while keeping the old server running. This wasn't a problem when I set up the server farms with a TCP profile, and our initial testing was working fine - minus the inability to log the source IP of incoming connections. On 2015-06-15 12:32, Mathieu Chateau wrote: > Hello, > > I guess it's incoming smtp, else your wouldn't see any relay attempt. It's actually outgoing SMTP, on a public IP address, which is why we see the relay attempts. Spammers scan our ports and try to use our SMTP server to send mail. We've currently got a particularly stupid one who won't take "no relay for YOU!" for an answer for several days now. > > Using L4xnat should make your server receiving real remote ip address. > Then it must use zen as a gateway for reply. > > For SMTP, except if you only have 1 ip address, I do not see big > benefits, as MX are already meant to survive smtp server failure in > the whole internet. > > Tcpdump wouldn't be useful as you need the true IP in realtime to > block smtp connection and not accept it at all. Also needed for grey > listing. > > Cordialement, > Mathieu CHATEAU > http://www.lotp.fr [3] > > 2015-06-15 16:44 GMT+02:00 Emilio Campos > <emilio.campos.mar...@gmail.com>: > >> You can use tcpdump in the load balancer in order to obtain the >> origin IP. >> >> 2015-06-12 22:54 GMT+02:00 Ernie Dunbar <maill...@lightspeed.ca>: >> >>> Hi everyone. >>> >>> We're using the community edition of Zen Loadbalancer, and I've >>> noticed >>> a problem with logging incoming connections. Namely, that it >>> doesn't >>> exist. We've only set up POP and outgoing SMTP as a load balanced >>> service so far, but as a result of that our logs are now filling >>> up with >>> a lot of SMTP relay attempts. Setting up Fail2Ban on the >>> loadbalancer >>> would be pretty easy, if only we had any idea where these >>> connections >>> were coming from, but they're not showing up in any of the logs. >>> Is >>> there some setting that can turn this logging on? >>> >>> >> > ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Zenloadbalancer-support mailing list >>> Zenloadbalancer-support@lists.sourceforge.net >>> >> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>> [1] >> >> -- >> >> Load balancer distribution - Open Source Project >> http://www.zenloadbalancer.com [2] >> Distribution list (subscribe): >> zenloadbalancer-support@lists.sourceforge.net >> >> > ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Zenloadbalancer-support mailing list >> Zenloadbalancer-support@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >> [1] > > > > Links: > ------ > [1] > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support > [2] http://www.zenloadbalancer.com > [3] http://www.lotp.fr > > ------------------------------------------------------------------------------ > > _______________________________________________ > Zenloadbalancer-support mailing list > Zenloadbalancer-support@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support ------------------------------------------------------------------------------ _______________________________________________ Zenloadbalancer-support mailing list Zenloadbalancer-support@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
