|
[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
|
