> -----Original Message-----
> From: mouss [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 27 October 2000 10:40 PM
> To: Ben Nagy
> Subject: RE: Dual firewall question

[Background is in the thread mentioned above] 

[Offlist, I (incorrectly) wrote:]

> >Dual NIC systems that have default routes on each NIC will 
> route via the NIC
> >that is appropriate. In this case the http daemon would be 
> configured to
> >bind to two IP addresses. IOW the outgoing NIC would be 
> selected based on
> >the IP address that was used to connect to the httpd. Set it 
> up and try
> >it...

(maybe I should have taken my own advice earlier!)

[mouss:]
> that's where I don't agree. the correct IP address is 
> selected, that's 
> fine. but not the
> correct NIC. [...]

Yup - you're dead right.

My test environment was a 'host' box with two NICs and no ip forwarding, a
'router' box with three NICs and my test LAN which was pretending to be the
'net. The two 'internal' NICs on the 'router' connected via crossover cables
to the two NICs in the 'host' box.

When I connected to 10.1.1.1 (host, NIC1) from the outside, I _expected_
host to use NIC1 to source the response. Whoops.

With linux, at least, (which runs the BSD derived IP stack, AFAIK) it seems
to select a default route out of however many equal cost defaults it has (2
in this case) and stick to it. This means I had the strange situation of the
responses coming out via a different NIC, even though there was no IP
forwarding on the box.

That's the bit I thought was impossible (silly me) - IMO it should not send
packets out of an interface that has a different L3 address unless
configured to be a router. Kind of like local spoof protection...

> 
> cheers,
> mouss

Is there some reason I'm missing why this is a vital implementation choice
or would it be more 'secure' for the stack to effectively bifurcate on a
dual-NIC box?

Cheers,

--
Ben Nagy
Network Consultant, Volante Solutions
PGP Key ID: 0x1A86E304  Mobile: +61 414 411 520  
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to