By the VPN channel between two ASG 110 both with ASL 7.011 there occure some problems. The connection is unstable and falls down and are not reconnected again.
The system behaves not predictably, sometimes it works but sometimes not and there is the problem to figure out, what can be down to reactivate it again. Sometimes there helps to inactivate and activate the connection, sometimes helps if the logging of some inforamtion is turned on, if it is turned off, then the connection is lost again. But this is also not every time. I think the reason is the ipsec subsystem is restarted by the change of some settings what causes the connections start working for some time.
In the log, there can be found following messages:
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: ignoring Vendor ID payload [strongSwan 2.7.3]
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: ignoring Vendor ID payload [XAUTH]
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: received Vendor ID payload [Dead Peer Detection]
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: received Vendor ID payload [RFC 3947]
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2007:11:03-16:16:25 (none) pluto[21722]: packet from 1.2.3.4:4500: initial Main Mode message received on 192.168.0.178:4500 but no connection has been authorized with policy=RSASIG
2007:11:03-16:16:46 (none) pluto[21722]: packet from 1.2.3.6:4500: Informational Exchange is for an unknown (expired?) SA
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: ignoring Vendor ID payload [strongSwan 2.7.3]
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: ignoring Vendor ID payload [XAUTH]
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: received Vendor ID payload [Dead Peer Detection]
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: received Vendor ID payload [RFC 3947]
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2007:11:03-16:16:55 (none) pluto[21722]: packet from 1.2.3.5:4500: initial Main Mode message received on 192.168.0.178:4500 but no connection has been authorized with policy=RSASIG
...
2007:11:03-16:24:01 (none) pluto[21722]: packet from 1.2.3.6:500: ignoring Vendor ID payload [4f455b7075417d5959587e46]
2007:11:03-16:24:01 (none) pluto[21722]: packet from 1.2.3.6:500: received Vendor ID payload [Dead Peer Detection]
2007:11:03-16:24:01 (none) pluto[21722]: packet from 1.2.3.6:500: received Vendor ID payload [RFC 3947]
2007:11:03-16:24:02 (none) pluto[21722]: packet from 1.2.3.6:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2007:11:03-16:24:02 (none) pluto[21722]: packet from 1.2.3.6:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2007:11:03-16:24:02 (none) pluto[21722]: packet from 1.2.3.6:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2007:11:03-16:24:02 (none) pluto[21722]: packet from 1.2.3.6:500: initial Main Mode message received on 192.168.0.178:500 but no connection has been authorized with policy=RSASIG
Because there were the messages the authorization over RSA did not happended, I verified all keys. It did not help. I regenerated all the keys. Also did not helpsed. I tried to change the "bittness" of the keyz - from 2048 to 4096 - and regenerated the keys - also unsuccessfull... Or if successfull, then only for some short time and then the connection has fallen again.
For example, if I also changed the remote gateway definition and saved it, it started to work, but in the case I have turned the logging off the connection has been broken again. Pure nightmare :-(. Somtimes it helps if the logging is turned on, sometimes not... I thought the problem could be i the different policy, so I defined the same policy on all gateways, but it did not help (changing of the policy helped only for some time).
Situation on the machine from which is the log is following:
1. it is ASG 110 with ASL 7.011
2. there are defined following channels on this machine:
a. channel to 1.2.3.4 – this machine is also ASG 110 with ASL 7.011 and on this connection there are the problems, becomes brobken and is not restored again.
b. channel to 1.2.3.5 – this machine is also ASG 110 with ASL 7.011 and on this connection there are the problems, becomes brobken and is not restored again.
c. channel to 1.2.3.6 – this machine is ASG 220 with ASL 6.310 and the connections to this machine work always without problems - even if there are similar messages in the log file, the connection keeps working and if turned of and on, is restored without problems after the reactivation in a short time
Does somebody know what could be the cause of the problems with RSA authetification? From which reason the ASG with ASL 6.x communicates over the port 500 and the ASG with ASL 7.x over 4500?
The firewall is behind the ADSL router and itself does not have the public IT, all traffic is routed to the DSL router, all traffic coming to DSL router is routed to astaro's external IP address 192.168.0.178. Situation by the astaro on the opposite side of the channel 2a is similar, channels 2b and 2c have directly the public IP addresses.
Any helps or ideas would be appreciated...
with regards, Archie
This thread was automatically locked due to age.
