Is there a way that you can force the PIX to authenticate the user(s) who uses the site-to-site VPN? I have no problem with the VPN setup but I want to control who goes through the tunnel by using the PIX local database. With VPN client I can configure the PIX to use per user authentication in addition to the group authentication and i want to do the same with site-to-site VPN.
I am thinking of the vitual HTTP but I don't know how which one goes first, the tunnel creation or the Virtual http authentication.
Group Setup. No basic configuration is required. For the purposes of this sample configuration, a CiscoSecure ACS group that is unused or that only has default settings associated with it is recommended.
User Setup. This guide assumes that basic user profiles have been created or that the Unknown User Policy, configurable in the External User Database section, has been configured to enable the creation of user profiles automatically upon the first successful authentication of each user by an external user database. If user profiles are manually created, this guide assumes only the following for each user profile: The username is specified. The Authenticate Using list in the user profile has been configured to specify the user database that will authenticate the user. If the CiscoSecure user database is to authenticate the user, the user's password has been specified.
i guess it will work providing the command "sysopt connection permit-ipsec" is disabled.
with this command disabled, all crypto traffic will be checked against the inbound acl. thus the pix will firstly decrypts the packet, check the inbound acl, it shoud be able to do "aaa authentication" for virtual http.
I have configured this on serval client installations. Create an access-list that defines the (private) source and destination networks that you want to authenticate and/or authorize for. Use the following command:
aaa authentication match ctap-list-name outside
After your ipsec packets are decapsulated, the source and destination are evaluated against any access-groups on the outside interface before being permitted access to the network. The purpose of the sysopt connection permit-ipsec command is to bypass this check. Otherwise you have to explicitly permit private traffic arriving on the outside interface. This always scares me, but if you carefully compare the crypto access-lists with the inbound access-groups you will see that the security risk is minimal. Fortunately, the sysopt connection permit-ipsec command only bypasses access restricted by access-groups. It does not bypass aaa inspection. Therefore, your aaa authentication match command can be successfully applied even when ipsec traffic is assumed trusted by the firewall.
An interesting twist on this is to use csacs radius server to distribute downloadable ip acls. This way you can configure a general VPN tunnel and use the aaa authorization to enforce a specific network security policy by user or group.
Another interesting trick is that you can use the same downloadable ip acl from the aaa server for your VPN clients. You can then have a single user configuration on the aaa that controls their access to network segments differently depending on their source address which is different between their native vlan and when accessing through the vpn client.
This should work with local aaa as well, but I have never tested this.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...