So in other words, for a DNAT network type, we turn the Zen load balancer into a NAT router, with a private IP space on the inside interface?
That makes it a little harder to migrate existing live servers, but I suppose it can be done. On 2015-06-15 22:25, Mathieu Chateau wrote: > I guess so 192.168.0.0/24 [1] 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 [2] > > 2015-06-15 23:38 GMT+02:00 Ernie Dunbar <[email protected]>: > >> 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 [1] 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 [2] [3] >> >>> >>> 2015-06-15 16:44 GMT+02:00 Emilio Campos >>> <[email protected]>: >>> >>>> 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 >> <[email protected]>: >>>> >>>>> 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 >>>>> [email protected] >>>>> >>>> >> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >> [3] >>>>> [1] >>>> >>>> -- >>>> >>>> Load balancer distribution - Open Source Project >>>> http://www.zenloadbalancer.com [4] [2] >>>> Distribution list (subscribe): >>>> [email protected] >>>> >>>> >>> >> > ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Zenloadbalancer-support mailing list >>>> [email protected] >>>> >> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >> [3] >>>> [1] >>> >>> >>> >>> Links: >>> ------ >>> [1] >>> >> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >> [3] >>> [2] http://www.zenloadbalancer.com [4] >>> [3] http://www.lotp.fr [2] >> >>> >>> >> > ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Zenloadbalancer-support mailing list >>> [email protected] >>> >> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >> [3] >> >> > ------------------------------------------------------------------------------ >> _______________________________________________ >> Zenloadbalancer-support mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >> [3] > > > > Links: > ------ > [1] http://192.168.0.0/24 > [2] http://www.lotp.fr > [3] > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support > [4] http://www.zenloadbalancer.com > > ------------------------------------------------------------------------------ > > _______________________________________________ > Zenloadbalancer-support mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support ------------------------------------------------------------------------------ _______________________________________________ Zenloadbalancer-support mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
