Community discussions

MikroTik App
 
mikroguf
just joined
Topic Author
Posts: 11
Joined: Mon Dec 06, 2010 5:40 am

NAT-T & IPSec Issues still exist

Mon Dec 06, 2010 5:58 am

Hi all,

First post - but I've been lurking for a while!

We have been doing extensive testing with remote users establishing L2TP/IPSec tunnels to an RB450G, now running V5.0 RC3. We're using the built in L2TP/IPSec capability of a few different clients, namely WindowsXP, Windows Vista/7 and Mac.

We have an IPSec peer setup allowing connections from 0.0.0.0/0 with 'generate policy' and 'use NAT-T' set.

Prior to V5.0, NAT-T would not work at all, although we could establish policies and tunnels when there was no NAT on the IP path.

Since we installed V5.0, here is what we have found:

1. L2TP/IPSec tunnels work fine from a MAC OS, whether with or without NAT-T
2. L2TP/IPSec tunnels work fine from a Windows XP when there is no NAT. In this case, Windows XP sends the IPV4 address in its setup and not the FQDN, which Mikrotik is happy about
3. L2TP/IPSec tunnels do not work from Windows XP when NAT is detected and NAT-T negotiated: in this case, XP sends the FQDN not the IPV4 address in the setup, and Mikrotik rejects the IPSec setup
4. L2TP/IPSec tunnels work from Windows Vista/7, but only for one computer at a time; apparently, all Vista/7 clients use the same message id in the setup which prevents a second from establishing a policy at the same time unless the server (in this case Mikrotik) can handle it
5. If the L2TP/IPSec tunnel from the Vista/7 client is disconnect and its not behind NAT, Mikrotik does not flush the policy data correctly and it's not possible to reconnect without forcing a flush, preventing a re-connect; if the client is behind NAT, it seems to flush ok as the client can disconnect/reconnect without problem

It would be good to get an update from Mikrotik as to whether there will be more work on IPSec and NAT-T in V5.0 or whether thats it for now!

Thanks!
 
grg
newbie
Posts: 44
Joined: Fri Aug 20, 2010 9:51 am
Location: Latvia

Re: NAT-T & IPSec Issues still exist

Wed Dec 08, 2010 8:51 am

I would be happy not only to see this problem being fixed, but also IPSec having DH groups going above 5.
 
TKITFrank
Member Candidate
Member Candidate
Posts: 236
Joined: Tue Jul 07, 2009 2:55 pm
Location: Sweden

Re: NAT-T & IPSec Issues still exist

Wed Dec 08, 2010 11:03 pm

I would be happy not only to see this problem being fixed, but also IPSec having DH groups going above 5.
Amen to that...

And also SHA2 256/512 would be nice :)
 
mikroguf
just joined
Topic Author
Posts: 11
Joined: Mon Dec 06, 2010 5:40 am

Re: NAT-T & IPSec Issues still exist

Sun Mar 06, 2011 11:53 pm

Hi Mikrotik,

I see RC11 is out and more work has been done on IPSec. However, no news about these final issues with ids for Vista/7 and XP behind NAT-T.

I'd be really grateful for just a clue as to whether anyone will look at it, so we can decide whether to stop waiting and go looking for another solution!

Thanks!
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6695
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: NAT-T & IPSec Issues still exist

Wed Mar 09, 2011 10:47 am

The most problematic point is NAT-T and generate-policy=yes using together.
The automatic policy is being generated for private IP address of the router, and additionally you should add manually one more policy with
src-address=your_MikroTik_router dst-address=your_NAT_router
 
User avatar
stmx38
Long time Member
Long time Member
Posts: 618
Joined: Thu Feb 14, 2008 4:03 pm
Location: Moldova, Chisinau

Re: NAT-T & IPSec Issues still exist

Tue Nov 15, 2011 11:08 pm

It seems that ROS 5.8 have same issue as described in first post.

PPtP - not secure.
L2TP - work bad.
OpenVPN - has a limitation(username+pass,-lzo,-udp).
SSTP - seems to be work fine, but only with wv,w7,w2k8.
IP Sec - work fine.

ROS is the best :).

What we can use for remote employees ?
 
User avatar
greencomputing
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Wed Jun 23, 2010 1:12 pm
Location: Italy

Re: NAT-T & IPSec Issues still exist

Wed Nov 16, 2011 3:25 am

did you take in consideration to use a weak but light tunneling method like pptp and giving access to remote users just to the services that they really need using further password mechanism. you implemnt sandbox like schema using /ip/fireall/filter and checking that jailed user can just go on some specific hosts intrenally to the office network and there you will add extra protected access mechanism

Just an idea
 
Rivera
Member Candidate
Member Candidate
Posts: 105
Joined: Thu Jul 21, 2011 7:42 pm

Re: NAT-T & IPSec Issues still exist

Wed Nov 16, 2011 2:56 pm

ROS 5.8
IPSec and IPSec/L2TP does not work with Mac OS X. Works fine with windows and linux.
 
User avatar
stmx38
Long time Member
Long time Member
Posts: 618
Joined: Thu Feb 14, 2008 4:03 pm
Location: Moldova, Chisinau

Re: NAT-T & IPSec Issues still exist

Wed Nov 16, 2011 3:44 pm

Works fine with windows and linux.
What version of Windows and behind NAT or no ?
 
Rivera
Member Candidate
Member Candidate
Posts: 105
Joined: Thu Jul 21, 2011 7:42 pm

Re: NAT-T & IPSec Issues still exist

Sat Nov 19, 2011 8:35 pm

Tested windows 7 and windows 8, both with NAT (connecting inside NAT) and from remote.
 
2400baud
newbie
Posts: 29
Joined: Tue Nov 15, 2011 1:04 am

Re: NAT-T & IPSec Issues still exist

Tue Nov 22, 2011 2:38 am

ROS 5.8
IPSec and IPSec/L2TP does not work with Mac OS X. Works fine with windows and linux.
I just set up MacOS 10.6.8 as an L2TP/IPSec client to ROS 5.8.
It seems to work ok.
 
Rivera
Member Candidate
Member Candidate
Posts: 105
Joined: Thu Jul 21, 2011 7:42 pm

Re: NAT-T & IPSec Issues still exist

Tue Nov 22, 2011 10:31 am

i use Lion, maybe that's the problem.
 
helisat
just joined
Posts: 5
Joined: Thu Nov 20, 2008 4:26 am

Re: NAT-T & IPSec Issues still exist

Tue Jan 10, 2012 5:58 am

Hi .. I had the same problem when using IPsec/L2TP and NAT-T

I resolved this by changing the IPsec > Peer > Exchange Mode from "main" to "main l2tp"

This revision allows the the FQDN as the peer ID with preshared key authorization in main mode;

Cheers,
Luke
 
2400baud
newbie
Posts: 29
Joined: Tue Nov 15, 2011 1:04 am

Re: NAT-T & IPSec Issues still exist

