VPN client access-list problem

antonello.i — Fri, 21 Feb 2020 07:45:35 GMT

Hi,

In my company I've a cisco pix 515 running 6.3(4), i've three interface but

i'm using only two of them.

On the inside network card I've two vlan, one for the inside networks (wks and internal

server) and one for dmz (mail, web... servers). The outside card is a "point to point" with

my border router.

From outside address to another firewall I've configured a normal ipsec tunnel and everything

works fine.

Now I'm introducing a vpn client service with cisco Vpn Client (ver. 4.x).

As radius I've a Windows Internet Authentication Service (IAS) on the internal network that

guarantees access to authenticated users.

After authentication the pix receives from the radius (via Cisco-Av-Pair attribute acl=xxxx) the access-list name to assign to the client users.

Everything seems to work fine: users authentication works -> client cisco receives split-tunnel rules from pix -> pix receives acl name from radius.

THE PROBLEM IS: the access-list I've assigned to the client don't match any packet and the client

can go on everything ip on my inside networks (compatibly with split-tunnel rules) !!!!

I've tried to put a "deny ip any any" on the inside network but it doesn't work, packets pass however...

I've a nat 0 on the inside interface, but the policies are corrects.

Seems like that the pix considers only the split-tunnels rules and not the access-list, also

I've tried to specify a fake access-list in the cisco-av-pair attibute but I've reported

the same results... packets passes

I've a similar configuration on another fw that runs 6.3(1) versions, on this pix everything works!

Any ideas?

Thanks in advance and sorry for my bad english.

Antonello I.

Re: VPN client access-list problem

antonello.i — Sat, 20 Nov 2004 15:23:37 GMT

Hi,

I've resolved... I didn't see this "FEATURE":

ipsec pl-compatible

Enable IPSec packets to bypass the PIX Firewall unit's NAT and ASA features and allows incoming IPSec packets to terminate on the inside interface.

Now it works...

Thanks

Antonello