[Openswan Users] Success with broadcast through GRE

[Michael Jurney]

Paul Wouters wrote:

> On Fri, 7 Oct 2005, Michael Jurney wrote:
>
>> Openswan at this point has not been started.  Tcpdump on an 
>> intermediate gateway shows GRE packets with private network packet 
>> payloads in the clear.
>>
>>> In other words, if the tunnel comes up, there is not going to be any 
>>> plaintext traffic for the range specified in the tunnel. 
>>
>>
>> Yes, but whether the openswan is started or not has no impact on the 
>> GRE configuration - When an ipsec SA is established between 
>> 10.1.1.100 and 10.2.2.100 ipsec encapsulation happens after GRE 
>> encapsulation.
>>
>> packet<->eth1<->tunnel0<->eth0(+ipsec)<->{routable 
>> network}<->(ipsec+)eth0<->tunnel0<->eth1<->packet
>
>
> How come prviate space IP addresses on both ends are visible *without* 
> the
> openswan tunnel? 

Because the GRE tunnel is between the routable IPs on each gateway, and 
each gateway has a static route to deliver traffic for the target 
network via the GRE device (tunnel0):

               
172.16.8.1(eth1)    (eth0)1.2.3.4==INTERNET==6.7.8.9(eth0)    
(eth1)172.16.32.1
                 (tunnel0)===========GRE============(tunnel0)
route: 172.16.32.0/24 dev tunnel0                   route: 172.16.8.0/24 
dev tunnel0

If I added a route on the left gateway for the network 100.101.200.0/24 
via the tunnel0 device, packets for that network would be encapsulated 
and delivered to the gateway on the right, which would then deliver or 
drop them.  In a traceroute it would look like one hop, no matter how 
many hops the GRE tunnel traverses.

> This is a gre tunnel within your own network? Usually,
> when ipsec tunnels are down, and they are connecting private space IP
> addresses, those hosts become unreachable.

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.

> In your case, you should add a firewall rule on ethX to block all
> traffic from the inside IP address in the 172. range, so that the GRE
> tunnel will not work without being protected by Openswan.


When traffic hits eth0 it's no longer in the 172.* range, it's GRE 
packets with a source of the public IP on the originating gateway and a 
destination of the public IP on the target gateway.  The right way to 
keep private network traffic from transiting in the clear is to drop all 
GRE (protocol 47) traffic exiting eth0 in the OUTPUT table.  If ipsec is 
up, the packets will be ESP when they hit this point, if it's not 
they'll still be GRE.

> As noted by others, i think you are doing ipsec over gre, instead of 
> gre over ipsec.


This might be true - What I'm doing is routing with GRE across a link 
that might or might not be protected by ipsec.  I'm not sure which term 
is most accurate, but in the full config GRE packets are being 
encapsulated by IPSEC, so the visible protocol in flight is ESP.  Is 
that gre over ipsec?  It seems like it would be gre through ipsec, at least.


-- 
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>