Tue Jan 10, 2012 6:20 am

Hi .. I had the same problem when using IPsec/L2TP and NAT-T

I resolved this by changing the IPsec > Peer > Exchange Mode from "main" to "main l2tp"

This revision allows the the FQDN as the peer ID with preshared key authorization in main mode;

Cheers,
Luke
I take it you're talking about Windows XP, then?
If so, that'd be good news.
 
ditonet
Forum Veteran
Forum Veteran
Posts: 835
Joined: Mon Oct 19, 2009 12:52 am
Location: Europe/Poland/Konstancin-Jeziorna
Contact:

Re: NAT-T & IPSec Issues still exist

Tue Jan 10, 2012 6:19 pm

@helisat
Could you please post working config example?
I'm trying to achieve this (L2TP/IPSec and WinXP behind NAT)
but without success.

TIA,
 
User avatar
thavinci
Member
Member
Posts: 335
Joined: Sat Aug 04, 2007 4:40 pm
Location: Johannessburg
Contact:

Re: NAT-T & IPSec Issues still exist

Fri Feb 03, 2012 2:52 pm

Im starting to think it won't be possible.
I have a simliar issue. Windows 7 as client, Mikrotik with L2TP & IPSEC.

EVERYTHING works fine if NAT isn't involved. As soon as the client is behind NAT it falls apart.
Now as you know that most roadwarriors will fall under this catagory.

I have tried with and without NAT-T and with and without Exchange mode set to main-l2tp and all combinations inbetween with no luck.

I have contacted Mikrotik with supout, then with debugging info but now im getting no response.(we having mail server issues atm so not sure if mails are getting through)
 
User avatar
thavinci
Member
Member
Posts: 335
Joined: Sat Aug 04, 2007 4:40 pm
Location: Johannessburg
Contact:

Re: NAT-T & IPSec Issues still exist

Fri Feb 03, 2012 3:53 pm

If anyone is interested here is a scenario with NAT-T enabled AND exchange mode = main l2tp

