The goal of this post is to achieve client access to StrongVPN’s IPsec-transported VPN service. However, this is not a tutorial on how to establish such connection with RouterOS, but a tracking of my steps so that someone else is able to correct my mistakes. Readers of this post are welcome to contribute so that those of us whose livelihood is dependent on VPN services overseas could be improved.
Microsoft’s L2TP+IPsec client/server configuration has concealed so many details that are often crucial in establishing a proper connection from a generic client. As such, part of the goal of this post is to dissect the Microsoft implementation so that any client is capable of accessing a Microsoft server configured with L2TP+IPsec.
A summary of IPsec-transported L2TP ensues.
The VPN connection consists of two steps. IPsec comes first followed by L2TP. If you reverse the order, then you risk grave security risks and percussions. The IPsec step should run in transport mode, as we are not attempting to bridge VLANs. And the IPsec itself consists of two phases. Phase 1 is, in Microsoft’s terminology, Main Mode, or, in Mikrotik terminology, Peer. Phase 2 is Quick Mode in Microsoft’s Terminology and Policy+Proposal in MikroTik’s. To make our lives easier, in the Microsoft world, mm and qm are shorthands respectively for Main Mode and Quick Mode.
Now onto my network topology.
----
IPsec and L2TP passthrough is already enabled on the Cisco router, so there is no need to configure additional port forwarding for port 500 or port 4500 (if NAT-T is required).
My configuration is listed as follows:
/ip ipsec peer add address=/32 auth-method=pre-shared-key dh-group=modp1024 disabled=no dpd-interval=10s dpd-maximum-failures=5 enc-algorithm=3des exchange-mode=main-l2tp generate-policy=no hash-algorithm=sha1 lifetime=8h nat-traversal=no passive=no port=500 secret= send-initial-contact=yes
/ip ipsec policy add action=encrypt disabled=no dst-address=/32 dst-port=any ipsec-protocols=esp level=require priority=0 proposal=StrongVPN-L2TP protocol=all sa-dst-address= sa-src-address= src-address=/32 src-port=any tunnel=no
/ip ipsec proposal add lifetime=1h name=StrongVPN-L2TP pfs-group=none auth-algorithms=sha1 enc-algorithms=3des
As you might wonder where I managed to receive the correct set of parameters, I picked the most of them from <1> (see References) with intention to secure compatibility with older Windows (NT) versions. However, a significant number of parameters are taken from PowerShell 4.0 cmdlet Get-NetIPsecMainModeSA and Get-NetIPsecQuickModeSA available in the PowerShell module NetworkSecurity which is only available in Windows (NT) 6.3 or later, or in part accessible via “netsh ipsec dynamic show all”. These information is present in Reference <2>, <3> and <4> respectively. If you are having problems with the variable “Sec Methods” in Reference <2>, note that the clue of the format could be found in “netsh ipsec dynamic add qmpolicy”.
I could see in the “Remote Peers” tab that a connection with the remote server is established. And when I started the L2TP client from the PPP section, I could see two connections established in the “Installed SAs” tab. However, I keep getting an error saying that “old tunnel is not closed yet”. As such, I cannot manage a L2TP dial-up.
Another suspicious point of note is that the Encryption/Hash Algorithm with each of the two connections found in the “Installed SAs” tab is none.
Could anyone tell me if anything is wrong in this set-up? Did I manage to get an IPsec transport mode running? Did I manage to establish SAs for both of the IKE phases?
Also, when I took a look at an equivalent on my Windows NT 6.3 client, the key exchange in IKE Phase 1 comes with DH Group 20, or DH20 in Microsoft terminology (see Reference <3>). Does that also make a difference? Does MikroTik plan to support DH20 at any point in the future? If yes, could I get an alpha/beta version of RouterOS that supports such? Also, since I have noticed successes from another StrongVPN customer on an IOS device with modp1024, or DH Group 2, the modp1024 option on Mikrotik is likely to be also a valid option.
This post is bound to be updated in the near future and I will inform StrongVPN people also of the input here.
References:
<1> IPsec Algorithms and Methods Supported in Windows
<2> stdout from netsh
netsh ipsec dynamic show all
IKE Main Mode SAs at REDACTED::DATETIME
Cookie Pair: REDACTED::RAND
Sec Methods: NONE/SHA1/5/28800
Auth Mode: Preshared Key
Source: REDACTED::LAN_WAN_ADDR , port 37905
ID: REDACTED::LAN_WAN_ADDR
Destination: REDACTED::WAN_ADDR , port 37905
ID: REDACTED::WAN_ADDR
Quick Mode SAs
Transport Filter
Source Address: REDACTED::LAN_WAN_ADDR
Destination Address: REDACTED::WAN_ADDR
Protocol: UDP
Source Port: 1701
Destination Port: 1701
Direction: Outbound
Encapsulation Type: Other
Source UDP Encap port: 4500
Dest UDP Encap port: 4500
Peer Private Addr: 0.0.0.0
Offer Used
AH(b/r): None
ESP Con(b/r): None
ESP Int: SHA1
PFS DH Group:
IPsec Configuration Parameters
StrongCRLCheck: 1
IPsecexempt: 3
<3> stdout from Get-NetIPsecMainModeSA
Get-NetIPsecMainModeSA
Name: 26
LocalEndpoint: REDACTED::LAN_WAN_ADDR
RemoteEndpoint: REDACTED::WAN_ADDR
LocalFirstId.Identity:
LocalFirstId.ImpersonationType: None
LocalFirstId.AuthenticationMethod: PresharedKey
LocalFirstId.Flags: None
RemoteFirstId.Identity:
RemoteFirstId.ImpersonationType: None
RemoteFirstId.AuthenticationMethod: PresharedKey
RemoteFirstId.Flags: None
LocalSecondId.Identity:
LocalSecondId.ImpersonationType:
LocalSecondId.AuthenticationMethod:
LocalSecondId.Flags:
RemoteSecondId.Identity:
RemoteSecondId.ImpersonationType:
RemoteSecondId.AuthenticationMethod :
RemoteSecondId.Flags:
CipherAlgorithm: AES256
HashAlgorithm: SHA1
GroupId: DH20
KeyModule: IkeV1
MaxQMSAs: 0
LifetimeSeconds: 28800
LocalUdpEncapsulationPort: 4500
RemoteUdpEncapsulationPort: 4500
ExtendedFilterId: 0
<4> stdout from Get-NetIPsecQuickModeSA
Get-NetIPsecQuickModeSA
Name: 15
LocalEndpoint: REDACTED::LAN_WAN_ADDR
RemoteEndpoint: REDACTED::WAN_ADDR
TransportLayerFilterName: L2TP Client Specific Filter
EncapsulationMode: Transport
Direction: Inbound
LocalPort: 1701
RemotePort: 1701
IpProtocol: 17
InterfaceAlias: REDACTED::INT
RealIfProfileId: 0
LocalUdpEncapsulationPort: 4500
RemoteUdpEncapsulationPort: 4500
SPI: REDACTED::SPI
FirstTransformType: EspAuthAndCipher
FirstIntegrityAlgorithm: SHA1
FirstCipherAlgorithm: AES128
SecondSpi:
SecondTransformType: None
SecondIntegrityAlgorithm: None
SecondCipherAlgorithm: None
Flags: NoExplicitCredMatch, AllowNullTargetNameMatch, AssumeUdpContextOutbound, PeerSupportsGuaranteeEncryption
MmSaId: 26
PfsGroupId: None
PeerV4PrivateAddress: REDACTED::WAN_ADDR
QuickModeFilterid: REDACTED::Filterid
LifetimeSeconds: 3600
LifetimeKilobytes: 250000
LifetimePackets: 2147483647
IdleDurationSeconds: 300
NdAllowClearTimeoutSeconds: 0
NapContext: 0
QmSaId: Redacted::QmSaId
VirtualIfTunnelId: 0
TrafficSelectorId: 0
MmTargetName:
EmTargetName:
ExplicitCredentials:
Name: 15
LocalEndpoint: REDACTED::LAN_WAN_ADDR
RemoteEndpoint: REDACTED::WAN_ADDR
TransportLayerFilterName: L2TP Client Specific Filter
EncapsulationMode: Transport
Direction: Outbound
LocalPort: 1701
RemotePort: 1701
IpProtocol: 17
InterfaceAlias: REDACTED::INT
RealIfProfileId: 1
LocalUdpEncapsulationPort : 4500
RemoteUdpEncapsulationPort : 4500
SPI: REDACTED::SPI
FirstTransformType: EspAuthAndCipher
FirstIntegrityAlgorithm: SHA1
FirstCipherAlgorithm: AES128
SecondSpi:
SecondTransformType: None
SecondIntegrityAlgorithm: None
SecondCipherAlgorithm: None
Flags: NoExplicitCredMatch, AllowNullTargetNameMatch, AssumeUdpContextOutbound, PeerSupportsGuaranteeEncryption
MmSaId: REDACTED::MmSaId
PfsGroupId : None
PeerV4PrivateAddress: REDACTED::WAN_ADDR
QuickModeFilterid: REDACTED::Filterid
LifetimeSeconds: 3600
LifetimeKilobytes: 250000
LifetimePackets: 2147483647
IdleDurationSeconds: 300
NdAllowClearTimeoutSeconds: 0
NapContext: 0
QmSaId: REDACTED::QmSaId
VirtualIfTunnelId: 0
TrafficSelectorId: 0
MmTargetName:
EmTargetName:
ExplicitCredentials: