Pix Syslog VPN Logging; Is there any way to determine which real addresses correlate with those from address-pool?

When an IPSec tunnel is created between a vpn client and my PIX, I need to know both the clien'ts public IP address and the address assigned to the client from the vpngroup address-pool. Specifically, I need to be able to easily tell from a perl script running on an OpenBSD system. I have the debugging syslog messages sent to the box now and my script checks the log file for updates every second. The only messages that I am seeing right now when I successfully connect are:

Apr 21 01:16:07 pixinside %PIX-6-602301: sa created, (sa) sa_dest= a.b.c.98, sa_prot= 50, sa_spi= 0x4f15da88(1326832264), sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 2
Apr 21 01:16:07 pixinside %PIX-6-602301: sa created, (sa) sa_dest= a.b.c.99, sa_prot= 50, sa_spi= 0x23106dc6(588279238), sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 1

Show logging:
Syslog logging: enabled
    Facility: 20
    Timestamp logging: disabled
    Standby logging: disabled
    Console logging: disabled
    Monitor logging: level emergencies, 0 messages logged
    Buffer logging: level debugging, 187 messages logged
    Trap logging: level debugging, 54726 messages logged
        Logging to inside escort
    History logging: disabled
    Device ID: disabled

Relevent Config:
ip local pool untrustedvpnusers a.b.c.206-a.b.c.210
vpngroup default address-pool untrustedvpnusers

show ip local pool
Pool            Begin           End              Free    In use
untrustedvpnusers               a.b.c.206   a.b.c.210       5         1

Available Addresses:

In Use Addresses:

The sho crypto sa command outputs the information I need, but I am not going to have my script login to the pix and run this command everytime it sees "%PIX-6-602301: sa created" in the syslog (not to mention the output of this command is far from regular expression friendly).

sho crypto sa | include current.peer|dynamic.allocated.peer.ip|spi
    current_peer: a.b.c.98:500
   dynamic allocated peer ip: a.b.c.206
     current outbound spi: 23106dc6
      spi: 0x4f15da88(1326832264)
      spi: 0x23106dc6(588279238)

I'm sure there is a fairly simple solution to this, so thanks in advance to the person that gets it.
Who is Participating?
Tim HolmanConnect With a Mentor Commented:
PS - grblades has documented this here - http://www.gbnetwork.co.uk/networking/ciscopixvpnradius.html
Tim HolmanConnect With a Mentor Commented:
You could create a VPN group for each VPN user, and assign a single IP address to each VPN group.  That way users would be tied to IP addresses, which may make things easier ?
sysop0Author Commented:
I'm not sure that helps. The sa created syslog message does not inform me for which vpngroup the sa was just created. I would still have no way of knowing from syslog the dynamic allocated peer address.
Not to mention it is too expensive from a management and maintainence point of view. Plus, I already have other vpngroups with other access-pools. The vpngroup "default" is a special vpngroup that is used anytime there is no exact match for the user specified group a feature I need for other reasons.
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

sysop0Author Commented:
The plot gets thicker...

I just threw together a quick and dirty MS IAS server to handle radius authentication for the PIX hoping that I could use NTsyslog to get the event messages from the IAS box to the syslog server. Done, but look at the useless new messages I have now:

Apr 21 16:16:48 pixinside %PIX-6-109005: Authentication succeeded for user 'Administrator' from a.b.o.99/0 to a.b.o.98/0 on interface outside
Apr 21 16:16:48 pixinside %PIX-6-602301: sa created, (sa) sa_dest= a.b.o.98, sa_prot= 50, sa_spi= 0x3ef0cd50(1055968592), sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 2
Apr 21 16:16:48 pixinside %PIX-6-602301: sa created, (sa) sa_dest= a.b.o.99, sa_prot= 50, sa_spi= 0x919d9f72(2443026290), sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 1
Apr 21 16:16:48 pixinside %PIX-2-109011: Authen Session Start: user 'Administrator', sid 5
Apr 21 15:55:44 a.b.i.69 ias[info] 1  User 4ESSB12 was granted access.  Fully-Qualified-User-Name = AUTH\\4ESSB12  NAS-IP-Address = a.b.i.1  NAS-Identifier = %%2147483686  Client-Friendly-Name = PIX  Client-IP-Address = a.b.i.1  Calling-Station-Identifier = a.b.o.99  NAS-Port-Type = %%2147483686  NAS-Port = 3  Proxy-Policy-Name = Use Windows authentication for all users  Authentication-Provider = %%2147483688  Authentication-Server = %%2147483685  Policy-Name = Connections to other access servers  Authentication-Type = PAP  EAP-Type = %%2147483685

If I didn't have the default vpngroup requirement, I could at this point take Time Holman's advice and create micro pools and vpngroups on a 1 to 1 user basis. As long as I keep the vngroup's name the same as the username in the radius database administration wouldn't be too difficult. Still, it requires that I now have two different sets of credentials for users attempting to make IPSec connections; first the vpngroup with it's secret and then second the radius user/pass. I hate making users remember multiple passwords just as much as I hate having users save passwords in laptops. I could setup certificate services on the server currently running IAS and use rsa-sig instead of pre-share for the isakmp policy authentication but then I'm drastically increasing deployment and administrative costs by depending on a PKI just so I can reduce, 2 passwords to 1? Still not good enough.