Debug is of ipsec portion only....
ipsec,debug,packet 384 bytes message received from 41.134.184.106[38876] to 216.59.3.178[500] in 3-Feb 15:53:38.70 from 216.59.3.178
ipsec,debug,packet ========== in 3-Feb 15:53:38.70 from 216.59.3.178
ipsec,debug,packet 00000001 00000001 000000c8 01010005 03000028 01010000 80010007 800e0100 in 3-Feb 15:53:38.70 from 216.59.3.178
ipsec,debug,packet 2bb63aab a15704c2 00000000 00000000 01100200 00000000 00000180 0d0000d4 in 3-Feb 15:53:38.71 from 216.59.3.178
ipsec,debug,packet 80020002 80040014 80030001 800b0001 000c0004 00007080 03000028 02010000 in 3-Feb 15:53:38.71 from 216.59.3.178
ipsec,debug,packet 80010007 800e0080 80020002 80040013 80030001 800b0001 000c0004 00007080 in 3-Feb 15:53:38.71 from 216.59.3.178
ipsec,debug,packet 000c0004 00007080 03000024 04010000 80010005 80020002 8004000e 80030001 in 3-Feb 15:53:38.71 from 216.59.3.178
ipsec,debug,packet 03000028 03010000 80010007 800e0100 80020002 8004000e 80030001 800b0001 in 3-Feb 15:53:38.71 from 216.59.3.178
ipsec,debug,packet 800b0001 000c0004 00007080 00000024 05010000 80010005 80020002 80040002 in 3-Feb 15:53:38.72 from 216.59.3.178
ipsec,debug,packet b587e461 00000008 0d000014 4a131c81 07035845 5c5728f2 0e95452f 0d000014 in 3-Feb 15:53:38.72 from 216.59.3.178
ipsec,debug,packet 90cb8091 3ebb696e 086381b5 ec427b1f 0d000014 4048b7d5 6ebce885 25e7de7f in 3-Feb 15:53:38.72 from 216.59.3.178
ipsec,debug,packet 80030001 800b0001 000c0004 00007080 0d000018 1e2b5169 05991c7d 7c96fcbf in 3-Feb 15:53:38.72 from 216.59.3.178
ipsec,debug,packet eddb61b3 172a36e3 d0cfb819 00000014 e3a5966a 76379fe7 07228231 e5ce8652 in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug,packet === in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug begin Identity Protection mode. in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug,packet seen nptype=13(vid) in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug,packet seen nptype=1(sa) in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug,packet 00d6c2d3 0d000014 fb1de3cd f341b7ea 16b7e5be 0855f120 0d000014 26244d38 in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug respond new phase 1 negotiation: 216.59.3.178[500]<=>41.134.184.106[38876] in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug,packet begin. in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug,packet seen nptype=13(vid) in 3-Feb 15:53:38.73 from 216.59.3.178
ipsec,debug,packet seen nptype=13(vid) in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug,packet seen nptype=13(vid) in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug,packet seen nptype=13(vid) in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug received Vendor ID: RFC 3947 in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug,packet seen nptype=13(vid) in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug,packet seen nptype=13(vid) in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug,packet succeed. in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug received broken Microsoft ID: MS NT5 ISAKMPOAKLEY in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug  in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug,packet received unknown Vendor ID in 3-Feb 15:53:38.74 from 216.59.3.178
ipsec,debug,packet received unknown Vendor ID in 3-Feb 15:53:38.75 from 216.59.3.178
ipsec,debug,packet 00000001 00000001 000000c8 01010005 03000028 01010000 80010007 800e0100 in 3-Feb 15:53:38.75 from 216.59.3.178
ipsec,debug,packet 80020002 80040014 80030001 800b0001 000c0004 00007080 03000028 02010000 in 3-Feb 15:53:38.75 from 216.59.3.178
ipsec,debug received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 in 3-Feb 15:53:38.75 from 216.59.3.178
ipsec,debug received Vendor ID: FRAGMENTATION in 3-Feb 15:53:38.75 from 216.59.3.178
ipsec,debug,packet received unknown Vendor ID in 3-Feb 15:53:38.75 from 216.59.3.178
ipsec,debug Selected NAT-T version: RFC 3947 in 3-Feb 15:53:38.76 from 216.59.3.178
ipsec,debug,packet total SA len=208 in 3-Feb 15:53:38.76 from 216.59.3.178
ipsec,debug,packet 80010007 800e0080 80020002 80040013 80030001 800b0001 000c0004 00007080 in 3-Feb 15:53:38.76 from 216.59.3.178
ipsec,debug,packet 000c0004 00007080 03000024 04010000 80010005 80020002 8004000e 80030001 in 3-Feb 15:53:38.77 from 216.59.3.178
ipsec,debug,packet 80030001 800b0001 000c0004 00007080 in 3-Feb 15:53:38.77 from 216.59.3.178
ipsec,debug,packet seen nptype=2(prop) in 3-Feb 15:53:38.77 from 216.59.3.178
ipsec,debug,packet succeed. in 3-Feb 15:53:38.78 from 216.59.3.178
ipsec,debug,packet begin. in 3-Feb 15:53:38.78 from 216.59.3.178
ipsec,debug,packet proposal #1 len=200 in 3-Feb 15:53:38.79 from 216.59.3.178
ipsec,debug,packet begin. in 3-Feb 15:53:38.79 from 216.59.3.178
ipsec,debug,packet seen nptype=3(trns) in 3-Feb 15:53:38.80 from 216.59.3.178
ipsec,debug,packet seen nptype=3(trns) in 3-Feb 15:53:38.80 from 216.59.3.178
ipsec,debug,packet succeed. in 3-Feb 15:53:38.80 from 216.59.3.178
ipsec,debug,packet encryption(aes) in 3-Feb 15:53:38.81 from 216.59.3.178
ipsec,debug,packet type=Key Length, flag=0x8000, lorv=256 in 3-Feb 15:53:38.81 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:38.81 from 216.59.3.178
ipsec,debug,packet type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC in 3-Feb 15:53:38.82 from 216.59.3.178
ipsec,debug,packet type=Hash Algorithm, flag=0x8000, lorv=SHA in 3-Feb 15:53:38.82 from 216.59.3.178
ipsec,debug,packet type=Group Description, flag=0x8000, lorv=20 in 3-Feb 15:53:38.83 from 216.59.3.178
ipsec,debug,packet transform #2 len=40 in 3-Feb 15:53:38.83 from 216.59.3.178
ipsec,debug,packet type=Key Length, flag=0x8000, lorv=128 in 3-Feb 15:53:38.84 from 216.59.3.178
ipsec,debug,packet encryption(aes) in 3-Feb 15:53:38.84 from 216.59.3.178
ipsec,debug,packet type=Group Description, flag=0x8000, lorv=19 in 3-Feb 15:53:38.85 from 216.59.3.178
ipsec,debug invalid DH group 19. in 3-Feb 15:53:38.85 from 216.59.3.178
ipsec,debug,packet transform #3 len=40 in 3-Feb 15:53:38.85 from 216.59.3.178
ipsec,debug,packet type=Key Length, flag=0x8000, lorv=256 in 3-Feb 15:53:38.86 from 216.59.3.178
ipsec,debug,packet type=Hash Algorithm, flag=0x8000, lorv=SHA in 3-Feb 15:53:38.87 from 216.59.3.178
ipsec,debug,packet hmac(modp2048) in 3-Feb 15:53:38.87 from 216.59.3.178
ipsec,debug,packet type=Authentication Method, flag=0x8000, lorv=pre-shared key in 3-Feb 15:53:38.88 from 216.59.3.178
ipsec,debug,packet transform #4 len=36 in 3-Feb 15:53:38.88 from 216.59.3.178
ipsec,debug,packet type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC in 3-Feb 15:53:38.88 from 216.59.3.178
ipsec,debug,packet type=Group Description, flag=0x8000, lorv=2048-bit MODP group in 3-Feb 15:53:38.89 from 216.59.3.178
ipsec,debug,packet type=Hash Algorithm, flag=0x8000, lorv=SHA in 3-Feb 15:53:38.90 from 216.59.3.178
ipsec,debug,packet type=Authentication Method, flag=0x8000, lorv=pre-shared key in 3-Feb 15:53:38.90 from 216.59.3.178
ipsec,debug,packet encryption(3des) in 3-Feb 15:53:38.90 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:38.91 from 216.59.3.178
ipsec,debug,packet hmac(modp2048) in 3-Feb 15:53:38.91 from 216.59.3.178
ipsec,debug,packet type=Life Type, flag=0x8000, lorv=seconds in 3-Feb 15:53:38.92 from 216.59.3.178
ipsec,debug,packet transform #5 len=36 in 3-Feb 15:53:38.92 from 216.59.3.178
ipsec,debug,packet type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC in 3-Feb 15:53:38.92 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:38.93 from 216.59.3.178
ipsec,debug,packet type=Authentication Method, flag=0x8000, lorv=pre-shared key in 3-Feb 15:53:38.93 from 216.59.3.178
ipsec,debug,packet type=Life Type, flag=0x8000, lorv=seconds in 3-Feb 15:53:38.94 from 216.59.3.178
ipsec,debug,packet hmac(modp1024) in 3-Feb 15:53:38.95 from 216.59.3.178
ipsec,debug,packet type=Life Duration, flag=0x0000, lorv=4 in 3-Feb 15:53:38.95 from 216.59.3.178
ipsec,debug,packet  0x80b1868: next=(nil) tnext=0x80afc98 in 3-Feb 15:53:38.95 from 216.59.3.178
ipsec,debug,packet    0x80b3bb0: next=(nil) tnext=(nil) in 3-Feb 15:53:38.96 from 216.59.3.178
ipsec,debug,packet prop#=1, prot-id=ISAKMP, spi-size=0, #trns=5 in 3-Feb 15:53:38.96 from 216.59.3.178
ipsec,debug,packet type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC in 3-Feb 15:53:38.96 from 216.59.3.178
ipsec,debug,packet type=Hash Algorithm, flag=0x8000, lorv=SHA in 3-Feb 15:53:38.97 from 216.59.3.178
ipsec,debug,packet type=Authentication Method, flag=0x8000, lorv=pre-shared key in 3-Feb 15:53:38.97 from 216.59.3.178
ipsec,debug,packet Compared: DB:Peer in 3-Feb 15:53:38.98 from 216.59.3.178
ipsec,debug,packet type=Key Length, flag=0x8000, lorv=256 in 3-Feb 15:53:38.98 from 216.59.3.178
ipsec,debug,packet type=Group Description, flag=0x8000, lorv=2048-bit MODP group in 3-Feb 15:53:38.99 from 216.59.3.178
ipsec,debug,packet type=Life Type, flag=0x8000, lorv=seconds in 3-Feb 15:53:39.0 from 216.59.3.178
ipsec,debug,packet type=Life Duration, flag=0x0000, lorv=4 in 3-Feb 15:53:39.0 from 216.59.3.178
ipsec,debug,packet (lifebyte = 0:0) in 3-Feb 15:53:39.1 from 216.59.3.178
ipsec,debug,packet (encklen = 0:256) in 3-Feb 15:53:39.2 from 216.59.3.178
ipsec,debug,packet dh_group = 1024-bit MODP group:2048-bit MODP group in 3-Feb 15:53:39.2 from 216.59.3.178
ipsec,debug,packet prop#=1, prot-id=ISAKMP, spi-size=0, #trns=5 in 3-Feb 15:53:39.2 from 216.59.3.178
ipsec,debug,packet type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC in 3-Feb 15:53:39.3 from 216.59.3.178
ipsec,debug,packet authmethod = pre-shared key:pre-shared key in 3-Feb 15:53:39.3 from 216.59.3.178
ipsec,debug,packet trns#=4, trns-id=IKE in 3-Feb 15:53:39.4 from 216.59.3.178
ipsec,debug,packet type=Hash Algorithm, flag=0x8000, lorv=SHA in 3-Feb 15:53:39.4 from 216.59.3.178
ipsec,debug,packet type=Life Type, flag=0x8000, lorv=seconds in 3-Feb 15:53:39.5 from 216.59.3.178
ipsec,debug,packet type=Life Duration, flag=0x0000, lorv=4 in 3-Feb 15:53:39.5 from 216.59.3.178
ipsec,debug,packet (lifetime = 86400:28800) in 3-Feb 15:53:39.5 from 216.59.3.178
ipsec,debug,packet (lifebyte = 0:0) in 3-Feb 15:53:39.6 from 216.59.3.178
ipsec,debug,packet hashtype = SHA:SHA in 3-Feb 15:53:39.6 from 216.59.3.178
ipsec,debug,packet prop#=1, prot-id=ISAKMP, spi-size=0, #trns=5 in 3-Feb 15:53:39.7 from 216.59.3.178
ipsec,debug,packet (encklen = 0:0) in 3-Feb 15:53:39.7 from 216.59.3.178
ipsec,debug,packet authmethod = pre-shared key:pre-shared key in 3-Feb 15:53:39.8 from 216.59.3.178
ipsec,debug,packet dh_group = 1024-bit MODP group:2048-bit MODP group in 3-Feb 15:53:39.8 from 216.59.3.178
ipsec,debug,packet type=Hash Algorithm, flag=0x8000, lorv=SHA in 3-Feb 15:53:39.9 from 216.59.3.178
ipsec,debug,packet type=Group Description, flag=0x8000, lorv=1024-bit MODP group in 3-Feb 15:53:39.10 from 216.59.3.178
ipsec,debug,packet type=Authentication Method, flag=0x8000, lorv=pre-shared key in 3-Feb 15:53:39.10 from 216.59.3.178
ipsec,debug,packet type=Life Duration, flag=0x0000, lorv=4 in 3-Feb 15:53:39.10 from 216.59.3.178
ipsec,debug,packet (lifebyte = 0:0) in 3-Feb 15:53:39.11 from 216.59.3.178
ipsec,debug,packet enctype = 3DES-CBC:3DES-CBC in 3-Feb 15:53:39.11 from 216.59.3.178
ipsec,debug,packet type=Life Type, flag=0x8000, lorv=seconds in 3-Feb 15:53:39.12 from 216.59.3.178
ipsec,debug,packet Compared: DB:Peer in 3-Feb 15:53:39.12 from 216.59.3.178
ipsec,debug,packet (lifetime = 86400:28800) in 3-Feb 15:53:39.13 from 216.59.3.178
ipsec,debug,packet (encklen = 0:0) in 3-Feb 15:53:39.13 from 216.59.3.178
ipsec,debug,packet hashtype = SHA:SHA in 3-Feb 15:53:39.13 from 216.59.3.178
ipsec,debug,packet an acceptable proposal found. in 3-Feb 15:53:39.14 from 216.59.3.178
ipsec,debug,packet hmac(modp1024) in 3-Feb 15:53:39.14 from 216.59.3.178
ipsec,debug,packet === in 3-Feb 15:53:39.15 from 216.59.3.178
ipsec,debug,packet aa2fbffb09403970  in 3-Feb 15:53:39.15 from 216.59.3.178
ipsec,debug,packet new cookie: in 3-Feb 15:53:39.15 from 216.59.3.178
ipsec,debug,packet add payload of len 52, next type 13 in 3-Feb 15:53:39.16 from 216.59.3.178
ipsec,debug,packet add payload of len 16, next type 0 in 3-Feb 15:53:39.17 from 216.59.3.178
ipsec,debug,packet 124 bytes from 216.59.3.178[500] to 41.134.184.106[38876] in 3-Feb 15:53:39.17 from 216.59.3.178
ipsec,debug,packet send packet to 41.134.184.106[38876] in 3-Feb 15:53:39.17 from 216.59.3.178
ipsec,debug,packet dst4 41.134.184.106[38876] in 3-Feb 15:53:39.18 from 216.59.3.178
ipsec,debug,packet 2bb63aab a15704c2 aa2fbffb 09403970 01100200 00000000 0000007c 0d000038 in 3-Feb 15:53:39.18 from 216.59.3.178
ipsec,debug,packet 80040002 80030001 800b0001 000c0004 00007080 0d000014 4a131c81 07035845 in 3-Feb 15:53:39.19 from 216.59.3.178
ipsec,debug,packet resend phase1 packet 2bb63aaba15704c2:aa2fbffb09403970 in 3-Feb 15:53:39.20 from 216.59.3.178
ipsec,debug,packet 00000001 00000001 0000002c 01010001 00000024 05010000 80010005 80020002 in 3-Feb 15:53:39.20 from 216.59.3.178
ipsec,debug,packet 5c5728f2 0e95452f 00000014 afcad713 68a1f1c9 6b8696fc 77570100 in 3-Feb 15:53:39.21 from 216.59.3.178
ipsec,debug,packet ========== in 3-Feb 15:53:39.39 from 216.59.3.178
ipsec,debug,packet 2bb63aab a15704c2 aa2fbffb 09403970 04100200 00000000 00000104 0a000084 in 3-Feb 15:53:39.40 from 216.59.3.178
ipsec,debug,packet 956a28ea bc18df94 ee364d36 d4cb068f 5ed41899 a59735cd 968bd7a8 09fa3257 in 3-Feb 15:53:39.41 from 216.59.3.178
ipsec,debug,packet 260 bytes message received from 41.134.184.106[38876] to 216.59.3.178[500] in 3-Feb 15:53:39.41 from 216.59.3.178
ipsec,debug,packet 68adb832 4c964d69 ebc3adc0 1b66bbf2 c316961d b6a82826 ceec43ef 607f3868 in 3-Feb 15:53:39.42 from 216.59.3.178
ipsec,debug,packet 14000034 2876c80c 78c412a7 8b5530f0 17e0677f e4f39884 ebc7953c 75d57984 in 3-Feb 15:53:39.43 from 216.59.3.178
ipsec,debug,packet 36011313 in 3-Feb 15:53:39.44 from 216.59.3.178
ipsec,debug,packet seen nptype=4(ke) in 3-Feb 15:53:39.45 from 216.59.3.178
ipsec,debug,packet ed25e814 212e9364 fe25b17b 93e028bd f971a49f 7b874587 20987392 d1961654 in 3-Feb 15:53:39.45 from 216.59.3.178
ipsec,debug,packet 18bd1061 d8f45400 d261e43e 0b4e921f b9c66515 2989a206 7617b249 d02aae7d in 3-Feb 15:53:39.45 from 216.59.3.178
ipsec,debug,packet d8f51570 490a9685 420a5283 35c7d3f3 381e00ab 14000018 f01f6693 3578b33f in 3-Feb 15:53:39.46 from 216.59.3.178
ipsec,debug,packet 8d821392 5dca164c 92d0ef9f 00000018 1c183356 a85d680c b980da03 bb4750ef in 3-Feb 15:53:39.46 from 216.59.3.178
ipsec,debug,packet begin. in 3-Feb 15:53:39.46 from 216.59.3.178
ipsec,debug,packet seen nptype=10(nonce) in 3-Feb 15:53:39.47 from 216.59.3.178
ipsec,debug,packet seen nptype=20(nat-d) in 3-Feb 15:53:39.48 from 216.59.3.178
ipsec,debug,packet succeed. in 3-Feb 15:53:39.48 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:39.48 from 216.59.3.178
ipsec,debug Hashing 41.134.184.106[38876] with algo #2  in 3-Feb 15:53:39.49 from 216.59.3.178
ipsec,debug NAT detected: PEER in 3-Feb 15:53:39.50 from 216.59.3.178
ipsec,debug,packet compute DH's private. in 3-Feb 15:53:39.50 from 216.59.3.178
ipsec,debug,packet 5317d126 bae65935 53856922 05de514c 604ada0c 2494697f 0de90efb 3d67cb1f in 3-Feb 15:53:39.50 from 216.59.3.178
ipsec,debug,packet compute DH's public. in 3-Feb 15:53:39.51 from 216.59.3.178
ipsec,debug,packet b4c5839b 57a4c11a ef3b7725 f8c9c359 307e258b 11f18dde 5529bd37 b9ad1915 in 3-Feb 15:53:39.51 from 216.59.3.178
ipsec,debug,packet 9057bd74 19c5ec62 403d3e71 2327d677 4f2ee0a7 66192691 d3c25a75 84a467ee in 3-Feb 15:53:39.52 from 216.59.3.178
ipsec,debug,packet seen nptype=20(nat-d) in 3-Feb 15:53:39.52 from 216.59.3.178
ipsec,debug Hashing 216.59.3.178[500] with algo #2  in 3-Feb 15:53:39.52 from 216.59.3.178
ipsec,debug NAT-D payload #0 verified in 3-Feb 15:53:39.53 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:39.53 from 216.59.3.178
ipsec,debug NAT-D payload #1 doesn't match in 3-Feb 15:53:39.54 from 216.59.3.178
ipsec,debug,packet === in 3-Feb 15:53:39.54 from 216.59.3.178
ipsec,debug,packet 5d3a3b74 410337de d5269da2 a15c128c b12ad311 8ee8b639 de6898e9 16c4e347 in 3-Feb 15:53:39.55 from 216.59.3.178
ipsec,debug,packet 05156fc0 5383d9f8 49d387bc 97efc794 9f16365c 8246b44e cc9286f1 97df8af0 in 3-Feb 15:53:39.55 from 216.59.3.178
ipsec,debug,packet 30bf84a8 10d570aa 63549b31 4b246472 92102199 a0aa6e33 74dfc870 76600dff in 3-Feb 15:53:39.56 from 216.59.3.178
ipsec,debug,packet bba69b26 544e4ec4 15ca958a 194e4170 c52a9f17 dc29fb4f 6d73d509 589f4fd0 in 3-Feb 15:53:39.56 from 216.59.3.178
ipsec,debug,packet 428ac99e 1899c218 558a3ec7 994d7686 386345f2 1017b852 2ee2c3a6 da758bd9 in 3-Feb 15:53:39.57 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:39.57 from 216.59.3.178
ipsec,debug Hashing 216.59.3.178[500] with algo #2  in 3-Feb 15:53:39.58 from 216.59.3.178
ipsec,debug,packet add payload of len 128, next type 10 in 3-Feb 15:53:39.58 from 216.59.3.178
ipsec,debug,packet add payload of len 20, next type 20 in 3-Feb 15:53:39.58 from 216.59.3.178
ipsec,debug,packet 236 bytes from 216.59.3.178[500] to 41.134.184.106[38876] in 3-Feb 15:53:39.59 from 216.59.3.178
ipsec,debug,packet send packet from 216.59.3.178[500] in 3-Feb 15:53:39.59 from 216.59.3.178
ipsec,debug,packet dst4 41.134.184.106[38876] in 3-Feb 15:53:39.60 from 216.59.3.178
ipsec,debug,packet 1 times of 236 bytes message will be sent to 41.134.184.106[38876] in 3-Feb 15:53:39.60 from 216.59.3.178
ipsec,debug,packet add payload of len 24, next type 20 in 3-Feb 15:53:39.61 from 216.59.3.178
ipsec,debug,packet add payload of len 20, next type 0 in 3-Feb 15:53:39.61 from 216.59.3.178
ipsec,debug,packet sockname 216.59.3.178[500] in 3-Feb 15:53:39.62 from 216.59.3.178
ipsec,debug,packet send packet to 41.134.184.106[38876] in 3-Feb 15:53:39.62 from 216.59.3.178
ipsec,debug,packet src4 216.59.3.178[500] in 3-Feb 15:53:39.62 from 216.59.3.178
ipsec,debug,packet 2bb63aab a15704c2 aa2fbffb 09403970 04100200 00000000 000000ec 0a000084 in 3-Feb 15:53:39.63 from 216.59.3.178
ipsec,debug,packet 9057bd74 19c5ec62 403d3e71 2327d677 4f2ee0a7 66192691 d3c25a75 84a467ee in 3-Feb 15:53:39.63 from 216.59.3.178
ipsec,debug,packet 428ac99e 1899c218 558a3ec7 994d7686 386345f2 1017b852 2ee2c3a6 da758bd9 in 3-Feb 15:53:39.64 from 216.59.3.178
ipsec,debug,packet resend phase1 packet 2bb63aaba15704c2:aa2fbffb09403970 in 3-Feb 15:53:39.64 from 216.59.3.178
ipsec,debug,packet compute DH's shared. in 3-Feb 15:53:39.65 from 216.59.3.178
ipsec,debug,packet 57b6a232 48098166 431fb8d2 21317ff0 ed5555eb 34c43f3c 664d3b51 93ac9045 in 3-Feb 15:53:39.65 from 216.59.3.178
ipsec,debug,packet 0dbc85d7 b1069ae6 2c4cd1d8 12dafe06 074a3b14 7f8dddf1 4db20bc4 3f0e32dd in 3-Feb 15:53:39.65 from 216.59.3.178
ipsec,debug,packet nonce 1:  in 3-Feb 15:53:39.66 from 216.59.3.178
ipsec,debug,packet 2876c80c 78c412a7 8b5530f0 17e0677f e4f39884 ebc7953c 75d57984 d8f51570 in 3-Feb 15:53:39.66 from 216.59.3.178
ipsec,debug,packet nonce 2:  in 3-Feb 15:53:39.67 from 216.59.3.178
ipsec,debug,packet hmac(hmac_sha1) in 3-Feb 15:53:39.67 from 216.59.3.178
ipsec,debug,packet SKEYID computed: in 3-Feb 15:53:39.67 from 216.59.3.178
ipsec,debug,packet hmac(hmac_sha1) in 3-Feb 15:53:39.68 from 216.59.3.178
ipsec,debug,packet 9a36a634 e5eed69a 6139d9cd b3a4e124 6d4909e6 96ebcc7e 955c35b9 d31db0c9 in 3-Feb 15:53:39.68 from 216.59.3.178
ipsec,debug,packet the psk found. in 3-Feb 15:53:39.69 from 216.59.3.178
ipsec,debug,packet 490a9685 420a5283 35c7d3f3 381e00ab in 3-Feb 15:53:39.69 from 216.59.3.178
ipsec,debug,packet be8d42d6 2d6314d6 2e578098 c3043724 446ae4e8 6599b0ea in 3-Feb 15:53:39.70 from 216.59.3.178
ipsec,debug,packet 320dbd01 ca9ec2a4 59b4e4ae aa976c0d 30c126ff in 3-Feb 15:53:39.70 from 216.59.3.178
ipsec,debug,packet f0710146 62c1fe56 5c0015ac 91374772 f7590d57 in 3-Feb 15:53:39.71 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:39.71 from 216.59.3.178
ipsec,debug,packet hmac(hmac_sha1) in 3-Feb 15:53:39.72 from 216.59.3.178
ipsec,debug,packet 00 in 3-Feb 15:53:39.72 from 216.59.3.178
ipsec,debug,packet b42cd224 b40dd5cc 5ad3d152 7b083b83 4c4c8d2c in 3-Feb 15:53:39.73 from 216.59.3.178
ipsec,debug,packet b42cd224 b40dd5cc 5ad3d152 7b083b83 4c4c8d2c in 3-Feb 15:53:39.73 from 216.59.3.178
ipsec,debug,packet final encryption key computed: in 3-Feb 15:53:39.73 from 216.59.3.178
ipsec,debug,packet 04721d2e ace9d622 65a50695 b0fa26eb 86559dc5 in 3-Feb 15:53:39.74 from 216.59.3.178
ipsec,debug,packet SKEYID_d computed: in 3-Feb 15:53:39.74 from 216.59.3.178
ipsec,debug,packet hmac(hmac_sha1) in 3-Feb 15:53:39.75 from 216.59.3.178
ipsec,debug,packet hmac(hmac_sha1) in 3-Feb 15:53:39.75 from 216.59.3.178
ipsec,debug,packet SKEYID_e computed: in 3-Feb 15:53:39.75 from 216.59.3.178
ipsec,debug,packet encryption(3des) in 3-Feb 15:53:39.76 from 216.59.3.178
ipsec,debug,packet hash(sha1) in 3-Feb 15:53:39.76 from 216.59.3.178
ipsec,debug,packet IV computed: in 3-Feb 15:53:39.77 from 216.59.3.178
ipsec,debug,packet len(SKEYID_e) < len(Ka) (20 < 24), generating long key (Ka = K1 | K2 | ...) in 3-Feb 15:53:39.77 from 216.59.3.178
ipsec,debug,packet compute intermediate encryption key K1 in 3-Feb 15:53:39.78 from 216.59.3.178
ipsec,debug,packet hmac(hmac_sha1) in 3-Feb 15:53:39.78 from 216.59.3.178
ipsec,debug,packet compute intermediate encryption key K2 in 3-Feb 15:53:39.78 from 216.59.3.178
ipsec,debug,packet 45060ce3 626e7474 e9705e93 3789c3db 66707a0d in 3-Feb 15:53:39.79 from 216.59.3.178
ipsec,debug,packet b42cd224 b40dd5cc 5ad3d152 7b083b83 4c4c8d2c 45060ce3 in 3-Feb 15:53:39.80 from 216.59.3.178
ipsec,debug,packet encryption(3des) in 3-Feb 15:53:39.80 from 216.59.3.178
ipsec,debug,packet c253dc7f 16fd6a07 in 3-Feb 15:53:39.80 from 216.59.3.178
ipsec,debug,packet 68 bytes message received from 41.134.184.106[42876] to 216.59.3.178[4500] in 3-Feb 15:53:40.19 from 216.59.3.178
ipsec,debug,packet ========== in 3-Feb 15:53:40.19 from 216.59.3.178
ipsec,debug,packet 2bb63aab a15704c2 aa2fbffb 09403970 05100201 00000000 00000044 160a8472 in 3-Feb 15:53:40.19 from 216.59.3.178
ipsec,debug,packet ba9cb505 in 3-Feb 15:53:40.20 from 216.59.3.178
ipsec,debug NAT-T: ports changed to: 41.134.184.106[42876]<->216.59.3.178[4500] in 3-Feb 15:53:40.20 from 216.59.3.178
ipsec,debug,packet 9b6c15e7 75978331 377c8c81 ccaa07f5 d1a1fc26 20187481 e38a1a37 3f24469a in 3-Feb 15:53:40.21 from 216.59.3.178
ipsec,debug KA list add: 216.59.3.178[4500]->41.134.184.106[42876] in 3-Feb 15:53:40.21 from 216.59.3.178
ipsec,debug,packet IV was saved for next processing: in 3-Feb 15:53:40.22 from 216.59.3.178
ipsec,debug,packet 3f24469a ba9cb505 in 3-Feb 15:53:40.22 from 216.59.3.178
ipsec,debug,packet with key: in 3-Feb 15:53:40.23 from 216.59.3.178
ipsec,debug,packet decrypted payload by IV: in 3-Feb 15:53:40.23 from 216.59.3.178
ipsec,debug,packet encryption(3des) in 3-Feb 15:53:40.24 from 216.59.3.178
ipsec,debug,packet encryption(3des) in 3-Feb 15:53:40.24 from 216.59.3.178
ipsec,debug,packet b42cd224 b40dd5cc 5ad3d152 7b083b83 4c4c8d2c 45060ce3 in 3-Feb 15:53:40.25 from 216.59.3.178
ipsec,debug,packet c253dc7f 16fd6a07 in 3-Feb 15:53:40.25 from 216.59.3.178
ipsec,debug,packet 0800000c 01000000 0af020e8 00000018 cafc3889 4d6edfa4 a7de16cc 83f8dfc0 in 3-Feb 15:53:40.25 from 216.59.3.178
ipsec,debug,packet skip to trim padding. in 3-Feb 15:53:40.26 from 216.59.3.178
ipsec,debug,packet decrypted payload, but not trimed. in 3-Feb 15:53:40.26 from 216.59.3.178
ipsec,debug,packet 7256992c 00000000 in 3-Feb 15:53:40.26 from 216.59.3.178
ipsec,debug,packet padding len=1 in 3-Feb 15:53:40.27 from 216.59.3.178
ipsec,debug,packet 2bb63aab a15704c2 aa2fbffb 09403970 05100201 00000000 00000044 0800000c in 3-Feb 15:53:40.27 from 216.59.3.178
ipsec,debug,packet 01000000 0af020e8 00000018 cafc3889 4d6edfa4 a7de16cc 83f8dfc0 7256992c in 3-Feb 15:53:40.28 from 216.59.3.178
ipsec,debug,packet seen nptype=5(id) in 3-Feb 15:53:40.28 from 216.59.3.178
ipsec,debug,packet succeed. in 3-Feb 15:53:40.28 from 216.59.3.178
ipsec,debug,packet decrypted. in 3-Feb 15:53:40.29 from 216.59.3.178
ipsec,debug,packet 00000000 in 3-Feb 15:53:40.30 from 216.59.3.178
ipsec,debug,packet begin. in 3-Feb 15:53:40.30 from 216.59.3.178
ipsec,debug,packet seen nptype=8(hash) in 3-Feb 15:53:40.30 from 216.59.3.178
ipsec,debug,packet HASH received: in 3-Feb 15:53:40.31 from 216.59.3.178
ipsec,debug,packet HASH with: in 3-Feb 15:53:40.32 from 216.59.3.178
ipsec,debug,packet 956a28ea bc18df94 ee364d36 d4cb068f 5ed41899 a59735cd 968bd7a8 09fa3257 in 3-Feb 15:53:40.32 from 216.59.3.178
ipsec,debug,packet 68adb832 4c964d69 ebc3adc0 1b66bbf2 c316961d b6a82826 ceec43ef 607f3868 in 3-Feb 15:53:40.32 from 216.59.3.178
ipsec,debug,packet 9057bd74 19c5ec62 403d3e71 2327d677 4f2ee0a7 66192691 d3c25a75 84a467ee in 3-Feb 15:53:40.33 from 216.59.3.178
ipsec,debug,packet 428ac99e 1899c218 558a3ec7 994d7686 386345f2 1017b852 2ee2c3a6 da758bd9 in 3-Feb 15:53:40.33 from 216.59.3.178
ipsec,debug,packet cafc3889 4d6edfa4 a7de16cc 83f8dfc0 7256992c in 3-Feb 15:53:40.34 from 216.59.3.178
ipsec,debug,packet ed25e814 212e9364 fe25b17b 93e028bd f971a49f 7b874587 20987392 d1961654 in 3-Feb 15:53:40.35 from 216.59.3.178
ipsec,debug,packet 18bd1061 d8f45400 d261e43e 0b4e921f b9c66515 2989a206 7617b249 d02aae7d in 3-Feb 15:53:40.35 from 216.59.3.178
ipsec,debug,packet b4c5839b 57a4c11a ef3b7725 f8c9c359 307e258b 11f18dde 5529bd37 b9ad1915 in 3-Feb 15:53:40.35 from 216.59.3.178
ipsec,debug,packet bba69b26 544e4ec4 15ca958a 194e4170 c52a9f17 dc29fb4f 6d73d509 589f4fd0 in 3-Feb 15:53:40.36 from 216.59.3.178
ipsec,debug,packet 03000028 01010000 80010007 800e0100 80020002 80040014 80030001 800b0001 in 3-Feb 15:53:40.36 from 216.59.3.178
ipsec,debug,packet 000c0004 00007080 03000028 02010000 80010007 800e0080 80020002 80040013 in 3-Feb 15:53:40.37 from 216.59.3.178
ipsec,debug,packet 80010005 80020002 8004000e 80030001 800b0001 000c0004 00007080 00000024 in 3-Feb 15:53:40.37 from 216.59.3.178
ipsec,debug,packet 05010000 80010005 80020002 80040002 80030001 800b0001 000c0004 00007080 in 3-Feb 15:53:40.38 from 216.59.3.178
ipsec,debug,packet hmac(hmac_sha1) in 3-Feb 15:53:40.38 from 216.59.3.178
ipsec,debug,packet 80030001 800b0001 000c0004 00007080 03000028 03010000 80010007 800e0100 in 3-Feb 15:53:40.38 from 216.59.3.178
ipsec,debug,packet 80020002 8004000e 80030001 800b0001 000c0004 00007080 03000024 04010000 in 3-Feb 15:53:40.39 from 216.59.3.178
ipsec,debug,packet 01000000 0af020e8 in 3-Feb 15:53:40.40 from 216.59.3.178
ipsec,debug,packet cafc3889 4d6edfa4 a7de16cc 83f8dfc0 7256992c in 3-Feb 15:53:40.40 from 216.59.3.178
ipsec,debug,packet HASH for PSK validated. in 3-Feb 15:53:40.40 from 216.59.3.178
ipsec,debug,packet 01000000 0af020e8 in 3-Feb 15:53:40.41 from 216.59.3.178
ipsec,debug,packet use ID type of IPv4_address in 3-Feb 15:53:40.41 from 216.59.3.178
ipsec,debug,packet generate HASH_R in 3-Feb 15:53:40.42 from 216.59.3.178
ipsec,debug,packet b4c5839b 57a4c11a ef3b7725 f8c9c359 307e258b 11f18dde 5529bd37 b9ad1915 in 3-Feb 15:53:40.42 from 216.59.3.178
ipsec,debug,packet === in 3-Feb 15:53:40.43 from 216.59.3.178
ipsec,debug,packet HASH with: in 3-Feb 15:53:40.43 from 216.59.3.178
ipsec,debug,packet 9057bd74 19c5ec62 403d3e71 2327d677 4f2ee0a7 66192691 d3c25a75 84a467ee in 3-Feb 15:53:40.44 from 216.59.3.178
ipsec,debug,packet bba69b26 544e4ec4 15ca958a 194e4170 c52a9f17 dc29fb4f 6d73d509 589f4fd0 in 3-Feb 15:53:40.45 from 216.59.3.178
ipsec,debug,packet ed25e814 212e9364 fe25b17b 93e028bd f971a49f 7b874587 20987392 d1961654 in 3-Feb 15:53:40.45 from 216.59.3.178
ipsec,debug,packet 68adb832 4c964d69 ebc3adc0 1b66bbf2 c316961d b6a82826 ceec43ef 607f3868 in 3-Feb 15:53:40.45 from 216.59.3.178
ipsec,debug,packet aa2fbffb 09403970 2bb63aab a15704c2 00000001 00000001 000000c8 01010005 in 3-Feb 15:53:40.46 from 216.59.3.178
ipsec,debug,packet 000c0004 00007080 03000028 02010000 80010007 800e0080 80020002 80040013 in 3-Feb 15:53:40.46 from 216.59.3.178
ipsec,debug,packet 80020002 8004000e 80030001 800b0001 000c0004 00007080 03000024 04010000 in 3-Feb 15:53:40.47 from 216.59.3.178
ipsec,debug,packet 03000028 01010000 80010007 800e0100 80020002 80040014 80030001 800b0001 in 3-Feb 15:53:40.47 from 216.59.3.178
ipsec,debug,packet 80030001 800b0001 000c0004 00007080 03000028 03010000 80010007 800e0100 in 3-Feb 15:53:40.48 from 216.59.3.178
ipsec,debug,packet 80010005 80020002 8004000e 80030001 800b0001 000c0004 00007080 00000024 in 3-Feb 15:53:40.48 from 216.59.3.178
ipsec,debug,packet 05010000 80010005 80020002 80040002 80030001 800b0001 000c0004 00007080 in 3-Feb 15:53:40.48 from 216.59.3.178
ipsec,debug,packet 011101f4 d83b03b2 in 3-Feb 15:53:40.49 from 216.59.3.178
ipsec,debug,packet HASH computed: in 3-Feb 15:53:40.49 from 216.59.3.178
ipsec,debug,packet add payload of len 20, next type 0 in 3-Feb 15:53:40.50 from 216.59.3.178
ipsec,debug,packet 33e436a2 b9ecb003 in 3-Feb 15:53:40.50 from 216.59.3.178
ipsec,debug,packet pad length = 4 in 3-Feb 15:53:40.51 from 216.59.3.178
ipsec,debug,packet add payload of len 8, next type 8 in 3-Feb 15:53:40.51 from 216.59.3.178
ipsec,debug,packet encryption(3des) in 3-Feb 15:53:40.52 from 216.59.3.178
ipsec,debug,packet 0800000c 011101f4 d83b03b2 00000018 03528533 ec47fa60 231ce213 8022859e in 3-Feb 15:53:40.52 from 216.59.3.178
ipsec,debug,packet begin encryption. in 3-Feb 15:53:40.53 from 216.59.3.178
 
