As mentioned in another post to this list recently I use IPv6 to secure
my tunnels when roaming to get pre-allocated IPv6 on my laptop..
Look for 'totd' in the subject and I think you'll see some useful examples.
Thanks,
--
Todd Fries .. t...@fries.net
_
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| "..in support of free software solutions." \ 250797 (FWD)
| \
\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
Penned by Brian A. Seklecki on 20081224 16:23.55, we have:
> All:
>
> Back in 01/2006, circa 3.8, there was a thread related to the use of
> gre(4) and Transport Mode ipsec(4) in isakmpd(8) to protect v4 tunnels.
>
> There was a repeatable kernel panic related to gre(4) packets needing a
> smaller MTU as they are encapsualted in ipsec(4) packets, before being
> transmited.
>
> I haven't looked if we have support, but gre(4) w/ ipv6 address and
> stf(4) seem to be best options out there for secure v6 tunnels.
>
> That is, explicitly, gre(4) inside ipv6, since we dont' have stf(4).
>
> I can revisit that bug in our lab, except with a slightly larger
> encapsulation packet overhead :)
>
> I'm wondering if a tranditional ipv6 isakmp(8) ipsec tunnel (using IPv4
> enpoints?!) is a safe alternative, or what other solutions people are
> cooking up on OpenBSD for tunneling IPv6 security.
>
> Thanks for your feedback and safe holidays to all!
>
> ~BAS
>
> On Mon, 9 Jan 2006, Jason Taylor wrote:
>
>> Hi Brian,
>>
>> I did a few more tests this evening and I think you are right about the
>> MTU issue. In OpenBSD 3.8, you can set the MTU of a GRE interface. I
>> set the mtu of the GRE tunnel on one end (Perspex, which runs 3.8) and
>> transferred a large file. It worked wonderfully and I am now in the
>> process of updating my soekri to the latest 3.8. I think what is
>> happening is the GRE tunnel sets its MTU according to the MTU of the
>> physical interface, in my case fxp0 and sis0 and does not take into
>> account the added overhead of IPsec...
>>
>>
>> Cheers,
>>
>> /Jason
>>
>> On Jan 9, 2006, at 4:41 PM, Brian A. Seklecki wrote:
>>
>>>
But as soon as I start an scp from Perspex to Soekris, Perspex reboots
after a few hundred kb. Unfortunately, Perspex is in a datacenter and I
do not have console access to it to see what the heck is happening at that
exact moment.
>>>
>>> I don't recall. But for the record (IPSEC inside GRE):
>>>
>>> If the Transport IPSEC connection is negotiated between two hosts
>>> inside the GRE tunnel private subnet and the IPSEC connection goes
>>> down, the data flows in cleartext. *bad*
>>>
>>> The opposite would be (GRE-inside-IPSEC-Transport):
>>>
>>> If the Transport IPSEC tunnel is built between the two hosts` public
>>> interfaces and the GRE tunnel is built normally and thus encrypted,
>>> things should work. Of course, we run into the crash.
>>>
>>> The trick was I tried it on OpenBSD/Sparc where there is
>>> no-such-thing as "Flash back to the BIOS" and it turns out a Sun
>>> "watchdog timer" is getting hit. Watchdog timers on i386 must cause
>>> the BIOS to reset. So the problem is in-kernel and the config is
>>> probably too obscure for developers to spend time on.
>>>
>>> My solution was to re-IP my network properly, and use IP Supernets/
>>> summarization/ subnet aggregation thus consolidating the need for so
>>> many spokes on a hub-and-spoke VPN config.
>>>
>>> ~~BAS
>>>
I noticed that there were no responses to your thread, but I was wondering
if you had worked out your problem or if you decided to go the ipsec
encapsulated in gre.
Cheers,
/Jason
--
Jason Taylor
e: j...@jtaylor.ca
m: 514-815-8204
>>>
>>> l8*
>>> -lava
>>>
>>> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
>>
>
> l8*
> -lava (Brian A. Seklecki - Pittsburgh, PA, USA)
> http://www.spiritual-machines.org/
>
> "Show me a young conservative and I'll show you someone with no heart.
> Show me an old liberal and I'll show you someone with no brains."
> ~ Winston Churchill
