Hello. I have been trying to use a few Draytek 2910s as as endpoints for IPSec VPN tunnels, making a connection to a server running Linux/OpenSwan on a central location.

The Drayteks must be behind small ADSL routers with dynamic public IPs (no other offer from ISPs at those locations). They do work, and maintain stable connections - so long as the public IP address of the ADSL router does not change. When that happens the tunnel is torn down (naturally) but all further attempts to reestabelish the IPSec connection fail.

I am aware that this is a problem (or a security feature?) with OpenSwan, as in similar VPNs between systems with OpenSwan I must restart the IPSec service in both systems when the router's IP address changes. As the change can be detected and the restart scripted, the problem is not serious.
Unfortunately it is also a problem with the Draytek 2910s. Even after I restart IPSec on the linux server, the connections from the Drayteks still fail, and continue to fail until the Drayteks are rebooted. Which requires manual intervention, rendering the Drayteks useless in location without personnel, and inconvenient otherwise.

Is there any workaround for this? Note that I cannot use a Draytek 2910 as the endpoint on the central location with the linux server because that Draytek model does not seem to handle the high arp traffic on the network very well (in testing it seemed to me that the arp table on the 2910 overflows and deletes the local gateway's ethernet address, causing all VPNs to drop once a minute).

Below some example logs from openswan on the linux server (the IP addresses and some other data are redacted).

Negotiation of a successful connection:
Sep 6 00:18:21 sismo01 pluto[19823]: packet from [GATEWAY_PUBLIC_IP]:4500: received Vendor ID payload [Dead Peer Detection]
Sep 6 00:18:21 sismo01 pluto[19823]: packet from [GATEWAY_PUBLIC_IP]:4500: received Vendor ID payload [RFC 3947] method set to=110
Sep 6 00:18:21 sismo01 pluto[19823]: packet from [GATEWAY_PUBLIC_IP]:4500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Sep 6 00:18:21 sismo01 pluto[19823]: packet from [GATEWAY_PUBLIC_IP]:4500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Sep 6 00:18:21 sismo01 pluto[19823]: packet from [GATEWAY_PUBLIC_IP]:4500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Sep 6 00:18:21 sismo01 pluto[19823]: packet from [GATEWAY_PUBLIC_IP]:4500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Sep 6 00:18:21 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: responding to Main Mode from unknown peer [GATEWAY_PUBLIC_IP]
Sep 6 00:18:21 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Sep 6 00:18:21 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: STATE_MAIN_R1: sent MR1, expecting MI2
Sep 6 00:18:22 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed
Sep 6 00:18:22 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Sep 6 00:18:22 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: STATE_MAIN_R2: sent MR2, expecting MI3
Sep 6 00:18:23 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: Main mode peer ID is ID_DER_ASN1_DN: '[CERTIFICATE_DETAILS]'
Sep 6 00:18:23 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: I am sending my cert
Sep 6 00:18:23 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Sep 6 00:18:23 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2089: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}

Successful renewal:
Sep 6 22:46:30 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2086: responding to Quick Mode {msgid:5b616f8b}
Sep 6 22:46:30 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2086: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Sep 6 22:46:30 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2086: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Sep 6 22:46:30 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2086: Dead Peer Detection (RFC 3706): enabled
Sep 6 22:46:30 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2086: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Sep 6 22:46:30 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2086: STATE_QUICK_R2: IPsec SA established {ESP=>0xfdb11a18 <0x3cbc7ff1 xfrm=3DES_0-HMAC_SHA1 NATD=[GATEWAY_PUBLIC_IP]:4500 DPD=enabled}
Sep 6 22:59:52 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2079: received Delete SA(0xfdb11a17) payload: deleting IPSEC State #2085
Sep 6 22:59:52 sismo01 pluto[19823]: "coimbra"[10] [GATEWAY_PUBLIC_IP] #2079: received and ignored informational message

Failed connections after the ADSL router's IP address changes (repeated every 8s):
Oct 23 11:02:49 sismo01 pluto[6635]: packet from [GATEWAY_NEW_PUBLIC_IP]:500: received Vendor ID payload [Dead Peer Detection]
Oct 23 11:02:49 sismo01 pluto[6635]: packet from [GATEWAY_NEW_PUBLIC_IP]:500: received Vendor ID payload [RFC 3947] method set to=110
Oct 23 11:02:49 sismo01 pluto[6635]: packet from [GATEWAY_NEW_PUBLIC_IP]:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Oct 23 11:02:49 sismo01 pluto[6635]: packet from [GATEWAY_NEW_PUBLIC_IP]:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Oct 23 11:02:49 sismo01 pluto[6635]: packet from [GATEWAY_NEW_PUBLIC_IP]:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Oct 23 11:02:49 sismo01 pluto[6635]: packet from [GATEWAY_NEW_PUBLIC_IP]:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Oct 23 11:02:49 sismo01 pluto[6635]: "coimbra"[53] [GATEWAY_NEW_PUBLIC_IP] #7087: responding to Main Mode from unknown peer [GATEWAY_NEW_PUBLIC_IP]
Oct 23 11:02:49 sismo01 pluto[6635]: "coimbra"[53] [GATEWAY_NEW_PUBLIC_IP] #7087: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Oct 23 11:02:49 sismo01 pluto[6635]: "coimbra"[53] [GATEWAY_NEW_PUBLIC_IP] #7087: STATE_MAIN_R1: sent MR1, expecting MI2
Oct 23 11:02:55 sismo01 pluto[6635]: "coimbra"[53] [GATEWAY_NEW_PUBLIC_IP] #7079: max number of retransmissions (2) reached STATE_MAIN_R1

