Closed GoogleCodeExporter closed 9 years ago
First of all, thank you for efforts. Unfortunately, none of us familiar with
IPSEC & OpenSwan.
Please provide your kernel config difference against our trunk. Did you modify
kernel code? Can you move on latest trunk revisions (r4667 & up)?
Messages "packet XXX has no Non-ESP marker" issued by Openswan, so problem
might be in NAT configuration itself. Please clarify "When router behind NAT" -
does it means that NAT running on some other host? If yes, it might be problem
in netfilter rules on it, take a look at:
http://www.archivum.info/users@openswan.org/2006-11/00336/%28Openswan-Users%29-P
acket-has-no-Non-ESP-marker.html
http://comments.gmane.org/gmane.network.openswan.user/16617
Original comment by lly.dev
on 8 Oct 2012 at 10:10
Thanks for your reply.
I used a Non-modified kernel code,which config is attached below.
As to "behind NAT" ,it means :
when the structure of network is like this:
subnet1 ---- WL-500GPv2 <----->MyFirewall(NAT)----- CentOs_IPsecVPN ---- subnet2
172.16.0.2 IP1 IP2 IP3 IP4 IP5 IP6 10.10.10.2
IP1: 172.16.0.1
IP2: 192.168.3.184
IP3: 192.168.3.1
IP4: public IPA
IP5: public IPB(xxx.xxx.xxx.xxx)
IP6: 10.10.10.1
Message "packet XXX has no Non-ESP marker" will turn up.But I replace
WL-500GPv2 with a Fedora14 PC which has been configured as a IPsec Gateway
,everything is OK.
By the way,the IPSec tunnel used pre-shared key.
The Links you mentioned, has a Similar situation indeed. It said "The problem
is a well known problem in kernel ipsec that is triggered when using
e1000 driver and ipsec. It has been corrected in 2.6.19 " . However,our kernel
has baesd on 2.6.22.
Original comment by cometjk3...@gmail.com
on 9 Oct 2012 at 7:54
Attachments:
About kernel config - for which purposes you turn on CONFIG_IP_PNP &
CONFIG_BLK_DEV_NBD ?
About "packet XXX has no Non-ESP marker" message - seems to be it is well known
problem for Double NAT configuration. But it splits to:
1) netfilter rules config (MTU problem)
2) kernel IKE frames fragmentation problem
Can you test various ping packet sizes? Best of all is to compare tcpdump
captured packets in case of WL-500GPv2(wrong) & Fedora14 PC(good?).
Again - can you move on latest trunk revisions (r4667 & up)?
Original comment by lly.dev
on 9 Oct 2012 at 12:18
CONFIG_IP_PNP & CONFIG_BLK_DEV_NBD is used for rootnfs ,I forget to turn
off.However,It doesn't work properly without that.
Based on the latest trunk revisions(r4672), I have tested pings with various
packet sizes from 1 to 1600 bytes.(MTU is always 1500.) But the result seems
similar.And I capture the output of tcpdump in Fedora 14 PC (It works well.)
Kernel config and tcpdump log is attached bellow.The ESP UDP packets length
looks different although the same size packets pings .wl500gpv2 is 120 while
fedora14 128,the difference is always multiple 8 bytes.
Original comment by cometjk3...@gmail.com
on 10 Oct 2012 at 8:18
Attachments:
Thanks for information, we will try find problem in our(Broadcom) ancient 2.6.22
Original comment by lly.dev
on 10 Oct 2012 at 5:34
try to switch bcm nat accelerator off
nvram set misc_fastnat_x=0 && nvram commit && reboot
Original comment by themiron.ru
on 11 Oct 2012 at 10:46
I switch bcm_nat off as you said,but problem remains.
Original comment by cometjk3...@gmail.com
on 12 Oct 2012 at 1:22
Please try xfrm backports 2.6.24 patch
http://wl500g.googlecode.com/files/xfrm.patch.gz against r4686
Original comment by lly.dev
on 21 Oct 2012 at 4:51
According to your suggestion,I'm getting the following error in pluto's logs:
/ # whack --initiate --name vpn_ipsec0_
002 "vpn_ipsec0_" #1: initiating Main Mode
104 "vpn_ipsec0_" #1: STATE_MAIN_I1: initiate
003 "vpn_ipsec0_" #1: ignoring unknown Vendor ID payload
[4f4568794c64414365636661]
003 "vpn_ipsec0_" #1: received Vendor ID payload [Dead Peer Detection]
003 "vpn_ipsec0_" #1: received Vendor ID payload [RFC 3947] method set to=115
002 "vpn_ipsec0_" #1: enabling possible NAT-traversal with method RFC 3947
(NAT-Traversal)
002 "vpn_ipsec0_" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "vpn_ipsec0_" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "vpn_ipsec0_" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike
(MacOS X): i am NATed
002 "vpn_ipsec0_" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "vpn_ipsec0_" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "vpn_ipsec0_" #1: received Vendor ID payload [CAN-IKEv2]
002 "vpn_ipsec0_" #1: Main mode peer ID is ID_IPV4_ADDR: 'xxx.xxx.xxx.xxx'
002 "vpn_ipsec0_" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
004 "vpn_ipsec0_" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
002 "vpn_ipsec0_" #1: Dead Peer Detection (RFC 3706): enabled
002 "vpn_ipsec0_" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using
isakmp#1 msgid:2c2b09c4 proposal=3DES(3)_192-MD5(1)_128
pfsgroup=OAKLEY_GROUP_MODP1024}
117 "vpn_ipsec0_" #2: STATE_QUICK_I1: initiate
003 "vpn_ipsec0_" #2: ERROR: netlink response for Add SA
esp.f829b00e@xxx.xxx.xxx.xxx included errno 22: Invalid argument
032 "vpn_ipsec0_" #2: STATE_QUICK_I1: internal error
003 "vpn_ipsec0_" #2: ERROR: netlink response for Add SA
esp.f829b00e@xxx.xxx.xxx.xxx included errno 22: Invalid argument
032 "vpn_ipsec0_" #2: STATE_QUICK_I1: internal error
Original comment by cometjk3...@gmail.com
on 22 Oct 2012 at 4:06
Thank you for test, I have to check it myself.
Original comment by lly.dev
on 22 Oct 2012 at 7:22
Sorry for late reply ,The truck code is correct.Problem is my openswan
transplantion.
When openswan 2.6.38 USE_NETKEY,in pluto/nat_traversal.c ,use eth0 as default
ethernet device.Howerver ,the router is vlan1.
Original comment by cometjk3...@gmail.com
on 9 Jan 2013 at 8:14
Thanks. So, problem with Non-ESP marker is inside vlan code.
Should we close the issue?
Original comment by lly.dev
on 9 Jan 2013 at 12:25
Yes,I change eth0 to vlan1 ,then It works well.
Thanks again for all your help.
Original comment by cometjk3...@gmail.com
on 9 Jan 2013 at 12:48
Original comment by themiron.ru
on 27 Apr 2013 at 8:14
Original issue reported on code.google.com by
cometjk3...@gmail.com
on 8 Oct 2012 at 6:10