williamm, set the same settings for ip ipsec peer and ip ipsec proposal configuration. As currently you have different settings for them, as it is written in the log.
michalciza2, are you able to establish the connect, when host is not behind the NAT?
sergejs,
I really don’t know why the log informs that about encryption-algorithm mismatch. Both the ipsec proposal and peer and configured with 3des. Maybe the “peer” in line logs refers to the ipsec client. And If you check the next line in logs, it’s informed that the encryption peer is adjusted:
18:12:08 ipsec Adjusting my encmode UDP-Transport->Transport
18:12:08 ipsec trns_id mismatched: my:3DES peer:AES
18:12:08 ipsec not matched
18:12:08 ipsec Adjusting peer’s encmode UDP-Transport(4)->Transport(2)
From Microsoft’s Article ID: 942957 it´s stated:
By default, if the Allow only secure connections option is selected, Windows Vista negotiates by using the AES-128 encryption method and the 3DES encryption method.
Anyway if I only disable the NAT-T and connect the Windows Vista client directly to the public IP, the L2TP connects perfectly.
William.
Will this problem be fixed for version 3.30 as well?
It will not be fixed for 3.30, only if there will be new v3.x version.
But current stable version is v4.x, you should use it.
I do have that same problem when client has public IP it works like charm but when client is not it’s stuck in trying to connect to L2TP server.
Kamil
I also seem to have the same issue. Unfortunately I didn’t notice it was the same issue and created a new topic: http://forum.mikrotik.com/t/trying-to-get-my-iphone-to-connect-to-my-routeros-with-l2tp/36328/3
Can someone merge the topics ?
This issue still hasn’t been resolved, even on 5.0b3.
It looks like the problem is in ipsec policy.
installed sa:
0 E spi=0x1C55FBB src-address=78.38.29.135 dst-address=78.153.66.123
generated policy:
0 D src-address=10.254.254.130/32:any dst-address=78.153.66.123/32:any (10.254.254.130 is the internal ip of the client behind NAT)
so the client properly encrypts the packets and when the RouterOS wants to reply to them, they fall out of ipsec policy and go out via default - public route.
This issue makes L2TP server with NAT-T impossible to use.
Hope it will get fixed soon.
I’ve written to support about that bug long time ago. Most likely it will not be fixed in any near future. In fact it makes L2TP useless - I had to switch L2TP+IPsec to Windows Server and works without any problem.
Kamil.
I agree. OpenVPN is somewhat usable with tweaks, but no native cross-platform support. PPTP is not usable for site to site VPNs (secure at least). SSTP seems to work so far, but again, no native cross-platform support.
My preference would be IPSEC/L2TP and that was my plan all along, but it never worked properly in ROS.
Exactly and it is very dissapointing, because there is none properly implemented and fast remote access solution on RouterOS.
I wouldn’t expect too much, sadly. Hell, they took the hardware acceleration for encryption out of the RB1100.
The main MikroTik problem is that, they make something good, and astonishing but in the end that new thing doesn’t have a “final touch”, I mean that we can say is “finished” and ready to be used in production environment.
I’m almost totally agree with siel.
I’m trying to do the opposite, the client IPSec/L2TP RouterOS (v5.0beta3 and v4.10) and the server Linux with racoon and l2tpns. The client is behind the nat, the server has an IP Public (tipically roadwarrior scenario).
The same happens, I have the SA’s installed, the interface l2tp running, and I can reach (ping) from the client to the server the private interface but without answer. On linux server a virtual interface tun is up by l2tpns) I can see the request/replay icmp packet correctly, but never goes back to the client.
I tried to generate my own policy without good results.
I start to think like siel, the problem is l2tp, but before I said almost, because it’s affect several implementation of l2tp.
I hope someone has a solution!
/rodrigo
Me again, the last comment let me think and I just tried l2tp without ipsec and work great!
I mean I can reach well from client to server IP tunnel and even more I can ping an IP address behind the server, after adding the necessary routes.
So its let me know that l2tp isn’t the problem, something is wrong in ipsec policies or missing configuration on that.
If someone have an idea let as know!
thanks.-
/rodrigo
I do have an idea. ROS and NAT-T just don’t work together.
Simple test:
[Client|192.168.84.2]---<private lan>---[192.168.84.1|NAT Router|nn.nn.nn.nn]---<public internet>---[ss.ss.ss.ss|Server]
Client runs Windows 7.
NAT Router is doing nothing special, just masquerading the traffic.
Server is RouterOS with IPSec peer 0.0.0.0/0 and auto generate policy.
On client there’s IPSec policy to encrypt ICMP to ss.ss.ss.ss.
ping -t ss.ss.ss.ss is running on client.
This is tcpdump output from nn.nn.nn.nn interface on NAT Router:
// this is how it looks before IPSec policy is enabled:
17:53:35.742256 nn.nn.nn.nn > ss.ss.ss.ss: icmp: echo request
17:53:35.762503 ss.ss.ss.ss > nn.nn.nn.nn: icmp: echo reply
17:53:36.740564 nn.nn.nn.nn > ss.ss.ss.ss: icmp: echo request
17:53:36.763472 ss.ss.ss.ss > nn.nn.nn.nn: icmp: echo reply
// now it was enabled:
17:53:37.742869 nn.nn.nn.nn.500 > ss.ss.ss.ss.500: isakmp: phase 1 I ident: [|sa]
17:53:37.774797 ss.ss.ss.ss.500 > nn.nn.nn.nn.500: isakmp: phase 1 R ident: [|sa] (DF)
17:53:37.786527 nn.nn.nn.nn.500 > ss.ss.ss.ss.500: isakmp: phase 1 I ident: [|ke]
17:53:38.060922 ss.ss.ss.ss.500 > nn.nn.nn.nn.500: isakmp: phase 1 R ident: [|ke] (DF)
// and you can see that NAT was detected and IPSec is correctly encapsulated in udp (NAT-T):
17:53:38.066047 nn.nn.nn.nn.4500 > ss.ss.ss.ss.4500: udp 72
17:53:38.299549 ss.ss.ss.ss.4500 > nn.nn.nn.nn.4500: udp 72 (DF)
17:53:38.302290 nn.nn.nn.nn.4500 > ss.ss.ss.ss.4500: udp 200
17:53:38.341726 ss.ss.ss.ss.4500 > nn.nn.nn.nn.4500: udp 152 (DF)
17:53:38.343059 nn.nn.nn.nn.4500 > ss.ss.ss.ss.4500: udp 76
17:53:38.343336 nn.nn.nn.nn.4500 > ss.ss.ss.ss.4500: udp 64
17:53:42.496674 nn.nn.nn.nn.4500 > ss.ss.ss.ss.4500: udp 76
// and here's the problem, ROS sends the reply to public IP of NAT Router:
17:53:42.519239 ss.ss.ss.ss > nn.nn.nn.nn: icmp: echo reply
17:53:47.488391 nn.nn.nn.nn.4500 > ss.ss.ss.ss.4500: udp 76
17:53:47.510976 ss.ss.ss.ss > nn.nn.nn.nn: icmp: echo reply
This is how it looks on Server:
17:53:37 ipsec respond new phase 1 negotiation: ss.ss.ss.ss[500]<=>nn.nn.nn.nn[500]
17:53:37 ipsec begin Identity Protection mode.
17:53:37 ipsec received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
17:53:37 ipsec received Vendor ID: RFC 3947
17:53:37 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
17:53:37 ipsec
17:53:37 ipsec received Vendor ID: FRAGMENTATION
17:53:37 ipsec Selected NAT-T version: RFC 3947
17:53:37 ipsec Hashing ss.ss.ss.ss[500] with algo #2
17:53:37 ipsec NAT-D payload #0 verified
17:53:37 ipsec Hashing nn.nn.nn.nn[500] with algo #2
17:53:37 ipsec NAT-D payload #1 doesn't match
17:53:37 ipsec NAT detected: PEER
17:53:38 ipsec Hashing nn.nn.nn.nn[500] with algo #2
17:53:38 ipsec Hashing ss.ss.ss.ss[500] with algo #2
17:53:38 ipsec Adding remote and local NAT-D payloads.
17:53:38 ipsec NAT-T: ports changed to: nn.nn.nn.nn[4500]<->ss.ss.ss.ss[4500]
17:53:38 ipsec KA list add: ss.ss.ss.ss[4500]->nn.nn.nn.nn[4500]
17:53:38 ipsec ISAKMP-SA established ss.ss.ss.ss[4500]-nn.nn.nn.nn[4500] spi:ade1d76b90eb17a8:6f90143abe23e16f
17:53:38 ipsec respond new phase 2 negotiation: ss.ss.ss.ss[4500]<=>nn.nn.nn.nn[4500]
17:53:38 ipsec no policy found, try to generate the policy : 192.168.84.2/32[0] ss.ss.ss.ss/32[0] proto=icmp dir=in
17:53:38 ipsec Adjusting my encmode UDP-Transport->Transport
17:53:38 ipsec Adjusting peer's encmode UDP-Transport(4)->Transport(2)
17:53:38 ipsec IPsec-SA established: ESP/Transport nn.nn.nn.nn[4500]->ss.ss.ss.ss[4500] spi=5091372(0x4db02c)
17:53:38 ipsec IPsec-SA established: ESP/Transport ss.ss.ss.ss[4500]->nn.nn.nn.nn[4500] spi=2918330273(0xadf22fa1)
And logging of output icmp packets from router looks like this:
17:53:42 firewall,info output: in:(none) out:public, proto ICMP (type 0, code 0), ss.ss.ss.ss->nn.nn.nn.nn, len 40
17:53:47 firewall,info output: in:(none) out:public, proto ICMP (type 0, code 0), ss.ss.ss.ss->nn.nn.nn.nn, len 40
They go straight to nn.nn.nn.nn instead of to correct 192.168.84.2.
may be you can try this way.
nat-t :
win2003 (Ipsec vpn server) ------Ros3.20 Gateway ==== Internet ==== client or client behind NAT
All you need to do Just map udp port 4500 1701 500 to win2003.
[admin@MikroTik] /ip firewall nat> export
jun/23/2010 13:28:51 by RouterOS 3.20
software id = NNFT-86N
/ip firewall nat
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=60.10.20.30 dst-port=1701 protocol=udp to-addresses=192.168.100.125 to-ports=1701
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=60.10.20.30 dst-port=500 protocol=udp to-addresses=192.168.100.125 to-ports=500
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=60.10.20.30 dst-port=4500 protocol=udp to-addresses=192.168.100.125 to-ports=4500
regedit:xp client
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec
AssumeUDPEncapsulationContextOnSendRule =2
regedit:win7 vista
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002
Also I have tested Openvpn, version 2.6.24 works fine with nat-t,but 2.6.21 didn't work.
Vista has many DHCP problems that are admitted by the MS knowledge-base.
Brand new Toshiba laptop with brand new Win7 simply doesn’t get IP from 4.5/3.20/3.30 DHCP via ethernet. It simply doesn’t! Iphones/Xperias/Nokias/MacOS/Windows XP and Linuxes do fine. What to blame? Think!
I know this issue, it exists in Vista but not in 7 (to my knowledge). Microsoft knows about it. It manifests itself when you disconnect your network cable and then plug it back, Vista doesn’t seem to notice that the DHCP server was gone, and doesn’t ask for new IP.
Nope. Not even connecting the cable the first time and not after restart with cable in socket.
And stop editing my posts! 