I run a tunnel between Openswan and a 2600G. The 2600 is on a pretty dynamic IP and mine (Openswan) is pretty static. My Openswan is on my gateway machine, but yours, with the multiple references to port 4500, looks NAT'd, so I don't know if my solution applies.

My ipsec.secrets is very simple here with all remote sites using the same PSK. It is:

Code:

: PSK "this is my shared secret"

I do not use any IP or FQDN in it.

In ipsec.conf, have these two lines in each conn section for the Drayteks:

Code:

right=%any # this could go in the %default conn if you wanted rightid=@IdentifyingText

The IdentifyingText should be different for each conn.

In the Drayteks go into the Advanced section of the LAN-LAN Dial Out Settings and set the Local ID to the IdentifyingText you have defined in your conn.

With this setup, in Openswan you never need to define a right IP or FQDN and it should accept a connection from anywhere with the correct PSK and rightid.

Are your remote modems in bridge mode i.e. does the Draytek have a public WAN IP?

Thanks for the answer. I cannot use the ADSL modem in bridged mode, unfortunately, so the Draytek must have a private IP address and IPSec uses NAT-T.

I'm also using certificates. From reading the manual I got the impression that if I used a PSK with "clients" which had dynamic IP addresses, I would be forced to place them all under a single connection (the right=%any line would only be allowed on one connection, when using shared keys). I need to keep several different LAN-to-LAN tunnels. My conn sections in ipsec.conf look like:

conn example
authby=rsasig
type=tunnel
rekey=no
auto=add
pfs=no
ike=3des-sha1
esp=3des-sha1
ikelifetime=240m
keylife=60m
aggrmode=no
dpddelay=30
dpdtimeout=120
dpdaction=clear
left=%defaultroute
leftsubnet=10.10.10.0/24
leftsourceip=10.10.10.2
leftcert=server.pem
right=%any
rightcert=remote.pem
rightsubnet=10.10.11.0/24

I have not been able to play with certificates as they do not exist on 2900's or 2600's.

From what I understand you can have many different conns with a single PSK and right=%any. Differentiate them with a rightid=@xxxxxx. Having said that, certificates are supposed to be better (more secure and easier to identify the different conns) if you can get them to work.

I've only just started trying DPD. Are you sure you want dpdaction=clear? In later versions of Openswan there are two more actions - reset and reset_by_peer. You could try them.

A few comments on your conn (but not relevant to your problem):
Do you use a %default conn? If so you can move your left stuff into it, and possibly a few more lines
You have limited your conn to 3DES. My 2900 works with AES128 (it appeared to connect with AES256 but yould not pass traffic. I may try it again sometime). If you are limiting it to 3DES you can do it from the Draytek end only.
Any reason you have pfs=no? It is better to allow it.

Thinking about it a bit more overnight, where my 2600 dials me, I do not use DPD (the 2600 does not support it). Just in case, I also have a script running on the Openswan box to reset the tunnel if it drops, but it does not normally trigger.

If you do try a PSK and rightid=@xxxxxxx, you will often see the conn mis-identified in the logs during the first part of the keying negotiation. It only gets identified correctly when the rightid is received from the 2910.

With pfs, if set to no in Openswan and yes on the Draytek, Openswan will ignore the no and use pfs anyway!

Can you telnet into your 2910 from the WAN? If you can, you could run a remote script to reboot it when you need to.

NJH wrote: I have not been able to play with certificates as they do not exist on 2900's or 2600's.

I can at least say that the certificates on the 2910 do work. I did had to convert the format. Openssl uses PEM by default, the drayteks require DER.

NJH wrote: From what I understand you can have many different conns with a single PSK and right=%any. Differentiate them with a rightid=@xxxxxx. Having said that, certificates are supposed to be better (more secure and easier to identify the different conns) if you can get them to work.

I've only just started trying DPD. Are you sure you want dpdaction=clear? In later versions of Openswan there are two more actions - reset and reset_by_peer. You could try them.

Thanks. In the 2.4 version I'm using the man page only shows "hold", "clear", and "restart" as options, and I've only tried those. I'll keep in mind your suggestion and try a newer version soon.

NJH wrote: A few comments on your conn (but not relevant to your problem):
Do you use a %default conn? If so you can move your left stuff into it, and possibly a few more lines

Yes, I'll probably may move all the common lines there, once I finish with experimenting. Now I only have leftrsasigkey=%cert and rightrsasigkey=%cert in %default.

NJH wrote: You have limited your conn to 3DES. My 2900 works with AES128 (it appeared to connect with AES256 but yould not pass traffic. I may try it again sometime). If you are limiting it to 3DES you can do it from the Draytek end only.
Any reason you have pfs=no? It is better to allow it.

3DES is still more common, and good enough for my purpose. I simply picked one which was clearly available on both ends and worked.
I'm almost sure I tried pfs=yes and had trouble getting a connection with that. Unfortunately I deleted those comments and don't have a Draytek at hand now to try it.
Once I get one back I'll try the PSKs with rightid. I cannot reach any with the VPNs down.

By the way, and this is only about Openswan, have you had pluto crash whenever aggrmode=yes? I noticed that with both 2.4 and 2.6.