Re: Modefg considered harmful

["Scott G. Kelly" <scott@airespace.com>]

Hi Derek,

Comments inline below...

Derek Atkins wrote:
> 
> "Scott G. Kelly" <scott@bstormnetworks.com> writes:
> 
> > Hi Michael,
> >
> > Michael Richardson wrote:
> > >
> > >   The degenerate case is a client connecting to a security-gateway/firewall
> > > of a small organization. It should get the same inner-address as when it is
> > > plugged into the organization LAN.
> >
> > In my experience, this leads to routing issues that are most easily
> > resolved by ensuring that remote access client addresses are *never*
> > assigned internally.
> 
> But that's not what I want..  I want my statically-assigned DHCP
> address regardless of whether I'm on the 100BaseT internal LAN, the
> 802.11 wireless lan, or connected via IPsec VPN.  I don't want to
> enforce an architecture where this is no longer possible.

Then you need to set up your routing infrastructure accordingly. I
didn't mean to imply that this cannot be done. What I meant is that in
most of the remote access vpn deployments I've seen, the routing
infrastructure was not very amenable to this. 

> I see no reason it SHOULDN'T be possible to allow this to work.  DCHP
> will already assign me the same address on the wired or wireless
> interface.  The only issue is getting that address via the IPsec
> gateway.

Actually, the issue for any given system that wants to talk to yours is
in determining the MAC address packets destined for you should be
forwarded to. In complex topologies where the same IP can pop up behind
router a, router b, or sometimes be directly connected, this can get to
be ...interesting. The mobile IP guys have been dealing with this from
day one.

Again, I didn't mean to say that it can't be done - only that it can be
problematic. It is *easier* if this can be avoided in remote access vpn
scenarios, and avoiding it is not difficult.

Scott