Re: [Users] Same twisted question for 10 days

From: Mathieu Bonnet <bonnet(at)sdl.hitachi.co.jp>
Date: Thu May 22 2003 - 01:06:52 EDT

Hello Sam

Thanks for you hints.
As I said in my previous message, the tunnel seems to simply ignore the router.
I tried tcpdump -e as you advised me to see what happend to the ESP packets, but the only thing I've found out is what I already knew: The packets try to use a direct route (from the mac address of A to the mac address of C), and are dopped by the filter on ip tables.

I tried replacing the entries in the routing table manually, but it doesn't change anything. I presume it would be the same if I change the _updown script, or there is something I don't know... In brief, I still don't know what is going on ^_^'

Maybe there is a problem with the tunnel itself, but as I am not an ipsec expert, I don't know what it can be.
Here is the "ipsec look" and the "ipsec auto --status" for the tunnel, from the A machine.

localhost.localdomain Thu May 22 13:49:17 JST 2003 A/32 -> C/32 => tun0x1002@C esp0xcccb3d66@C (12) ipsec0->eth1 mtu=16260(1443)->1500
esp0x7c4a7278@A ESP_3DES_HMAC_MD5: dir=in src=C iv_bits=64bits iv=0x2afa5f69e9f456a0 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(1628,0,0)
esp0xcccb3d66@C ESP_3DES_HMAC_MD5: dir=out src=A iv_bits=64bits iv=0x461805d15f64ed18 ooowin=64 seq=6 alen=128 aklen=128 eklen=192 life(c,s,h)=bytes(816,0,0)addtime(1628,0,0)usetime(849,0,0)packets(6,0,0) idle=844
tun0x1001@A IPIP: dir=in src=C life(c,s,h)=addtime(1628,0,0) tun0x1002@C IPIP: dir=out src=A
life(c,s,h)=bytes(624,0,0)addtime(1628,0,0)usetime(849,0,0)packets(6,0,0) idle=844
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.25.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.25.0 0.0.0.0 255.255.255.0 U 40 0 0 ipsec0
B 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
C B 255.255.255.255 UGH 40 0 0 ipsec0

000 interface ipsec0/eth1 A
000
000 "ac": A---B...B---C
000 "ac": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "ac": policy: RSASIG+ENCRYPT+TUNNEL+DISABLEARRIVALCHECK; interface: eth1; erouted
000 "ac": newest ISAKMP SA: #1; newest IPsec SA: #2; eroute owner: #2 000
000 #2: "ac" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27996s; newest IPSEC; eroute owner 000 #2: "ac" esp.cccb3d66@C esp.7c4a7278@A tun.1002@C tun.1001@A 000 #1: "ac" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2692s; newest ISAKMP
000

I replaced IP addresses by their given letters to simplify. Here next is the tcpdump -e during the negociation. I show only the ISAKMP messages, and some "Unknown IPX data" messages that drawed my attention.

11:55:41.253790 macA macB ip 218: A.isakmp > C.isakmp: isakmp: phase 1 I
ident: [|sa] (DF)
11:55:41.253858 macB macC ip 246: B > A: icmp: redirect C to host C [tos

0xc0]
11:55:41.254336 macA macC ip 218: A.isakmp > C.isakmp: isakmp: phase 1 I ident: [|sa] (DF)
...

11:55:42.754665 macC macB ip 122: C.isakmp > A.isakmp: isakmp: phase 1 R
ident: [|sa] (DF)
11:55:42.754730 macB macC ip 150: B > C: icmp: redirect A to host A [tos

0xc0]
11:55:42.755134 macC macA ip 122: C.isakmp > A.isakmp: isakmp: phase 1 R ident: [|sa] (DF)
...

11:55:43.276838 macA macB ip 286: A.isakmp > C.isakmp: isakmp: phase 1 I
ident: [|ke] (DF)
11:55:43.276932 macB macA ip 314: B > A: icmp: redirect C to host C [tos

0xc0]
11:55:43.277467 macB macC ip 286: A.isakmp > C.isakmp: isakmp: phase 1 I ident: [|ke] (DF)
...