User avatar
thavinci
Member
Member
Posts: 335
Joined: Sat Aug 04, 2007 4:40 pm
Location: Johannessburg
Contact:

Re: NAT-T & IPSec Issues still exist

Tue Feb 07, 2012 8:35 am

I have re-sent the debugging info to mikrotik from a differant mail account, but still no response.

/me sends ping to mikrotik

PING mikrotikareyouthere (mikrotikareyouthere) 56(84) bytes of data.

^C
--- mikrotikareyouthere ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7005ms

Are you there?

:lol:
 
_saik0
Member Candidate
Member Candidate
Posts: 129
Joined: Sun Aug 26, 2007 11:18 pm

Re: NAT-T & IPSec Issues still exist

Sun Mar 04, 2012 5:46 pm

Hi,

Right now on ROS 5.14 and apparently l2tp+ipsec (preshared key) + client behind NAT doesn't work.
When the client isn't behind NAT everything goes smoothly...
Did anyone ever managed to get the above setup (client behind NAT) working??
 
piyokos
just joined
Posts: 9
Joined: Fri Mar 05, 2010 2:29 am

Re: NAT-T & IPSec Issues still exist

Sun Mar 04, 2012 11:16 pm

Are you there?

:lol:
it took mikrotik support a month and two days to respond to my inquiry over another l2tp/ipsec issue (ticket #2011112966000166) so dont expect a quick response.
 
2400baud
newbie
Posts: 29
Joined: Tue Nov 15, 2011 1:04 am

Re: NAT-T & IPSec Issues still exist

Tue Mar 06, 2012 4:44 pm

Hi,

Right now on ROS 5.14 and apparently l2tp+ipsec (preshared key) + client behind NAT doesn't work.
When the client isn't behind NAT everything goes smoothly...
Did anyone ever managed to get the above setup (client behind NAT) working??
I can confirm that L2TP+IPSEC+PSK+NAT-T+ ROS 5.14 works just fine for me from my laptop running MacOS 10.6.8.

I've been having some problems with a new Android 2.3 phone, but that appear to be a function of the carrier, and I haven't tried via wifi instead of 3g.

Note that for Windows XP and possibly other Windows versions, you have to configure the registry to allow NAT-T, then set up main-l2tp at the Mikrotik end.
 
publicreg
just joined
Posts: 3
Joined: Thu Feb 16, 2012 11:00 am

Re: NAT-T & IPSec Issues still exist

Wed Mar 07, 2012 5:04 pm

Hi,

Right now on ROS 5.14 and apparently l2tp+ipsec (preshared key) + client behind NAT doesn't work.
When the client isn't behind NAT everything goes smoothly...
Did anyone ever managed to get the above setup (client behind NAT) working??
I can confirm that L2TP+IPSEC+PSK+NAT-T+ ROS 5.14 works just fine for me from my laptop running MacOS 10.6.8.

I've been having some problems with a new Android 2.3 phone, but that appear to be a function of the carrier, and I haven't tried via wifi instead of 3g.

Note that for Windows XP and possibly other Windows versions, you have to configure the registry to allow NAT-T, then set up main-l2tp at the Mikrotik end.
Wow, good work guys, i can confirm L2TP/IPSec now working for me, from Windows 7 behind NAT and from Iphone behind NAT (ROS 5.14). I would later test connection from Android 2.3 phone.
 
_saik0
Member Candidate
Member Candidate
Posts: 129
Joined: Sun Aug 26, 2007 11:18 pm

Re: NAT-T & IPSec Issues still exist

Thu Mar 08, 2012 11:40 pm

I can also confirm that L2TP+IPSEC+PSK+NAT-T+ ROS 5.14 works with windows registry modification and main-l2tp peer setting.
What about certificates instead of PSK?
 
spyderspartan
just joined
Posts: 2
Joined: Sat Mar 10, 2012 4:45 am

Re: NAT-T & IPSec Issues still exist

Sat Mar 10, 2012 4:48 am

Could one of you post a config pls? I'm still having a problem with it. I'm getting an error "invalid length of payload"
 
a76
just joined
Posts: 8
Joined: Tue May 22, 2012 6:42 am

Re: NAT-T & IPSec Issues still exist

Wed Jul 25, 2012 8:07 am

No matter what I try I cannot get two users from behind the same NAT to connect to my LTP/IPSEC Mik even with NAT-T enabled. Firmware 5.19. Can anyone else confirm this?
 
gsloop
Member Candidate
Member Candidate
Posts: 213
Joined: Wed Jan 04, 2012 11:34 pm
Contact:

Re: NAT-T & IPSec Issues still exist

Fri Aug 10, 2012 10:34 pm

Somewhat uninformed speculation:

I think this is because you can't "Generate" unique policies - I could well be wrong - but I think that's the problem.
Not confirming, but I may well be testing it myself. I'll try to update if I find out something helpful/definitive.

It would be great if you'd update with anything you find.

-Greg

Who is online

Users browsing this forum: aTan, charliehun, GoogleOther [Bot], holvoetn, jaclaz, m3das, vaio73, vikashdh and 110 guests