In a scenario where you notice an IP address that belongs to the address-pool of the default vpngroup, violating acceptable network usage policy, how does Cisco expect for you to determine with near 100% confidence which IPSec peer has the offending dynamically allocated IP address (without using sho crypto sa interactively)?

There must be a simple way to do this, which expert knows the answer?

***Also, please note that in the first post I had a typo... in the show crypto output the line current_peer: a.b.c.98:500 was acutally current_peer: a.b.c.99:500
Have you tried using the PDM GUI, monitoring tab, VPN tunnels? It should show you right there remote/local ip for each connected tunnel..
sysop0Author Commented:
I haven't used the PDM GUI, but that doesn't sound different than running the 'sho crypto sa' console command. I need a perl script to be able to read this from a 'file'. Does the PDM GUI provide extra logging? How would an incident handler perform post-mortem analysis?
try adding
logging message  6113 level debug
I am fairly sure the vpn client info will fall into the syslog 6113xx range
sysop0Author Commented:
Let's review: "When an IPSec tunnel is created between a vpn client and my PIX, I need to know both the clien'ts public IP address and the address assigned to the client from the vpngroup address-pool."

You are correct that messages 611301 - 611311 return information about the PIX's vpnclient. However, I am not using the PIX's vpnclient. I don't care about the connecting client's logs. I don't trust the connecting client.

I want a log message generated by my PIX that says, "The new SA_spi xxxxxx was created for vpngroup xxxxx and I just assigned it IP address x.y.z.n from ip local pool xxxxx, have a nice day."

I am using the vpngroup command to give access to client's using the 3.x version of Cisco's vpn client on Windows/Mac OS/*nix. Right now I can tell that *someone* succesfully connected because there is a new SA. The PIX kindly includes the *public* IP address of the client associated with the SA. When I setup xauth, I get to see the username they entered but still not the IP address on my network that eventually gets pushed to the client. As stated earlier, if the vpngroup address pools contain 1 IP address each (a bad idea for two reasons and a configuration not supported by Cisco) and the vpngroup groupname matches the username in the radius database, I could infer the internal IP address as long as radius was enabled.

But as I stated, that is not supported by Cisco, they ask that you use a min. of 3. It also messes up users that get disconnected by temporary network failures because when they try to reconnect, the previous session hasn't expired and thus the one IP address available is still in use. Finally, it makes for a brittle system. If changes in the PIX don't get manually replicated in my script's database, then game over. Would it be that hard to add syslog messages for the address pools? Does know one else care what addresses are being handed out for their network?

I really don't get how I am supposed to know who is causing all of the alarms on my IDS when the IP's that are being assigned can't be easily and directly linked back to the user or system that it was originally assigned to. Anyway, thanks for the help, but I am pretty sure that it is impossible.
Tim HolmanCommented:
If you setup a debug all on the PIX, and fire up a VPN Client in this scenario, do you see the information you require ?
Basically, if it's not in the debugs, it will never appear in any of the command subsets that the PIX uses.

Have you thought about using RADIUS ?

I'm pretty sure you can tell RADIUS which IP address a particular user will get ?

WINS would also tell you, assuming the user has logged on to your domain.

sysop0Author Commented:
The debug all doesn't show the magic. 'Sho crypto sa' reveals the information but the SA messages in the syslog and debug output are generated prior to the address getting pushed to the client. If,instead of using a radius server for xauth I were to require some particular traffic type to be radius authenticated first, then yes I would be able to get the assigned internal IP address and associated user is a log message. The problem with that approach is an addittional set of access credentials for users to remember and much longer connection times than when using xauth after IKE as is standard. The latter is non-trivial, some programs will timeout, etc.

DNS nor WINS are options right now because those services are not other wise needed or indeed, even accessible by the VPN users.

Still, your post-connection radius solution is the best option so far because though it requires two login IDs, it would remove the need for a user/IP database being maintained within my script that matches the PIX configuration. How would you configure it to ensure the smallest preformance impact without compromising security?
Tim HolmanCommented:
You wouldn't need 2 login IDs - you could redirect all authentication from the PIX to the RADIUS, so user IDs and passwords would be kept on this instead.
sysop0Author Commented:
From the link you posted:
vpngroup groupstaff password grouppassword
vpngroup groupother password grouppassword

If you were recommending that I stop using an individual vpngroup for each user and not count this as an authentication mechanism, that will not work. Because some of the users are on laptops, and this password is often saved in their VPN Client, the cost of a single lost laptop would require manual updates to everyone's VPN client that had the password saved. For everyone else, they would have to remember a new password. If these were internal machines that we had aministrativer control over, it might not be that bad. Unfortunately, we own less than an eighth of them. Our model is to give access to users not computers. So really, we might not even know when the vpngroup user and password are lost if the user never reports to us that their computer is stolen.

I also like giving individual vpngroups small IP pools and then creating user specific access controls linked to tightly defined NAT exception lists.

I think this is as close as we'll get. I will give Tim half for the answer first answer, one to one, I learned a lot of useful tricks from that but remember you have to waste three IPs per user. I will give Tim the other half the points for the link to the article that shows a FreeRADIUS configuration that is compatible with PIX because a lot of people don't want to use Microsoft IAS and there aren't a lot of PIX-RADIUS configuration exampels out there that cover non-MS/Cisco Radius solutions. Thanks.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.