[Openswan Users] oenswan 2.4.10 kernel 2.6.22 can only run behind firewall(natted).
Jennifer Agarwal
jsagarwal at exqss.com
Tue Mar 17 08:39:45 EDT 2009
Hi,
It is my understanding these kernel options are used by NETKEY and should be either
turned off or loaded as modules when using KLIPS.
Also it looks like the ip address of PC B (eth1) you have listed as 192.168.1.231 and
then in the ipsec.conf file for PC A you have the right=192.168.1.132. Could this be
causing your issues?
-Jennifer
Jennifer Agarwal
President / Principal Engineer
Exquisite Software Solutions, LLC
(240) 483-8619
jsagarwal at exqss.com=========================================================
> Hi all:
> openswan conflits with following kernel OPTIONS:# CONFIG_INET_AH is not set
> # CONFIG_INET_ESP is not set
> # CONFIG_INET_IPCOMP is not set
> # CONFIG_INET_XFRM_TUNNEL is not set
> when these options is disabled,everything is fine....
> 2009/3/16 <users-request at openswan.org>
> Send Users mailing list submissions to
> users at openswan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openswan.org/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
users-request at openswan.org
>
> You can reach the person managing the list at
> users-owner at openswan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Users digest..."
>
>
> Today's Topics:
>
> 1. multiple tunnels road-warriors/net-to-net and l2tp/non-l2tp
> (Bob Miller)
> 2. Re: multiple tunnels road-warriors/net-to-net and
> l2tp/non-l2tp (Paul Wouters)
> 3. oenswan 2.4.10 kernel 2.6.22 can only run behind
> firewall(natted). (Zhiping Liu)
>
>
> ----------------------------------------------------------------------
>
> Message: 3
> Date: Mon, 16 Mar 2009 15:31:27 +0800
> From: Zhiping Liu <flyingzpl at gmail.com>
> Subject: [Openswan Users] oenswan 2.4.10 kernel 2.6.22 can only run
> behind firewall(natted).
> To: users at openswan.org
> Message-ID:
> <92eb98380903160031s2b01e2eboa5355ce32f749a5 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi everyone:
> I have a strange problem,IPSEC SA can established,but can only forward
> package through NAT.
>
>
> 1.WITHOUT NAT NetWork topology: <javascript:void(0)>
>
> PC A:
> eth0:192.168.100.234
> eth1:192.168.1.234
> PC B:
> eth0:192.168.111.231
> eth1:192.168.1.231
>
> My pc(Windows XP,trying to access 192.168.111.231,set 192.168.100.234 as
> gateway):
> eth0:192.168.100.10
>
> 2.ipsec.conf (PC A)
> -bash-3.2$ cat /etc/ipsec.conf
> version 2.0 # conforms to second version of ipsec.conf specification
> config setup
> plutodebug = all
> klipsdebug = all
> nat_traversal=no
> interfaces = "ipsec0=eth1"
> include /etc/ipsec.d/examples/no_oe.conf
> conn aa
> type = tunnel
> auto = start
> keyexchange = ike
> authby = secret
> auth = esp
> esp = 3DES-SHA1
> ike = 3DES-SHA1-MODP1024
> aggrmode = yes
> pfs = yes
> pfsgroup = MODP1024
> left = 192.168.1.234
> leftsubnet = 192.168.100.0/255.255.255.0
> right = 192.168.1.132
> rightsubnet = 192.168.111.0/255.255.255.0
> leftid = @aaa
> rightid = @bbb
>
> 3.tcp dump result on PC A
>
> >From eth1,there is result from peer node,192.168.1.132:
>
> -bash-3.2$ sudo ./tcpdump -i eth1 host 192.168.1.132 -vv
> tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96
> bytes
> 14:16:32.753634 IP (tos 0x0, ttl 64, id 51990, offset 0, flags [none],
> proto
> ESP (50), length 112) 192.168.1.234 > 192.168.1.132:
> ESP(spi=0xa1015406,seq=0x2), length 92
> 14:16:52.764378 IP (tos 0x0, ttl 64, id 32957, offset 0, flags [none],
> proto
> ESP (50), length 112) 192.168.1.132 > 192.168.1.234:
> ESP(spi=0x1c703a00,seq=0x2), length 92
> 14:16:37.729272 arp who-has 192.168.1.132 tell 192.168.1.234
> 14:16:37.729482 arp reply 192.168.1.132 is-at 00:19:db:47:0c:60 (oui
> Unknown)
>
> 4 packets captured
> 4 packets received by filter
> 0 packets dropped by kernel
>
> But no result for ipsec0(192.168.100.10 is my IP)
> -bash-3.2$ sudo ./tcpdump -i ipsec0 -vv
> tcpdump: listening on ipsec0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 14:16:32.744483 IP (tos 0x0, ttl 127, id 31949, offset 0, flags [none],
> proto ICMP (1), length 60) 192.168.100.10 > 192.168.111.132: ICMP echo
> request, id 768, seq 35072, length 40
> 14:16:32.747816 IP (tos 0x0, ttl 64, id 7320, offset 0, flags [DF], proto
> UDP (17), length 74) 192.168.1.234.filenet-pa > 192.168.111.1.domain: [udp
> sum ok] 3304+ PTR? 132.111.168.192.in-addr.arpa. (46)
>
> 2 packets captured
> 13 packets received by filter
> 0 packets dropped by kernel
> -bash-3.2$
>
> 4.ipsec log file(can only see message send out)
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_tunnel_hard_header:
> skb->dev=ipsec0 dev=ipsec0.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_tunnel_hard_header:
> Revectored 0p00000000->0pdc883a24 len=84 type=2048 dev=ipsec0->eth1
> dev_addr=00:50:c2:1c:97:92 ip=c0a864ea->c0a86f01
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_strip_hard_header:
> >>>
> skb->len=98 hard_header_len:14 00:50:c2:1c:97:92:00:50:c2:1c:97:92:08:00
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:84
> id:0 DF frag_off:0 ttl:64 proto:1 (ICMP) chk:58732 saddr:192.168.100.234
> daddr:192.168.111.1 type:code=8:0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_strip_hard_header:
> Original head,tailroom: 2,28
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_findroute:
> 192.168.100.234:0->192.168.111.1:0 1
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: * See if we match
> exactly as a host destination
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: ** try to match a
> leaf,
> t=0pde630180
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_SAlookup: checking
> for
> local udp/500 IKE packet saddr=c0a864ea, er=0pde630180, daddr=c0a86f01,
> er_dst=c0a80184, proto=1 sport=0 dport=0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_sa_getbyid: linked entry
> in
> ipsec_sa table for hash=168 of
> SA:tun.1002 at 192.168.1.132 <SA%3Atun.1002 at 192.168.1.132><
> SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132>>requested.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle: found
> ipsec_sa -- SA:<IPIP> tun.1002 at 192.168.1.132
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle: calling
> room for <IPIP>, SA:tun.1002 at 192.168.1.132 <SA%3Atun.1002 at 192.168.1.132> <
> SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132>>
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> Required
> head,tailroom: 20,0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle: calling
> room for <ESP_3DES_HMAC_SHA1>,
> SA:esp.1867139c at 192.168.1.132 <SA%3Aesp.1867139c at 192.168.1.132><
> SA%3Aesp.1867139c at 192.168.1.132 <SA%253Aesp.1867139c at 192.168.1.132>>
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> Required
> head,tailroom: 16,16
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> existing
> head,tailroom: 2,28 before applying xforms with head,tailroom: 36,16 .
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> mtu:1500
> physmtu:1500 tothr:36 tottr:16 mtudiff:52 ippkttotlen:84
> Mar 16 12:49:32 SSLVPN kernel: klips_info:ipsec_xmit_encap_bundle: dev
> ipsec0 mtu of 1500 decreased by 57 to 1443
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> allocating 14 bytes for hardheader.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> head,tailroom: 16,28 after hard_header stripped.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:84
> id:0 DF frag_off:0 ttl:64 proto:1 (ICMP) chk:58732 saddr:192.168.100.234
> daddr:192.168.111.1 type:code=8:0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> head,tailroom: 68,104 after allocation
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:84
> id:0 DF frag_off:0 ttl:64 proto:1 (ICMP) chk:58732 saddr:192.168.100.234
> daddr:192.168.111.1 type:code=8:0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: calling
> output for <IPIP>, SA:tun.1002 at 192.168.1.132 <SA%3Atun.1002 at 192.168.1.132><
> SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132>>
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: pushing
> 20
> bytes, putting 0, proto 4.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once:
> head,tailroom: 48,104 before xform.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: after
> <IPIP>, SA:tun.1002 at 192.168.1.132 <SA%3Atun.1002 at 192.168.1.132> <
> SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132>>:
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:104 id:46843 frag_off:0 ttl:64 proto:4 chk:16088 saddr:192.168.1.234
> daddr:192.168.1.132
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:104 id:46843 frag_off:0 ttl:64 proto:4 chk:16088 saddr:192.168.1.234
> daddr:192.168.1.132
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: calling
> output for <ESP_3DES_HMAC_SHA1>,
> SA:esp.1867139c at 192.168.1.132 <SA%3Aesp.1867139c at 192.168.1.132><
> SA%3Aesp.1867139c at 192.168.1.132 <SA%253Aesp.1867139c at 192.168.1.132>>
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: pushing
> 16
> bytes, putting 16, proto 50.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once:
> head,tailroom: 32,88 before xform.
> Mar 16 12:49:32 SSLVPN kernel: klips_dmp: at pre-encrypt, len=136:
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @000: 45 00 00 88 b6 fb 00 00
> 40 32 3e d8 c0 a8 01 ea
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @010: c0 a8 01 84 18 67 13 9c
> 00 00 00 02 c0 a8 01 ea
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @020: c0 a8 01 84 45 00 00 54
> 00 00 40 00 40 01 e5 6c
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @030: c0 a8 64 ea c0 a8 6f 01
> 08 00 38 4f 3a 37 00 00
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @040: 0d 20 35 2d 00 00 00 00
> 00 00 00 00 00 00 00 00
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @050: 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @060: 00 00 00 00 00 00 00 10
> 00 00 00 00 00 00 00 00
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @070: 68 8d 0c 08 34 c7 99 bf
> 01 02 02 04 04 00 00 00
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: @080: 50 e5 74 64 64 ed 07 00
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: entering
> with encalg=3, ixt_e=df0c3bc0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: calling
> cbc_encrypt encalg=3 ips_key_e=d26c5400 idat=de5f6644 ilen=88 iv=de5f663c,
> encrypt=1
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: returned
> ret=1
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: after
> <ESP_3DES_HMAC_SHA1>,
> SA:esp.1867139c at 192.168.1.132 <SA%3Aesp.1867139c at 192.168.1.132><
> SA%3Aesp.1867139c at 192.168.1.132 <SA%253Aesp.1867139c at 192.168.1.132>>
> :
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:136 id:46843 frag_off:0 ttl:64 proto:50 (ESP) chk:16010
> saddr:192.168.1.234 daddr:192.168.1.132
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:136 id:46843 frag_off:0 ttl:64 proto:50 (ESP) chk:16010
> saddr:192.168.1.234 daddr:192.168.1.132
> Mar 16 12:49:32 SSLVPN kernel: klips_error:ipsec_sa_put: null pointer
> passed
> in!
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_findroute:
> 192.168.1.234:0
> ->192.168.1.132:0 50
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: * See if we match
> exactly as a host destination
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: ** try to match a
> leaf,
> t=0pde630180
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: *** start searching up
> the tree, t=0pde630180
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: **** t=0pde630198
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: **** t=0pdc8838c0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: ***** cp2=0pd5f31d68
> cp3=0pd8d998d0
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:rj_match: ***** not found.
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_restore_hard_header:
> After recursive xforms -- head,tailroom: 32,88
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_restore_hard_header:
> With hard_header, final head,tailroom: 18,88
> Mar 16 12:49:32 SSLVPN kernel: klips_debug:ipsec_xmit_send: ...done,
> calling
> ip_send() on device:eth1
> Mar 16 12:49:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:136 id:46843 frag_off:0 ttl:64 proto:50 (ESP) chk:16010
> saddr:192.168.1.234 daddr:192.168.1.132
>
>
> 5.WITH NAT NetWork topology: <javascript:void(0)>
> PC A
> eth0:192.168.100.234
> eth1:192.168.111.234
> Gateway: 192.168.111.1(udp port 500,4500 natted to PC A)
>
> Server B:
> ppp0--->pppoe
> eth1:192.168.80.1
>
> 6.ipsec.conf (PC A)
> version 2.0 # conforms to second version of ipsec.conf specification
> config setup
> plutodebug = all
> klipsdebug = all
> nat_traversal=yes
> interfaces = "%defaultroute"
> include /etc/ipsec.d/examples/no_oe.conf
> conn cylan
> type = tunnel
> auto = start
> keyexchange = ike
> authby = secret
> auth = esp
> esp = 3DES-SHA1
> ike = 3DES-SHA1-MODP1024
> aggrmode = yes
> pfs = yes
> pfsgroup = MODP1024
> left = %defaultroute
> leftsubnet = 192.168.100.0/255.255.255.0
> right = 219.133.245.113
> rightsubnet = 192.168.80.0/255.255.255.0
> leftid = @bbb
> rightid = @aaa
>
> 7.tcp dump result on PC A
> -bash-3.2$ sudo ./tcpdump -i eth1 host 219.133.245.113
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> 14:55:14.424375 IP 192.168.111.234.ipsec-nat-t >
> 113.245.133.219.broad.sz.gd.dynamic.163data.com.cn.ipsec-nat-t: UDP-encap:
> ESP(spi=0x4f6ec270,seq=0x2), length 92
> 14:55:23.105922 IP 192.168.111.234.ipsec-nat-t >
> 113.245.133.219.broad.sz.gd.dynamic.163data.com.cn.ipsec-nat-t: UDP-encap:
> ESP(spi=0x4f6ec270,seq=0x3), length 92
> 14:55:25.115728 IP 192.168.111.234.ipsec-nat-t >
> 113.245.133.219.broad.sz.gd.dynamic.163data.com.cn.ipsec-nat-t:
> isakmp-nat-keep-alive
> 14:55:25.117799 IP 192.168.111.234.ipsec-nat-t >
> 113.245.133.219.broad.sz.gd.dynamic.163data.com.cn.ipsec-nat-t:
> isakmp-nat-keep-alive
>
> 4 packets captured
> 4 packets received by filter
> 0 packets dropped by kernel
>
> ipsec0 got ICMP echo replys,it's ok
> -bash-3.2$ sudo ./tcpdump -i ipsec0 -vv
> tcpdump: listening on ipsec0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 14:56:34.183178 IP (tos 0x0, ttl 127, id 44881, offset 0, flags [none],
> proto ICMP (1), length 60) 192.168.100.10 > 192.168.80.1: ICMP echo
> request,
> id 768, seq 36352, length 40
> 14:56:34.207201 IP (tos 0x0, ttl 64, id 50421, offset 0, flags [none],
> proto
> ICMP (1), length 60) 192.168.80.1 > 192.168.100.10: ICMP echo reply, id
> 768,
> seq 36352, length 40
>
> 2 packets captured
> 2 packets received by filter
> 0 packets dropped by kernel
> -bash-3.2$
>
> 8.ipsec log file(with icmp result)
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_tunnel_neigh_setup:
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_tunnel_hard_header:
> skb->dev=ipsec0 dev=ipsec0.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_tunnel_hard_header:
> Revectored 0p00000000->0pd80e4a24 len=60 type=2048 dev=ipsec0->eth1
> dev_addr=00:50:c2:1c:97:92 ip=c0a8640a->c0a85001
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_strip_hard_header:
> >>>
> skb->len=74 hard_header_len:14 00:50:c2:1c:97:92:00:50:c2:1c:97:92:08:00
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:60
> id:48219 frag_off:0 ttl:127 proto:1 (ICMP) chk:18953 saddr:192.168.100.10
> daddr:192.168.80.1 type:code=8:0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_strip_hard_header:
> Original head,tailroom: 18,36
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_findroute:
> 192.168.100.10:0
> ->192.168.80.1:0 1
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: * See if we match
> exactly as a host destination
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: ** try to match a
> leaf,
> t=0pd85d0e40
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_SAlookup: checking
> for
> local udp/500 IKE packet saddr=c0a8640a, er=0pd85d0e40, daddr=c0a85001,
> er_dst=db85f571, proto=1 sport=0 dport=0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_sa_getbyid: linked entry
> in
> ipsec_sa table for hash=234 of
> SA:tun.1004 at 219.133.245.113 <SA%3Atun.1004 at 219.133.245.113><
> SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113>>requested.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle: found
> ipsec_sa -- SA:<IPIP> tun.1004 at 219.133.245.113
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle: calling
> room for <IPIP>, SA:tun.1004 at 219.133.245.113<SA%3Atun.1004 at 219.133.245.113><
> SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113>>
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> Required
> head,tailroom: 20,0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle: calling
> room for <ESP_3DES_HMAC_SHA1>,
> SA:esp.4f6ec270 at 219.133.245.113 <SA%3Aesp.4f6ec270 at 219.133.245.113><
> SA%3Aesp.4f6ec270 at 219.133.245.113 <SA%253Aesp.4f6ec270 at 219.133.245.113>>
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> Required
> head,tailroom: 16,24
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> existing
> head,tailroom: 18,36 before applying xforms with head,tailroom: 36,24 .
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> mtu:1500
> physmtu:1500 tothr:36 tottr:24 mtudiff:60 ippkttotlen:60
> Mar 16 15:10:32 SSLVPN kernel: klips_info:ipsec_xmit_encap_bundle: dev
> ipsec0 mtu of 1500 decreased by 65 to 1435
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> allocating 14 bytes for hardheader.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> head,tailroom: 32,36 after hard_header stripped.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:60
> id:48219 frag_off:0 ttl:127 proto:1 (ICMP) chk:18953 saddr:192.168.100.10
> daddr:192.168.80.1 type:code=8:0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_bundle:
> head,tailroom: 68,128 after allocation
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:60
> id:48219 frag_off:0 ttl:127 proto:1 (ICMP) chk:18953 saddr:192.168.100.10
> daddr:192.168.80.1 type:code=8:0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: calling
> output for <IPIP>, SA:tun.1004 at 219.133.245.113<SA%3Atun.1004 at 219.133.245.113>
> <SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113>>
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: pushing
> 20
> bytes, putting 0, proto 4.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once:
> head,tailroom: 48,128 before xform.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: after
> <IPIP>, SA:tun.1004 at 219.133.245.113 <SA%3Atun.1004 at 219.133.245.113> <
> SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113>>:
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:80
> id:43802 frag_off:0 ttl:64 proto:4 chk:52741 saddr:192.168.111.234
> daddr:219.133.245.113
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:80
> id:43802 frag_off:0 ttl:64 proto:4 chk:52741 saddr:192.168.111.234
> daddr:219.133.245.113
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: calling
> output for <ESP_3DES_HMAC_SHA1>,
> SA:esp.4f6ec270 at 219.133.245.113 <SA%3Aesp.4f6ec270 at 219.133.245.113><
> SA%3Aesp.4f6ec270 at 219.133.245.113 <SA%253Aesp.4f6ec270 at 219.133.245.113>>
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: pushing
> 16
> bytes, putting 16, proto 50.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once:
> head,tailroom: 32,112 before xform.
> Mar 16 15:10:32 SSLVPN kernel: klips_dmp: at pre-encrypt, len=112:
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: @000: 45 00 00 70 ab 1a 00 00
> 40 32 ce 05 c0 a8 6f ea
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: @010: db 85 f5 71 4f 6e c2 70
> 00 00 00 08 c0 a8 6f ea
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: @020: db 85 f5 71 45 00 00 3c
> bc 5b 00 00 7f 01 4a 09
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: @030: c0 a8 64 0a c0 a8 50 01
> 08 00 ba 5b 03 00 90 00
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: @040: 61 62 63 64 65 66 67 68
> 69 6a 6b 6c 6d 6e 6f 70
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: @050: 71 72 73 74 75 76 77 61
> 62 63 64 65 66 67 68 69
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: @060: 01 02 02 04 00 00 00 00
> 00 00 00 00 00 00 00 00
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: entering
> with encalg=3, ixt_e=df0c3bc0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: calling
> cbc_encrypt encalg=3 ips_key_e=de5f6800 idat=d1f03c44 ilen=64 iv=d1f03c3c,
> encrypt=1
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: returned
> ret=1
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_encap_once: after
> <ESP_3DES_HMAC_SHA1>,
> SA:esp.4f6ec270 at 219.133.245.113 <SA%3Aesp.4f6ec270 at 219.133.245.113><
> SA%3Aesp.4f6ec270 at 219.133.245.113 <SA%253Aesp.4f6ec270 at 219.133.245.113>>
> :
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:112 id:43802 frag_off:0 ttl:64 proto:50 (ESP) chk:52663
> saddr:192.168.111.234 daddr:219.133.245.113
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:112 id:43802 frag_off:0 ttl:64 proto:50 (ESP) chk:52663
> saddr:192.168.111.234 daddr:219.133.245.113
> Mar 16 15:10:32 SSLVPN kernel: klips_error:ipsec_sa_put: null pointer
> passed
> in!
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_findroute:
> 192.168.111.234:0->219.133.245.113:0 50
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: * See if we match
> exactly as a host destination
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: ** try to match a
> leaf,
> t=0pd85d0e40
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: *** start searching up
> the tree, t=0pd85d0e40
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: **** t=0pd85d0e58
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: **** t=0pd80e4f40
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: ***** cp2=0pd94d9aa8
> cp3=0pd8d99990
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:rj_match: ***** not found.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_restore_hard_header:
> After recursive xforms -- head,tailroom: 32,112
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_tunnel_start_xmit:
> encapsuling packet into UDP (NAT-Traversal) (2 8)
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_restore_hard_header:
> With hard_header, final head,tailroom: 18,104
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_xmit_send: ...done,
> calling
> ip_send() on device:eth1
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:120 id:43802 frag_off:0 ttl:64 proto:17 (UDP) chk:52688 saddr:
> 192.168.111.234:4500 daddr:219.133.245.113:4500
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:112 id:50426 frag_off:0 ttl:62 proto:50 (ESP) chk:46576
> saddr:219.133.245.113 daddr:192.168.111.234
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv_decap_once: decap (50)
> from 219.133.245.113 -> 192.168.111.234
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_sa_getbyid: linked entry
> in
> ipsec_sa table for hash=113 of
> SA:esp.a4cc5288 at 192.168.111.234 <SA%3Aesp.a4cc5288 at 192.168.111.234><
> SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234>
> >requested.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv:
> SA:esp.a4cc5288 at 192.168.111.234 <SA%3Aesp.a4cc5288 at 192.168.111.234> <
> SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234>>,
> src=219.133.245.113 of pkt agrees with expected SA source address policy.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv:
> SA:esp.a4cc5288 at 192.168.111.234 <SA%3Aesp.a4cc5288 at 192.168.111.234> <
> SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234>>
> First SA
> in group.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: natt_type=2
> tdbp->ips_natt_type=2 : ok
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: packet from
> 219.133.245.113 received with seq=8 (iv)=0x528c134e3bcb1e22 iplen=92
> esplen=80 sa=esp.a4cc5288 at 192.168.111.234
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: encalg = 3, authalg =
> 3.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: authentication
> successful.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: encalg=3 esphlen=16
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: entering
> with encalg=3, ixt_e=df0c3bc0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: calling
> cbc_encrypt encalg=3 ips_key_e=d88e4000 idat=d1f03c4c ilen=64 iv=d1f03c44,
> encrypt=0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_alg_esp_encrypt: returned
> ret=1
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: padlen=2, contents:
> 0x<offset>: 0x<value> 0x<value> ...
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: 00: 01 02
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: packet decrypted from
> 219.133.245.113: next_header = 4, padding = 2
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: trimming to 60.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: after
> <ESP_3DES_HMAC_SHA1>,
> SA:esp.a4cc5288 at 192.168.111.234 <SA%3Aesp.a4cc5288 at 192.168.111.234><
> SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234>>
> :
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:80
> id:50426 frag_off:0 ttl:62 proto:4 chk:46629 saddr:219.133.245.113
> daddr:192.168.111.234
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv:
> SA:esp.a4cc5288 at 192.168.111.234 <SA%3Aesp.a4cc5288 at 192.168.111.234> <
> SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234>>,
> Another
> IPSEC header to process.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: ESP SA sets
> skb->nfmark=0x170000.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: IPIP tunnel stripped.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug: IP: ihl:20 ver:4 tos:0
> tlen:60
> id:50425 frag_off:0 ttl:64 proto:1 (ICMP) chk:32875 saddr:192.168.80.1
> daddr:192.168.100.10 type:code=0:0
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: IPIP SA sets
> skb->nfmark=0x170000.
> Mar 16 15:10:32 SSLVPN kernel: klips_debug:ipsec_rcv: netif_rx() called.
>
>
> 9.udp.c manully patched...
> start line:1097
> if (ret < 0) {
> if(xfrm4_rcv_encap_func != NULL) {
> ret = (*xfrm4_rcv_encap_func)(skb, up->encap_type);
> UDP_INC_STATS_BH(UDP_MIB_INDATAGRAMS,up->pcflag);
> } else {
> UDP_INC_STATS_BH(UDP_MIB_INERRORS,up->pcflag);
> ret = 1;
> }
> return ret;
>
> }
>
>
_________________________________________________________________
Use Messenger to talk to your IM friends, even those on Yahoo!
http://ideas.live.com/programpage.aspx?versionId=7adb59de-a857-45ba-81cc-685ee3e858fe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090317/febb2cd8/attachment-0001.html
More information about the Users
mailing list