I guess so 192.168.0.0/24 is not your real network as it's public ip ? You can use vlan on your switch to have a different logical network from the public ip one
Flows must go both way through Zen. Remote computer is waiting a tcp ack from the public ip it is connecting to, not another one. Dnat is the good profile to get real remote ip address. You should use tcpdump/wireshark on Zen,server and remote client if you can to figure out issue Your server should be hidden from direct internet access. Using a "*" for port would allow remote desktop & ssh & co, which is bad. Please only allow mail ports / load balanced one Cordialement, Mathieu CHATEAU http://www.lotp.fr 2015-06-15 23:38 GMT+02:00 Ernie Dunbar <maill...@lightspeed.ca>: > 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 >
------------------------------------------------------------------------------
_______________________________________________ Zenloadbalancer-support mailing list Zenloadbalancer-support@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
