Re: [strongSwan] /etc/strongswan.d/VPN.conf:1: syntax error, unexpected NAME, expecting NEWLINE or '{' or '=' [vpn]
Hi Stephen,
So I assume there is no longer any syntax error reported.
From logfile I see there is no acceptable traffic selector. I assume that
you have a home PC (Ubuntu) with Strongswan which you want to connect to
the office VPN concentrator with IP 17.11.7.5 running Windows. I suppose
VPN concentrator in the office is not configured to route any traffic
towards you home PC's IP address, thus you will need a virtual IP address
assigned to your home PC by the VPN concentrator. Also I suppose you want
to route all traffic via that VPN once connected.
Then, please try to modify left=%defaultroute to left=%any and add
rightsubnet=0.0.0.0/0 and leftsourceip=%config. You should not specify
leftsubnet, it has same effect as leftsubnet=%dynamic.
According to documentation at wiki
https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
configuration
directive left=defaultroute% was used prior to version 5.0.0, superseded
by left=%any.
leftsubnet=%dynamic (or omitting leftsubnet at all) and
rightsubnet=0.0.0.0/0 will create your traffic selector. It says that
anything (0.0.0.0/0) from your side will be routed to remote host and that
the remote host will route towards your PC (left==local) a traffic which
would fit your dynamically assigned IP. Should you want to route towards
office network only office-related traffic then change
rightsubnet=subnet_used_in_Stephen's_office.
If that didn't help please can you provide output of 'ipsec statusall' and
also more details about network topology?
Regards,
Miroslav
On Saturday, April 18, 2015 at 5:28:12 PM UTC+2, Stephen Feyrer wrote:
Hi Miroslav,
Thank you. The conn section as presented below was copied and pasted from
web page for convenience (this stripped the leading white spaced from the
conn section). For the moment the white spaces are in form of TAB
characters. I will test with space characters and complete this email.
I Apologise for the lack of white spaces in the conn section of below
email. I have now tested with both spaces and tabs, each producing the
same error as below.
--
Kind regards
Stephen Feyrer.
On Sat, 18 Apr 2015 13:25:20 +0100, Miroslav Svoboda good...@goodmirek.cz
javascript: wrote:
Hi Stephen,
I believe the issue might be caused as the conn section is not compliant
with prescribed format. There should be at least one whitespace at the
beginning of each line within the section. Only sections can and shall
start at the first character of the line.
Supposed correction:
*conn VPN-OFFICE-COM*
* keyexchange=ikev1*
*type=transport*
*authby=secret*
*ike=3des-sha1-modp1024*
*rekey=no*
*left=%defaultroute*
*leftprotoport=udp/l2tp*
*right=vpn.office.com http://vpn.office.com*
*rightprotoport=udp/l2tp*
*rightid=17.11.7.5*
*auto=add*
Regards,
Miroslav
Message: 3
Date: Fri, 17 Apr 2015 14:08:57 +0100
From: Stephen Feyrer stephen...@btinternet.com javascript:
To: us...@lists.strongswan.org javascript:
Subject: Re: [strongSwan] /etc/strongswan.d/VPN.conf:1: syntax error,
unexpected NAME, expecting NEWLINE or '{' or '=' [vpn]
Message-ID: op.xw8ms...@sveta.home.org javascript:
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Hi Neol,
Thank you. I have removed the file /etc/strongswan.d/VPN.conf
In /etc/ipsec.conf I have the same configuration. At least there is
progress, unfortunately I am still baffled. This is the previously
working configuration.
code:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn VPN-OFFICE-COM
keyexchange=ikev1
type=transport
authby=secret
ike=3des-sha1-modp1024
rekey=no
left=%defaultroute
leftprotoport=udp/l2tp
right=vpn.office.com
rightprotoport=udp/l2tp
rightid=17.11.7.5
auto=add
Having restarted ipsec, I get the following result
code:
# ipsec up VPN-OFFICE-COM
initiating Main Mode IKE_SA VPN-OFFICE-COM[1] to 17.11.7.5
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (212 bytes)
received packet: from 17.11.7.5[500] to 1.2.3.4[500] (116 bytes)
parsed ID_PROT response 0 [ SA V V ]
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (244 bytes)
received packet: from 17.11.7.5[500] to 1.2.3.4[500] (304 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: [Available On Request]
received unknown vendor ID: [Available On Request]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 1.2.3.4[4500] to 17.11.7.5[4500] (84 bytes)
received packet: from 17.11.7.5[4500] to 1.2.3.4[4500] (84
Re: [strongSwan] Incorrect Phase II for Cisco IOS Transport VPN
Hi John,
I think it is not possible to use transport mode with local (left) address
from private range, not routable over internet, unless the peer is in the
same private network.
I suggest to try a change to left=%any, rightsubnet=0.0.0.0/0,
leftsourceip=%config. You should not specify leftsubnet, it has same
effect as leftsubnet=%dynamic. Also delete type=transport or change it
to tunnel.
If that did not help, please can you increase loglevel as described here
https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration
and provide the log?
Especially emphasized lines in bold below are important, achieved with
following settings in strongswan.d/charon-logging.conf:
enc = 1
job = 1
cfg = 2
ike = 4
mgr = 4
knl = 2
Also attach output of ipsec statusall command.
Log should look like this, even though this is from VPN server to which
roadwarriors are connecting to:
2015-04-18 21:40:28 10[IKE] roadwarrior|1 IKE_SA roadwarrior[1] state
change: CONNECTING = ESTABLISHED
2015-04-18 21:40:28 10[IKE] roadwarrior|1 scheduling reauthentication in
9746s
2015-04-18 21:40:28 10[IKE] roadwarrior|1 maximum IKE_SA lifetime 10286s
2015-04-18 21:40:28 10[IKE] roadwarrior|1 sending end entity cert C=CZ,
O=Aloha, CN=swan.aloha.com
2015-04-18 21:40:28 10[IKE] roadwarrior|1 peer requested virtual IP %any
2015-04-18 21:40:28 10[CFG] roadwarrior|1 assigning new lease to 'C=CZ,
O=Aloha, CN=GoodBoy'
2015-04-18 21:40:28 10[IKE] roadwarrior|1 assigning virtual IP
192.168.55.1 to peer 'C=CZ, O=Aloha, CN=GoodBoy'
2015-04-18 21:40:28 10[IKE] roadwarrior|1 peer requested virtual IP %any6
2015-04-18 21:40:28 10[IKE] roadwarrior|1 no virtual IP found for %any6
requested by 'C=CZ, O=Aloha, CN=GoodBoy'
2015-04-18 21:40:28 10[IKE] roadwarrior|1 building INTERNAL_IP4_DNS
attribute
2015-04-18 21:40:28 10[IKE] roadwarrior|1 building INTERNAL_IP4_DNS
attribute
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 looking for a child config for
0.0.0.0/0 ::/0 === 0.0.0.0/0 ::/0*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 proposing traffic selectors
for us:*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 0.0.0.0/0*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 proposing traffic selectors
for other:*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 192.168.55.1/32*
2015-04-18 21:40:28 10[CFG] roadwarrior|1 candidate roadwarrior with
prio 10+2
2015-04-18 21:40:28 10[CFG] roadwarrior|1 found matching child config
roadwarrior with prio 12
2015-04-18 21:40:28 10[CFG] roadwarrior|1 selecting proposal:
2015-04-18 21:40:28 10[CFG] roadwarrior|1 no acceptable
ENCRYPTION_ALGORITHM found
2015-04-18 21:40:28 10[CFG] roadwarrior|1 selecting proposal:
2015-04-18 21:40:28 10[CFG] roadwarrior|1 no acceptable
INTEGRITY_ALGORITHM found
2015-04-18 21:40:28 10[CFG] roadwarrior|1 selecting proposal:
2015-04-18 21:40:28 10[CFG] roadwarrior|1 no acceptable
ENCRYPTION_ALGORITHM found
2015-04-18 21:40:28 10[CFG] roadwarrior|1 selecting proposal:
2015-04-18 21:40:28 10[CFG] roadwarrior|1 proposal matches
2015-04-18 21:40:28 10[CFG] roadwarrior|1 received proposals:
ESP:AES_GCM_16_128/AES_GCM_16_256/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_384_192/NO_EXT_SEQ,
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/NO_EXT_SEQ
@
2015-04-18 21:40:28 10[CFG] roadwarrior|1 selected proposal:
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
2015-04-18 21:40:28 10[KNL] roadwarrior|1 got SPI cff90361
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 selecting traffic selectors
for us:*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 config: 0.0.0.0/0, received:
0.0.0.0/0 = match: 0.0.0.0/0*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 config: 0.0.0.0/0, received:
::/0 = no match*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 selecting traffic selectors
for other:*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 config: 192.168.55.1/32,
received: 0.0.0.0/0 = match: 192.168.55.1/32*
*2015-04-18 21:40:28 10[CFG] roadwarrior|1 config: 192.168.55.1/32,
received: ::/0 = no match*
2015-04-18 21:40:28 10[KNL] roadwarrior|1 adding SAD entry with SPI
cff90361 and reqid {1} (mark 0/0x)
2015-04-18 21:40:28 10[KNL] roadwarrior|1 using encryption algorithm
AES_CBC with key size 128
2015-04-18 21:40:28 10[KNL] roadwarrior|1 using integrity algorithm
HMAC_SHA1_96 with key size 160
2015-04-18 21:40:28 10[KNL] roadwarrior|1 using replay window of 32
packets
2015-04-18 21:40:29 10[KNL] roadwarrior|1 adding SAD entry with SPI
a2210fbc and reqid {1} (mark 0/0x)
2015-04-18 21:40:29 10[KNL] roadwarrior|1 using encryption algorithm
AES_CBC with key size 128
2015-04-18 21:40:29 10[KNL] roadwarrior|1 using integrity algorithm
HMAC_SHA1_96 with key size 160
2015-04-18 21:40:29 10[KNL] roadwarrior|1 using replay window of 32
packets
2015-04-18
Re: [strongSwan] /etc/strongswan.d/VPN.conf:1: syntax error, unexpected NAME, expecting NEWLINE or '{' or '=' [vpn]
Hi Stephen, Please delete type=transport or change it to type=tunnel. Also delete rightprotoport and leftprotoport. If this did not help, please provide again ipsec statusall + enable logging at higher level as described here https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration and provide logfile. Regards, Miroslav On Monday, April 20, 2015 at 1:47:48 AM UTC+2, Stephen Feyrer wrote: Hi Miroslav, You are correct, the syntax error is gone. Sadly, there is not much which I can tell you about my office Network topology. All that I do know is that we pass through a Windows Firewall before being able to connect our work stations. code: # ipsec.conf - strongSwan IPsec configuration file # basic configuration config setup # strictcrlpolicy=yes # uniqueids = no conn VPN-OFFICE-COM keyexchange=ikev1 type=transport authby=secret ike=3des-sha1-modp1024 rekey=no left=%any leftsourceip=%config leftprotoport=udp/l2tp right=vpn.office.com rightprotoport=udp/l2tp rightid=17.11.7.5 rightsubnet=0.0.0.0/0 auto=add # ipsec up VPN-OFFICE-COM initiating Main Mode IKE_SA VPN-OFFICE-COM[14] to 17.11.7.5 generating ID_PROT request 0 [ SA V V V V ] sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (212 bytes) received packet: from 17.11.7.5[500] to 1.2.3.4[500] (116 bytes) parsed ID_PROT response 0 [ SA V V ] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID received FRAGMENTATION vendor ID generating ID_PROT request 0 [ KE No NAT-D NAT-D ] sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (244 bytes) received packet: from 17.11.7.5[500] to 1.2.3.4[500] (304 bytes) parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ] received Cisco Unity vendor ID received XAuth vendor ID received unknown vendor ID: [HIDDEN] received unknown vendor ID: [HIDDEN] local host is behind NAT, sending keep alives generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ] sending packet: from 1.2.3.4[4500] to 17.11.7.5[4500] (84 bytes) received packet: from 17.11.7.5[4500] to 1.2.3.4[4500] (84 bytes) parsed ID_PROT response 0 [ ID HASH V ] received DPD vendor ID IKE_SA VPN-OFFICE-COM[14] established between 1.2.3.4[1.2.3.4]...17.11.7.5[17.11.7.5] generating QUICK_MODE request [HIDDEN] [ HASH SA No ID ID NAT-OA NAT-OA ] sending packet: from 1.2.3.4[4500] to 17.11.7.5[4500] (220 bytes) received packet: from 17.11.7.5[4500] to 1.2.3.4[4500] (180 bytes) parsed QUICK_MODE response [HIDDEN] [ HASH SA No ID ID N(([HIDDEN])) NAT-OA ] received 28800s lifetime, configured 0s no acceptable traffic selectors found establishing connection 'VPN-OFFICE-COM' failed # ipsec statusall Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.16.5-gentoo, x86_64): uptime: 3 hours, since Apr 19 20:50:15 2015 malloc: sbrk [HIDDEN], mmap 0, used [HIDDEN], free [HIDDEN] worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1 loaded plugins: charon ldap mysql sqlite aes des rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp xcbc cmac hmac curl attr kernel-netlink resolve socket-default socket-dynamic farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap xauth-pam dhcp lookip led unity Listening IP addresses: 1.2.3.4 Connections: VPN-OFFICE-COM: %any...vpn.office.com IKEv1 VPN-OFFICE-COM: local: [1.2.3.4] uses pre-shared key authentication VPN-OFFICE-COM: remote: [17.11.7.5] uses pre-shared key authentication VPN-OFFICE-COM: child: dynamic[udp/l2tp] === dynamic[udp/l2tp] TRANSPORT Security Associations (1 up, 0 connecting): VPN-OFFICE-COM[14]: ESTABLISHED 6 seconds ago, 1.2.3.4[1.2.3.4]...17.11.7.5[17.11.7.5] VPN-OFFICE-COM[14]: IKEv1 SPIs: [HIDDEN]_i* [HIDDEN]_r, rekeying disabled VPN-OFFICE-COM[14]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Thank you for your help. I hope this tells you more than it does me. -- Kind regards Stephen Feyrer. On Sun, 19 Apr 2015 09:11:04 +0100, Miroslav Svoboda good...@goodmirek.cz javascript: wrote: Hi Stephen, So I assume there is no longer any syntax error reported. From logfile I see there is no acceptable traffic selector. I assume that you have a home PC (Ubuntu) with Strongswan which you want to connect to the office VPN concentrator with IP 17.11.7.5 running Windows. I suppose VPN concentrator in the office is not configured to route any traffic towards you home PC's IP address, thus you will need a virtual IP address assigned to your home PC by the VPN concentrator. Also I suppose you want to route all traffic via that VPN once connected. Then, please try to modify left=%defaultroute to
