[Chilli] [Layer3] Like uamallowed, but for source address - like macallowed but for IPs - ip source whitelist - server whitelist - Layer3: help with connections / dhcp connections

[Michele Bergonzoni]

> Is l3singledhcp really necessary? It is suppose to be able to track
> multiple "routers", not just one.

l3singledhcp is a "hack" and I understand very well why you won't commit 
it, but in my environment, without that, redirection doesn't happen 
(with or without ipsrcallowed).

I observed this sequence of events:

* Client 10.0.0.1 sends a DNS request
* DNS requests arrives to coova from MAC A
* Coova makes a dhcp connection for MAC A
* Coova makes a connection for IP 10.0.0.1
* Coova answers
* Client correctly receives the DNS answer
* Client sends a TCP SYN to 78.46.45.181 port 80
* TCP SYN arrives to coova from MAC B, different from MAC A
* Coova makes a second dhcp connection for MAC B

At this point, Coova sends a SYN/ACK to the client, from port 80 to the 
correct source (high) port, but it doesn't have 78.46.45.181 as the 
source. It has the source of the DHCP interface, i.e. uamipaddress. The 
client ignores this, of course, retries, and there is no redirection.

This sequence of events is related to some specific policy routing we 
are using in our L3 network, that has the side effect of consistently 
forwarding DNS requests on one path and the SYN on another.

In single-router environments the problem probably doesn't exist, in 
many redundant router environments with load balancing the problem can 
be intermittent and difficult to observe. If you decide to ignore it, 
you probably will not disappoint many people.

If you are interested, in my opinion, given my very limited 
understanding of coovachilli internals, the right and correct thing to 
do would be:

* Use a "special" dhcp connection, or no connection at all, for L3 clients
* When sending packets to an L3 clients, use the MAC address of the 
router, as found in the ARP table (as the linux kernel would do). The IP 
address of the router is not in coova configuration, it is in the 
routing table (of course we can put it also in the config).

Such a strict adherence to IP routing principles is surely better than 
sending to the same MAC you received from: the MAC that the router uses 
when transmitting packets to coova is not the same that coova should use 
when replying.

In all HSRP setups, packets coming from the router have the physical MAC 
address as the source, but when sending packets to the router, you are 
supposed to use the virtual MAC address as the destination, which is 
what the router tells you in ARP replies. This is because the virtual 
MAC is guaranteed to survive the fault of a single router.

The same is true for many other first-hop redundancy protocols and 
firewall clustering technologies.

Of course, with ot without a virtual MAC address, sending the SYN/ACK 
for the redirect with the uamipaddress as the IP source cannot work.

I really would have loved to implement this instead of l3singledhcp, but 
it was too difficult for me. With this hack, the fault of a router has a 
rough 50% probability of requiring coova restart.

You might want to forget all this, and when someone with an environment 
similar to mine will google up all this intricacies, we can hope to have 
her/him land here.

Best regards, thank you very much and keep up with your good work.

			Michele

-- 
Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a.
Phone:+39-051-6781926 e-mail: bergonz at labs.it
alt.advanced.networks.design.configure.operate