Re: (PM) PM2ER/PM3 source address (fwd)

Dick St.Peters (stpeters@NetHeaven.com)
Sun, 1 Feb 1998 16:24:57 -0500

Stephen Fisher writes:
> Yup.. I've always liked the idea of being able to specify source interfaces
> on Ciscos. Such as ip telnet source-interface ethernet 0 or ip radius
> source-interface ethernet 0. These would let you override the default
> action of just using the interface the data goes out of - it lets you
> specify which interface, such as ethernet, you want it to come from.

This would solve one problem, that of having the RADIUS packets coming
from a customer's address.

However, having a box respond to telnet (or anything) SYNs sent to one
of its interfaces with ACKs sourced from a different interface, even a
configurable one, is seriously broken, so any such config options
should affect only transactions initiated by the PM.

For people having trouble seeing what's at issue here, consider a
diagram of the actual case under discussion:

customer enet--> PM2ER/PM3 <--T1--> router <--network

When the T1 is down the router has no route to the customer's network.

When the T1 comes up, the router knows how to talk to the PM's WAN
interface immediately, but it doesn't have a route to the customer's
network until the PM and router establish an OSPF session.

Because the PM telnet responds from the Ethernet interface address, if
OSPF doesn't come up, a network admin can't telnet in to the PM to fix
things. I don't think pmconsole etc. can get to the PM either.

On the router the admin sees the T1 connection established. He (or
she) can ping the PM WAN interface. He just can't telnet to it.

On the PM, he can telnet to the router if it's a cisco or virtually
anything else, but not if it's a PM with a WAN address different from
its Ethernet address.

In my case, the router is a cisco; I could ping in both directions but
telnet in only one. (If a "telnet source-interface ethernet 0" config
option had been used on the PM, I wouldn't have been able to telnet in
either direction.)

After hosting this POP for a year, the cutomer was finally ready to
connect their network, so I had just moved the Ethernet interface out
of my admin space and was struggling with OSPF ... with the POP down
... and late at night ... not ideal conditions for working out why
bizarre conditions like one-way telnets are occurring.

Eventually I got OSPF working again, but the POP still didn't work. I
didn't know it yet, but changing the Ethernet address had effectively
moved the PM off my network, out of the space allowed access to
RADIUS, and it had changed the PM's RADIUS client identity.

--
Dick St.Peters, stpeters@NetHeaven.com 
Gatekeeper, NetHeaven, Saratoga Springs, NY, 1-800-910-6671 (voice)
Saratoga/Albany/Amsterdam/BlueMountain/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
	  First Internet service based in the 518 area code
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.