[Openswan Users] Success with broadcast through GRE

[Michael Jurney]

Paul Wouters wrote:

>> The ipsec tunnel isn't connecting private IP space - It's connecting 
>> 1.2.3.4 and 6.7.8.9.  That's why encryption and transit are 
>> independent in this configuration.  If GRE is up, the networks can 
>> see each other.  If ipsec is up, all traffic between the two gateways 
>> is encrypted.  Either can function without the other.
>
>
> You are breaking the inbuilt security of ipsec. IPsec was designed to NOT
> leak out clear text packets when for some reason, encryption would fail.
> How do you describe the security of your link now anyway? Is it save for
> windows users to logon? Is FTP/pop safe? Your answer now seems to me 
> "most
> of the time", which from a security point of view means it only takes
> time before security is compromised.


There's an operational requirement here that gives me no option:  I need 
to be able to get broadcast packets between networks; Ipsec will not 
propogate these packets; GRE will.

As it happens, GRE for tunneling and ipsec for encryption precisely fits 
my operational constraints.  It also explicitly decouples transit and 
encryption, so that someone can choose to prioritize connectivity over 
security.  For my network leaking information isn't acceptable, so both 
gateways are configured to drop GRE packets on eth0 bound for the 
other.  If encryption fails in this configuration connectivity is broken 
as well, so it meets the same operational criteria as a net-to-net ipsec 
tunnel.  If some other sysadmin considers it more important to keep the 
offices connected than it is to protect the data in transit, then that's 
easy to do.  My network's profile is the same as with pure ipsec.

-- 
Michael D. Jurney
Sysadmin, DataSynapse
mikej at datasynapse.com
p: 212.842.8860

View the DataSynapse email disclaimer here:
<http://www.datasynapse.com/legal/emailprivacy.jsp>