[Openswan Users] Testing Host to Host
Greg Lamb
greg at linuxbin.com
Mon May 30 12:23:50 CEST 2005
You are correct, that is what passthrough indicates... however (now
correct me if I am wrong) I have `type=tunnel` which means this is an
encrypted tunnel and if this tunnel should fail... "failureshunt" means
that it should begin passthrough as backup in the event encryption is
not possible.
Fabien Tivolle wrote:
>
> If you want to have your data encrypted all the time you should remove
> this line:
> failureshunt=passthrough
> "passthrough" here means the data will be in the tunnel but not
> encrypted, not what you want I guess.
>
> From ref:
> http://www.freeswan.nl/freeswan_trees/freeswan-2.00-rc1/doc/manpage.d/ipsec.conf.5.html
>
>
> *type*
> the type of the connection; currently the accepted values are
> *tunnel* (the default) signifying a host-to-host, host-to-subnet, or
> subnet-to-subnet tunnel; *transport*, signifying host-to-host
> transport mode; *passthrough*, signifying that no IPsec processing
> should be done at all; *drop*, signifying that packets should be
> discarded; and *reject*, signifying that packets should be discarded
> and a diagnostic ICMP returned
>
>
> Fabien
>
>
> Greg Lamb wrote:
>
>> I'm trying to get a host-to-host vpn up and running between two
>> servers... and it *appears* to be working however I've been doing
>> some testing with tcpdump to make sure it's actually encrypting the
>> data...
>>
>> from server-b running `ping -p feedfacedeadbeef server-a`
>> i see on server-a with `tcpdump -i eth0 host server-b -x`
>>
>> 21:03:31.582575 IP server-a > server-b: ESP(spi=0x651bd3dd,seq=0x24)
>> 0x0000: 4500 0098 7805 0000 4032 35da 4655 1fc2
>> E...x... at 25.FU <mailto:E...x... at 25.FU>..
>> 0x0010: 4655 1fe9 651b d3dd 0000 0024 c029 364e
>> FU..e......$.)6N
>> 0x0020: cbaa 4234 8db2 0577 10a9 bb8b 905d 2de9
>> ..B4...w.....]-.
>> 0x0030: 57b4 242a 43af 1526 cab9 4e1b 8c2c e71b
>> W.$*C..&..N..,..
>> 0x0040: a2a2 aa06 fcbc 23b6 0cf0 8667 6d52 a3f6
>> ......#....gmR..
>> 0x0050: 5247 RG
>> 21:03:32.601102 IP server-b > server-a: ESP(spi=0x4172ce43,seq=0x25)
>> 0x0000: 4500 0098 706c 4000 3f32 fe72 4655 1fe9
>> E...pl at .?2.rFU..
>> 0x0010: 4655 1fc2 4172 ce43 0000 0025 7a98 2d71
>> FU..Ar.C...%z.-q
>> 0x0020: d333 006c 3203 a471 043a 9320 4e63 0b2b
>> .3.l2..q.:..Nc.+
>> 0x0030: 578f b2f4 4c73 cdae 0a31 84ec 7c40 f300
>> W...Ls...1..|@..
>> 0x0040: 1a7d 037b 6880 00a0 21ed 7b3d 6a0a 6d73
>> .}.{h...!.{=j.ms
>> 0x0050: e4ce ..
>> 21:03:32.601102 IP server-b > server-a: icmp 64: echo request seq 56
>> 0x0000: 4500 0054 0038 4000 4001 6e1c 4655 1fe9
>> E..T.8 at .@.n.FU..
>> 0x0010: 4655 1fc2 0800 8120 5006 0038 e414 9942
>> FU......P..8...B
>> 0x0020: 142a 0900 feed face dead beef feed face
>> .*..............
>> 0x0030: dead beef feed face dead beef feed face
>> ................
>> 0x0040: dead beef feed face dead beef feed face
>> ................
>> 0x0050: dead ..
>>
>> Now I've read that if you see the ESP packets... your set... however
>> I'm also seeing the clear text packets... Just want to make sure, is
>> this only because this is a host-to-host tunnel and I'm seeing it
>> also decrypting the packets since I'm on one of the endpoints?
>> Unfortunately in this set up I do have have an ability to get onto
>> these machine's gateways and monitor the packets from there...
>>
>> What I'm concerned about is whether it could be circumventing the
>> tunnel? Thank you!
>>
>> From ipsec.conf...
>>
>> conn servera-to-serverb
>> left=publicipofservera
>> leftid=@servera
>> leftrsasigkey=keyblahblah
>> leftnexthop=serveradefaultgateway failureshunt=passthrough
>> right=publicipofserverb
>> rightid=@serverb
>> rightrsasigkey=keyblahblah
>> rightnexthop=serverbdefaultgateway failureshunt=passthrough
>> auto=start
>> rekey=no
>> failureshunt=passthrough
>> pfs=no
>> compress=no
>> authby=rsasig
>> type=tunnel
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openswan.org
>> http://lists.openswan.org/mailman/listinfo/users
>>
>>
>
More information about the Users
mailing list