11:55:45.177508 macC macB ip 286: C.isakmp > A.isakmp: isakmp: phase 1 R
ident: [|ke] (DF)
11:55:45.177570 macB macC ip 314: B > C: icmp: redirect A to host A [tos

0xc0]
11:55:45.178084 macB macA ip 286: C.isakmp > A.isakmp: isakmp: phase 1 R ident: [|ke] (DF)
...
11:55:45.774039 macA macB ip 366: A.isakmp > C.isakmp: isakmp: phase 1 I ident[E]: [|id] (DF)
11:55:45.774126 macB macA ip 394: B > A: icmp: redirect C to host C [tos 0xc0]
11:55:45.774721 macB macC ip 366: A.isakmp > C.isakmp: isakmp: phase 1 I ident[E]: [|id] (DF)
...
11:55:48.220116 macC macB ip 366: C.isakmp > A.isakmp: isakmp: phase 1 R ident[E]: [|id] (DF)
11:55:48.220165 macB macC ip 394: B > C: icmp: redirect A to host A [tos 0xc0]
11:55:48.220739 macB macA ip 366: C.isakmp > A.isakmp: isakmp: phase 1 R ident[E]: [|id] (DF)
...
11:55:48.717583 macA macB ip 182: A.isakmp > C.isakmp: isakmp: phase 2/others I oakley-quick[E]: [|hash] (DF) 11:55:48.717659 macB macA ip 210: B > A: icmp: redirect C to host C [tos 0xc0]
11:55:48.718115 macB macC ip 182: A.isakmp > C.isakmp: isakmp: phase 2/others I oakley-quick[E]: [|hash] (DF) ...
11:55:51.239383 macC macB ip 158: C.isakmp > A.isakmp: isakmp: phase 2/others R oakley-quick[E]: [|hash] (DF) 11:55:51.239456 macB macC ip 186: B > C: icmp: redirect A to host A [tos 0xc0]
11:55:51.239890 macB macA ip 158: C.isakmp > A.isakmp: isakmp: phase 2/others R oakley-quick[E]: [|hash] (DF) ...
11:55:51.912079 macA macB ip 94: A.isakmp > C.isakmp: isakmp: phase 2/others I oakley-quick[E]: [|hash] (DF)
11:55:51.912131 macB macA ip 122: B > A: icmp: redirect C to host C [tos 0xc0]
11:55:51.912549 macB macC ip 94: A.isakmp > C.isakmp: isakmp: phase 2/others I oakley-quick[E]: [|hash] (DF)
...
11:55:54.754029 macB macC 002e 60: sap d6 > sap d2 ui/C
>>> Unknown IPX Data: (43 bytes)

[000] 60 CE BC 72 D8 4A A3 4F C3 78 16 C5 87 DD 87 EA `..r.J.O .x......
[010] 6D F8 C0 B5 68 65 1D 96 02 DF 0F 09 16 09 B9 42 m...he.. .......B
[020] 8C E8 C8 25 C7 65 58 D7 EE 1B 3C ...%.eX. ..<

len=43
...
11:56:01.455038 macB macC 00fa 264: sap 0a > sap b0 ui/C
>>> Unknown IPX Data: (79 bytes)

[000] 55 A0 35 61 F8 AA 32 01 9D BE 76 91 6C 59 F8 F4 U.5a..2. ..v.lY..
[010] 07 CC 21 4C 26 F9 35 42 40 09 A0 98 90 F8 49 F2 ..!L&.5B @.....I.
[020] 76 DB 9D AD 93 B9 76 7B 3A 46 00 A5 96 BD FF 54 v.....v{ :F.....T
[030] C8 3B 21 0E 4D 4E E9 98 9C E3 F5 1F 9C 9C 5A E2 .;!.MN.. ......Z.
[040] 01 92 D4 44 D4 0F 33 D8 16 88 33 2A BD 63 54 ...D..3. ..3*.cT

len=247
...
11:56:01.660663 macB macA 0058 102: sap ae > sap ca ui/C
>>> Unknown IPX Data: (79 bytes)

[000] F3 D6 87 C5 C4 99 33 46 93 10 19 7B 73 7C CD C8 ......3F ...{s|..
[010] 0F A2 83 40 69 6D 54 C8 69 4B 37 D6 9E 08 00 90 ...@imT. iK7.....
[020] 66 2A 74 1F 02 DC 74 25 6A 3C C3 E5 5C 5D FE B6 f*t...t% j<..\]..
[030] B0 6A D8 91 E1 A7 A3 13 03 10 C8 D0 26 8D 5A 2E .j...... ....&.Z.
[040] 54 D6 55 61 7F D3 7F 49 59 C2 5D 16 2D 7F 5E T.Ua...I Y.].-.^

len=85

As you can see, except for the 3 last messages, everything seems ok. Then after the tunnel is not working.
Any Clue?

Mathieu Bonnet

• Original Message ----- From: "Sam Sgro" <sam@freeswan.org> To: "Mathieu Bonnet" <bonnet@sdl.hitachi.co.jp> Cc: <users@lists.freeswan.org> Sent: Wednesday, May 21, 2003 7:57 AM Subject: Re: [Users] Same twisted question for 10 days

> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> On Mon, 19 May 2003, Mathieu Bonnet wrote:
>
> > IPSec route generated by "ipsec auto --up ac" has the metric 0 as if the
SA
> > was attempting to establish direct connection (and the previous route
with
> > metric 2 disappears). Why? Is it possible to have somthing else or to
avoid
> > this problem?
>
> The route generated upon "ipsec auto --up" is created by the _updown
script.
> You can modify the route command there and customize it as you need to.
>
> What might help is the use of tcpdump, printing the link-level headers so
you
> can have a clear picture who is trying to speak with whom, as well as the
> routing table before and after.
>
> - --
> Sam Sgro
> sam@freeswan.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: noconv
> Comment: For the matching public key, finger the Reply-To: address.
>
> iQCVAwUBPsqyvkOSC4btEQUtAQE4PAQAqqmEfmPF80Y2+zKDzdyvfpr+S2c4E6kn
> jq3vnVey/GZMdHjWtUSRAWWjipYW+9lTZVs7KGQt3b8yICARtGzHDZYOF4A5mgmO
> JSOsEpkKoLuub1EGjvOvd68hdzlPZQUmJFcz5fn43Vy9pmlliLEtUUe4URVQjpmg
> Q+CSPbAWPQc=
> =H9HD
> -----END PGP SIGNATURE-----
>

---

Users mailing list
Users@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users Received on Tue Jun 24 17:47:36 2003