At 10:11 02/03/01 -0600, Gary Maltzen wrote:
>On Mon, 26 Feb 2001, BN wrote:
>
> >At the time, mouss pointed out that most stacks do not
> >remember the interface they received a packet on when making outbound
> >routing decisions (for the WWW response). I didn't believe it at the time,
> >and tested it in the lab. I can report that humbling "learning experiences"
> >are good for the soul. ;)
>
>A truly surprising result; I would've thought that a TCP connection would
>reply using the incoming IP - or perhaps I misunderstand the process of
>assigning an IP to a NIC.
Most people here got confused about NICs and addresses. The latter are part
of the IP
protocol. The former is part of Ethernet and the like. Two different things.
The confusion comes from the fact that you generally give a NIC an address and
vice-versa, but this is just the general (aliases give you the possiblity
of having many
addresses for a single NIC, and ARP/promiscuous mode/* give you the
possiblity of having
multiple NICs for a single IP).
When you config a NIC, you are just doing 2 things:
- adding the addr to the list of local addresses, so that the host
accepts packets sent
to it (and here, you'll note that which NIC has which addr is not important)
- sending replies to ARP apckets saying "I am the guy", and once this is
done, there is no
more need to know which NIC has which addr.
Back to our problem, let me give another of my silly examples (My
apologies, Ben, I can't
live without silly examples:). When you receive a letter from your lovely
german Betty, and you reply to her, there is no need that the reply takes
exactly the reverse
way as the original letter. That's just it, nothing more.
So, receiving a packet through NIC1 doesn't mean you'll send the answer
through NIC1.
IP is stateless. TCP helps in keeping the original destination address, so
that replies use it.
but it doesn't save the original receiving NIC (so as to allow you use
multiple NIC to get more
throuput...). so, your response won't get through the NIC that received the
initial request.
>This may explain anomalies I've seen when using multiple IP addresses on a
>single card - the incoming request was to a static NAT but the outgoing
>response went through the NAT pool. (I sent a message to George and got
>the reply from Howard??)
>
>This could make (reflective) firewall nightmares:
> the outgoing request from frank:2345 to george:80
> establishes an inbound reverse permit from george:80 to NATfrank:2345
> but the response from howard:80 to NATfrank:2345 would be denied.
This is normal and good. Suppose you ask George and the malicious Howard
replies! do you want your FW to allow it?
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
