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

Jeff Kell jeff-kell at utc.edu
Wed Sep 7 23:38:57 EDT 2005


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 :-)

Thanks,

Jeff Kell
ITD Security


More information about the cisco-nsp mailing list