PIX with AAA not validating new users from same NAT-domain
We're using a PIX 515R with a Microsoft webserver on HTTP and HTTPS. Users on this webserver have to authenticate with an cryptocard token.
The PIX is validating the user by checking the token on a cryptocard RADIUS server. This system works fine if you're not behind a proxyserver with NAT. If the clienst are behind a proxy/firewall server with NAT we encounter problems with authenticating each client seperate.
Once the first user is authenticated, every other user from behind the proxy server can connect trough the PIX with the webserver without authentication.
The log from the PIX and the configuration of the PIX are included below.
The log from the pix is as follows:
109001: Auth start for user '???' from 220.127.116.11/30120 to 10.2.1.2/80
109011: Authen Session Start: user 'gobo', sid 242
109005: Authentication succeeded for user 'gobo' from 10.2.1.2/80 to 18.104.22.168/30120 on interface outside
302001: Built inbound TCP connection 47097 for faddr 22.214.171.124/30120 gaddr 126.96.36.199/80 laddr 10.2.1.2/80 (gobo)
302001: Built inbound TCP connection 47099 for faddr 188.8.131.52/30257 gaddr 184.108.40.206/80 laddr 10.2.1.2/80 (gobo) This user doesn't have to authenticate because the PIX firewall still thinks it's the first user (gobo)
Then request a webpage with first client (gobo)
302001: Built inbound TCP connection 47100 for faddr 220.127.116.11/30324 gaddr 18.104.22.168/443 laddr 10.2.1.2/443 (gobo)
302001: Built inbound TCP connection 47101 for faddr 22.214.171.124/30326 gaddr 126.96.36.199/443 laddr 10.2.1.2/443 (gobo)
And then the second client again (not authenticated, PIX thinks that this is client "gobo")
302001: Built inbound TCP connection 47102 for faddr 188.8.131.52/30342 gaddr 184.108.40.206/443 laddr 10.2.1.2/443 (gobo)
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...