RSA(ACE) Primary/Replica server failover with VPN3015

[dfariborz]

We have configured a primary and a replica RSA server and these 2 servers communicate ok with each other.

We get also autheticated against the primary RSA server with no problem thru VPN3015..

However, when the primary RSA server is made to fail the first time that we try to authenticate which should be against the replica server fails but the 2nd attemp passes. The same scenario happens when the primary is brought up.

Is the problem due to VPN box can support only one RSA server with v5?

The RSA server is v5.2 and VPN3015 is v4.0.

[umedryk]

As far as my knowledge goes, there is no problem with the versions that you use. You could try to increase the timeout timer.

[prossouw]

Try to reduce the Retries to 1, on the configuration option for Athentication Server. Below is an extract from the Help facility that explain the Retries option.

Retries.

Enter the number of times to retry sending a query to the server after the timeout period. If there is still no response after this number of retries, the VPN Concentrator declares this server inoperative and uses the next SDI authentication server in the list. The minimum number of retries is 0. The default number of retries is 2. The maximum number is 10.

[aklausner]

Hello,

I'm facing a similar issue, did you get an answer for your problem ?

thanks

Alain,

[dfariborz]

When I tested it in the Lab over LAN, I had that problem. But we went to production knowing this potential problem. However, it worked in production as the users were coming from the internet. I guess 100Mbps FDX in a LAN environment was too fast for the boxes.

[aklausner]

Hi,

I re-read your first post, I think I misunderstood it slightly, actually my problem is that some users need to authenticate to the slave rsa ( this works ok ), I tested the situation when that slave fails, so they indeed authenticate against the primary rsa, but when I re-establish the slave server, the users keep on authenticating against the primary, as if the concentrator kept on preferring that server ... so I think this is a little bit different from your issue.....