[replying on-list for completeness] On Wed, 2007-12-05 at 14:57 +0000, Steve Drew wrote: > access-list from-dmz2-network extended permit ip object-group > dmz1-network any > > (The dmz1-network object group is for the subnet the VIP/LB sits on) > > I get: (with ip verify reverse-path interface dmz1-network) > > Deny TCP reverse path check from host-lb0 to external.ip.address on > interface dmz2-network
That's to be expected - the dmz2 interface is defining the network it expects to see, so the return packet hitting the input on dmz1 is an anomaly. > and ( no ip verify reverse-path interface dmz1-network) > > %PIX-6-106015: Deny TCP (no connection) from host lb0/80 to > external.ip.address/1083 flags SYN ACK on interface dmz2-network Right, now I get it. The PIX builds a connection table. I forget the hash mechanism, but it's some analogue of: src_ip/src_port/dst_ip/dst_port/input_interface/output_interface The connection has for your packet will be something like this, in pseudo-code: 1.2.3.4/30251/lb0/80/external/dmz1 So when the return packet comes back on dmz2 the hash would be (for the returning packet): lb0/80/1.2.3.4/30251/dmz2/external Everything matches bar the input interface, so the packet gets dropped. This is a fundamental design principle of the PIX - if I ain't seen one half of this conversation on this port, I ain't letting that packet through. (unless it's a SYN, inbound, of course!). I'd recommend moving your realservers to the same DMZ. Having them separated seems rather over-complicated, as you've found. Graeme _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
