Continuing on my zones in different subnets theme, but starting a new thread to improve readability...
The other problem I have been experiencing can be "solved" with the right ipf.conf incantation (I think). Lets pretend the host (zone) mail-fe-1 initiates a connection to dirsrv-lb (load balancer) on port 389/tcp. The Load balancer decides to send that connection (dnat) to host (zone) dirsrv-1, which happens to be on the same physical server (global zone) as the mail-fe-1 zone... (all networks below are /24) So, according to mail-fe-1: LOCAL: mail-fe-1 (172.16.1.51) REMOTE: dirsrv-lb (172.16.1.30) ... and according to dirsrv-1: LOCAL: dirsrv-1 (172.16.3.31) REMOTE: mail-fe-1 (172.16.1.51) If these are all separate physical machines (or at least one physical machine per subnet), there would be no problems, because in order to get back to mail-fe-1 (172.16.1.51), the host dirsrv-1 (172.16.3.31) would use its default router (the load balancer), which would fix (snat) the source address to be dirsrv-lb (172.16.1.30), and everyone would be happy. Since they are on the same physical machine, even though they are on separate physical interfaces, they "find" each other as the packet is flowing out e1000g3, and comes back in e1000g1, but never really gets back because the Local/Remote addresses don't match, so mail-fe-1 never sees the S/A. The host based firewall (ipf) gets scared and confused and blocks the packet, but I don't think that it would even matter if IPF wasn't being used, because I had this problem in the past without ipf or any firewall with everything on the same subnet. Same issue, the packet was returned directly instead of via the wire where it would have (presumably) flowed through the load balancer and gotten fixed. I can obviously workaround the issue by using source-nat in the load balancer, causing dirsrv-1 to think that the connection came FROM the load balancer (or one of its nat-pool IP addresses) to force the packet onto the wire, but that makes logs useless on dirsrv-1 and troubleshooting a who made what changes issue a nightmare. I am sure there must be a way to tell ipf to force packets from the be- net to the fe-net to go out on the wire, presumably using "dup-to" but I was unable to make it work, so I am using source-nat at the moment. I look forward to hearing that someone else has already figured this out and here is how they did it, but for now I need to work on installing software on "mail-fe-1" because it was supposed to be working last Tuesday ;) Thanks in advance, Tommy _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
