About gmparis

More to share on this topic... I got this working better than before. I'm not certain what I did to fix it, but those sessions I was getting before were not completing. I think I had an errant interface management policy. In any case, CPM is now updating. Three things of note: First, CPM is only providing address change information, at least that's what I think is happening. Since a large proportion of the RADIUS registrations end up with the same address over and over, I think CPM remains silent about these. If so, it avoids a lot of chatter, but seems like it might be a long while before a complete database is built. Not sure about any of this. Second -- and I am sure about this -- the CPM integration does not work at all in a system with multi-vsys enabled. This is because the xpath (which I see no way to modify in the ClearPass GUI) does not contain /vsys/entry@name='vsys1'. The result is nothing gets added to the ip-user-mapping table, since there is effectively a different table for each vsys. Third, the AirHeads discussion forum has a note that says CPM 6.3 will have the ability to pass the domain along with the login. Right now, what I'm getting -- login only -- is all there is. ... View more

I see you asked your question a while back. Maybe you already got it working. If so, please share. Otherwise, I have a little bit to share since I have gotten this partially working. Well, maybe only the tiniest bit working. First thing is that the ClearPass server connects from its RADIUS IP rather from the Management IP. This is hard to figure out without a sniffer, if you have the https requests go to the Management port on the Palo Alto, which is what I first tried. However, since most of our PAs are HA pairs, that would mean two management IP entries for each. Plus, no firewall logging to help debug the thing. So I made the trust interface an https management port, updated the ACL, then added a Security Policy to allow the RADIUS servers to talk ssl to the interface IP. This seems to have worked. Sort of. I see the connections, but they come up as "incomplete" rather than "ssl" as I would expect. They're short too. 6 packets and 636 bytes each. I used a browser to connect and it worked fine, so it seems functional. Also, I see only a a few IP entries added to the ip-user-mapping table. I should see hundreds. Here's what I think is the useful command: "show user ip-user-mapping all | match XMLAPI". Another thing, which may or may not be an issue, is that for those few entries I do get, I see only the user name and not the domain. That's in contrast to what I see in the table from the User-ID Agent. The documentation on this is shy of useful detail, especially on the Palo Alto config side. I'll keep poking at it, but I'm hoping a little activity here will draw out somebody who has this working. ... View more

I'm wondering why you used the manage-ip for the path monitoring instead of the NSRP IP. I have similar configurations here, both NSRP and VRRP, and my concern is that the shared address -- which is what the traffic cares about -- can be unreachable, even though the manage/local IP is reachable. This comes about because we generally have two layer-2 devices involved. This may not be your configuration, but still, I wonder if you are accomplishing what you want with this configuration. Of course, I'm chiming in on this only because I'm getting all the updates to this thread. 🙂 ... View more

No problem about the hijacking, @vwaghmar. Thanks for answering my question. I was trying to test the path monitoring using ping before configuring it into HA. That apparently can't be made to work, but isn't necessary. Just putting the source address into the vwire path monitoring config is all that's needed. I was making it harder than it had to be. Good luck with your layer-3 issue. ... View more