[c-nsp] Help settling an argument :-)

Bruce Pinsky bep at whack.org
Thu Sep 8 01:26:19 EDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Kell wrote:
> I've gone around in circles for a week with our Novell administrator on
> this one.  I'm fairly certain I'm right but I can't find a good
> black-and-white reference to point him to that proves it (or point me to
> so I can quitely surrender).  So here is the issue...
> 
> We have an IChains server (Novell proxy/auth/SSL thing) that has one
> interface on the DMZ that users access directly, and another interface
> on an internal network that has the back-end services it is protecting.
> Fairly straightforward so far.
> 
> The switch handling the subnets is a 4500, which is relevant because it
> doesn't support uRPF (at least not on our IOS image).  To compensate, I
> have ingress filters that perform the same function, since these are
> "leaf" subnets with no other routers, it checks to be sure the source IP
> is indeed on the subnet in question.  Exceptions are logged (I want to
> see any spoofing).  That filtering is a shop standard.
> 
> Now the interesting part.  The Novell server triggers the ingress
> filters for certain traffic, trying to send DMZ interface IP sourced
> packets out the private network interface, and vice versa.
> 
> The Novell box must be doing routing or IP forwarding, no?  I don't want
> them routing [for obvious purposes].  He says he isn't.  I say he is.
> There you go.
> 
> A consistent example of the problem, we have a simple network monitor
> that pings each interface periodically to see if it is up.  When it
> pings the DMZ interface, the Novell box answers on the private interface
> (with a source IP of the DMZ interface).  If you're not routing, aren't
> you always supposed to answer on the same interface the traffic came
> from?
> 
> Bonus points if anyone knows the Novell knob to turn this off :-)
> 

Assuming that the monitoring system has an address on the "inside"
interface, it sounds like the Novell server is sourcing its response with
an IP address that is on the interface that is the route to the monitoring
system.  That would not be uncommon and is the default behavior for IOS
devices if their source interface address is not specified for a specific
service (i.e. snmp source-interface command, etc).

Can the Novell sysadmin provide you the output of their routing table?  It
could shed some light on the issue.  Also, if the Novell server has some
host IP debugging, it would interesting to see the output from that.

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFDH8t7E1XcgMgrtyYRAnddAKDCq22X6HGcepT1M9I6cLe1C858CQCg1LBW
27voS1nUnIBEa2rfUaWXehM=
=9xJX
-----END PGP SIGNATURE-----


More information about the cisco-nsp mailing list