[Openswan Users] Success with broadcast through GRE

[Michael Jurney]

Paul Wouters wrote:

> On Fri, 7 Oct 2005, Michael Jurney wrote:
>
> If using GRE you should not have specified any right/left subnet, 
> since that
> now excludes the host-host communication. If you added a leftsourceip= 
> and
> rightsourceip= you would solve this, but you should just remove the 
> subnet=
> lines for your GRE setup.

Thanks - This is a nice thing to have been able to clean out of the config.

>>
>> The new configuration:
>> ------------------------------------------------------------------------- 
>>
>>
>> Create a pair of GRE tunnels between the two gateways and route 
>> private network traffic over them:
>>
>> On openswan1:
>>
>> Create the tunnel:
>>   ip tunnel add tunnel0 mode gre local 10.1.1.100 remote 10.2.2.100
>> Bring the tunnel up:
>>   ip link set tunnel0 up
>> Give the tunnel an address:
>>   ip addr add 10.1.1.100 dev tunnel0
>> Make sure rp_filtering on the interface is off, or broadcasts won't 
>> traverse it:
>>   echo 0 > /proc/sys/net/ipv4/conf/tunnel0/rp_filter
>> Route the target network through the tunnel:
>>   ip route add 172.16.32.0/24 dev tunnel0
>>
>> On openswan2 (The same procedure, just reversing IPs and network 
>> routes):
>>
>> ip tunnel add tunnel0 mode gre local 10.2.2.100 remote 10.1.1.100
>> ip link set tunnel0 up
>> ip addr add 10.2.2.100 dev tunnel0
>> echo 0 > /proc/sys/net/ipv4/conf/tunnel0/rp_filter
>> ip route add 172.16.8.0/24 dev tunnel0
>>
>> At this point, traffic (including broadcast packets) pass between the 
>> networks with no problems, but it will NOT be encrypted!
>
>
> This is not correct. See my above statement.
> Also, you are tcpdupming in NETKEY which will only encrypt the
> traffic after tcpdump has "seen" the traffic. 

On the source gateway, if I tcpdump tunnel0 I see the gre-encapsulated 
packets.  If openswan is running, tcpdump on eth0 will show ESP packets.

> Openswan will NEVER allow plaintext traffic over a connection that has 
> a security association connected
> to it.

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

You can shut ipsec down or start it up - Either way the subnets can talk 
to each other via the GRE tunnel.

> You can verify this by hooking up a hub and plugging a tcpdump machine 
> on the same cable as your openswna endpoint and then sniff the traffic.

My testrig has a gateway machine that connects the two openswan 
gateways' public interfaces.  When ipsec is up, I see ESP packets 
between the two, even if I'm using ssh to go from one to the other.  
When ipsec is down, I see either ssh or GRE packets, depending on 
whether I'm talking from gateway to gateway or private network to 
private network.

>> In order to get the 'private' into 'virtual private network', we need 
>> to encrypt traffic between the gateways.  Because we're already 
>> tunneling the
>
> There is no such as thing "private into the vpn". And the 
> virtual_private=
> option only applies to NAT-T subnet ranges.

I was just being clever with my words.  I meant that in order to not 
just have a virtual (tunneled) network, we need encryption for the 
"private" aspect.

>> This new configuration has one extremely important difference vs. the 
>> old config:  If openswan dies for any reason, packets will continue 
>> to move over the internet totally in the clear.
>
>
> If you use auto=start, then a %hold will be created and no plaintext 
> traffic will be send out, even if "openswan dies". And the other end 
> will neither accept nor transmid plaintext traffic.

This is also helpful to know.  Thank you.


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