[Openswan Users] oenswan 2.4.10 kernel 2.6.22 can only run behind firewall(natted)

Zhiping Liu flyingzpl at gmail.com
Tue Mar 17 20:59:37 EDT 2009


Sorry.i input the wrong address,it should be 192.168.1.132
All NETKEY options were built in KERNEL mode,not MODULE mode,this might be
the cause.

2009/3/17 <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. VPN-Client over two changing ipadresses (Marc Hansen)
>   2. Re: oenswan 2.4.10 kernel 2.6.22 can only run     behind
>      firewall(natted). (Jennifer Agarwal)
>
>
> ----------------------------------------------------------------------
>
> Message: 2
> Date: Tue, 17 Mar 2009 08:39:45 -0400
> From: Jennifer Agarwal <jsagarwal at exqss.com>
> Subject: Re: [Openswan Users] oenswan 2.4.10 kernel 2.6.22 can only
>        run     behind firewall(natted).
> To: <users at openswan.org>
> Message-ID: <BLU131-W1059394EB5DF9218913549AF980 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> 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>><
> > SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132> <
> SA%253Atun.1002 at 192.168.1.132 <SA%25253Atun.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>> <
> > SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132> <
> SA%253Atun.1002 at 192.168.1.132 <SA%25253Atun.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>><
> > SA%3Aesp.1867139c at 192.168.1.132 <SA%253Aesp.1867139c at 192.168.1.132> <
> SA%253Aesp.1867139c at 192.168.1.132 <SA%25253Aesp.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>><
> > SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132> <
> SA%253Atun.1002 at 192.168.1.132 <SA%25253Atun.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>> <
> > SA%3Atun.1002 at 192.168.1.132 <SA%253Atun.1002 at 192.168.1.132> <
> SA%253Atun.1002 at 192.168.1.132 <SA%25253Atun.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>><
> > SA%3Aesp.1867139c at 192.168.1.132 <SA%253Aesp.1867139c at 192.168.1.132> <
> SA%253Aesp.1867139c at 192.168.1.132 <SA%25253Aesp.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>><
> > SA%3Aesp.1867139c at 192.168.1.132 <SA%253Aesp.1867139c at 192.168.1.132> <
> SA%253Aesp.1867139c at 192.168.1.132 <SA%25253Aesp.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>><
> > SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113> <
> SA%253Atun.1004 at 219.133.245.113 <SA%25253Atun.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>><
> > SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113> <
> SA%253Atun.1004 at 219.133.245.113 <SA%25253Atun.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>><
> > SA%3Aesp.4f6ec270 at 219.133.245.113 <SA%253Aesp.4f6ec270 at 219.133.245.113><
> SA%253Aesp.4f6ec270 at 219.133.245.113<SA%25253Aesp.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>>
> > <SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113> <
> SA%253Atun.1004 at 219.133.245.113 <SA%25253Atun.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>> <
> > SA%3Atun.1004 at 219.133.245.113 <SA%253Atun.1004 at 219.133.245.113> <
> SA%253Atun.1004 at 219.133.245.113 <SA%25253Atun.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>><
> > SA%3Aesp.4f6ec270 at 219.133.245.113 <SA%253Aesp.4f6ec270 at 219.133.245.113><
> SA%253Aesp.4f6ec270 at 219.133.245.113<SA%25253Aesp.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>><
> > SA%3Aesp.4f6ec270 at 219.133.245.113 <SA%253Aesp.4f6ec270 at 219.133.245.113><
> SA%253Aesp.4f6ec270 at 219.133.245.113<SA%25253Aesp.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>><
> > SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234><
> SA%253Aesp.a4cc5288 at 192.168.111.234<SA%25253Aesp.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>> <
> > SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234><
> SA%253Aesp.a4cc5288 at 192.168.111.234<SA%25253Aesp.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>> <
> > SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234><
> SA%253Aesp.a4cc5288 at 192.168.111.234<SA%25253Aesp.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>><
> > SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234><
> SA%253Aesp.a4cc5288 at 192.168.111.234<SA%25253Aesp.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>> <
> > SA%3Aesp.a4cc5288 at 192.168.111.234 <SA%253Aesp.a4cc5288 at 192.168.111.234><
> SA%253Aesp.a4cc5288 at 192.168.111.234<SA%25253Aesp.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.html
>
> ------------------------------
>
> _______________________________________________
> Users mailing list
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
>
>
> End of Users Digest, Vol 64, Issue 21
> *************************************
>



-- 
from Romeo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090318/68c44225/attachment-0001.html 


More information about the Users mailing list