Hi Robby, thank you for your detailed problem description.
As I can read, your farm configuration seems to be perfect, but note that
when you start a connection from the client side, a dnat association
between client-lb-backend is generated. The backend sees the client ip but
the client sees the balancer ip.
In the case that the backend initiates the connection for relay or similar,
there isn't any nat performed, so the backend is using the lb as a simple
gw and reach the router with its own ip, not lb ip.
So my recommendations are:
- check the default gw in the lb, it should be the router local ip
- confirm that the router recognizes the backends local network as a local
network to be routable to the internet.
Hope this helps.
Regards.
El 26/04/2013 10:09, "Robby Pedrica" <[email protected]> escribió:
> Hi Laura, Emilio and Friends
>
> V3 is great and offers one of the most important features, L4 mode.
> However I'm having some issues I hope you can help with. Some background:
>
> We have been running v2 without any serious issues for the last year. We
> have ldap, dns/udp ( for small work ), http and smtp farms. All work fine
> however the main issue is that the ZLB IP address is presented to the
> smtp service ( postfix ) instead of the connecting client. Therefore we
> can't do ACL-based restrictions on Postfix ( as ZLB IP is the only IP
> presented ). You can argue that we should be using smtp auth, but we have
> some devices or services that do not support auth so IP ACL is the only
> option. In any case, L4 mode in V3 is recommended by yourselves for
> performance
> reasons.
>
> Our layout is a primary private network of 192.168.9.x/24, with other
> local nets and default gateway through 192.168.9.1
>
> Under v2 we have:
>
> ---- internet ---- ( public IP | router | 192.168.9.1 ) ---- ( 192.168.9.2
> | ZLB ) --- ( 192.168.9.3/4 | real servers )
>
> The real servers do not only serve ZLB clients but also other clients
> that connect directly to them. Eg. we have proxies with high performanceDNS
> requirements that use real servers directly, bypassing ZLB. Squid
> supports multiple DNS servers in its config and does not rely on OS
> resolv.conf so ZLB not required there ). For http farm, real servers include
> the http files to serve up to ZLB clients. For DNS and SMTP however, the
> real server gets connections from ZLB clients and has to go to internet
> for smtp deliveries and DNS recursive lookups on upstream DNS servers.
>
> All of this works fine except for the client IP issue for postfix.
>
> So we have reinstalled and changed to v302. Under this scenario, and for
> L4 requirement, we have the following setup:
>
> ---- internet ---- ( public IP | router | 192.168.9.1 ) ---- ( 192.168.9.2
> | ZLB | 10.11.12.1 ) --- ( 10.11.12.3/4 | real servers )
>
> With real server default gw set to 10.11.12.1 and using an additional VIP
> address on ZLB for the farms ( 192.168.9.5 ), basic connectivity to the
> real servers works fine. So I can connect from a client through ZLB to the
> real servers on 25, and with DNAT option, real server smtp log shows
> connecting client IP address.
>
> But, real server can't connect out to internet through ZLB to deliver
> outbound email ... same with dns: the query comes into the real server
> via ZLB, but the real server can't query upstream DNS servers on internet
> for the answer. Is this by design or am I missing some configuration?
>
> I have an additional requirement as well: proxies ( some on 192.168.9.x
> and some on other local network available through 192.168.9.1 ) still need
> to query real server directly for dns lookups. So I have to add second
> interface on 192.168.9.x network on real servers, so that proxies can query
> them directly for DNS.
>
> ---- internet ---- ( public IP | router | 192.168.9.1 ) ---- ( 192.168.9.2
> | ZLB | 10.11.12.1 ) ---- ( 10.11.12.3/4 | real servers | 192.168.9.3/4 )
> ---- 192.168.9.1
>
> But this fails for other local networks because default gw on real server
> points to private network behind ZLB ( 10.11.12.1 ). i.e. there are 2
> paths to local net default gw, one through ZLB and one through directly
> connected network on 2nd NIC - which one works depends on real server
> default gw. I can't remove 10.11.12.1 as default gw on real servers because
> L4 mode won't work. I could add static route to 'other' local networks
> through 2nd NIC but this would not work for 192.168.9.x because the 2nd
> NIC on real servers already has that net directly connected. So you get
> asymmetric routing ... which doesn't work.
>
> Even if there is a solution to the routing issue, I still can't access
> internet though 10.11.12.1 from real servers ....
>
> As a temp solution, I'm doing the following:
>
> ---- internet ---- ( public IP | router | 192.168.9.1 ) ---- ( 192.168.9.2
> | ZLB | 10.11.12.1 ) --- ( 10.11.12.3/4 | real servers | 192.168.9.3/4 )
> ---- 192.168.9.1
>
> Default route on real servers is 192.168.9.1 through 2nd NIC. ZLB farms
> are set for proxy mode ... In this way I can have clients connecting
> through ZLB + clients connecting direct to real servers. Also real servers
> can connect through default gw on 2nd NIC to internet for DNS queries,
> smtp deliveries and other requirements.
>
> I'm not sure if I'm doing something really stupid here or if this
> scenario is not possible; at least it must be possible for real servers
> to access internet through ZLB for eg. smtp deliveries. But I may be
> missing something obvious.
>
> Your assistance is appreciated.
>
> Regards
>
>
> --
>
> Robby
> Pedrica<https://www.xstore.co.za/index.php/business-documentation-mainmenu-52/118-how-to-generate-an-efficient-support-request>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> Zenloadbalancer-support mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>
>
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
