[Openswan Users] Success with broadcast through GRE

[Paul Wouters]

On Fri, 7 Oct 2005, Michael Jurney wrote:

> Network 1: 172.16.8.0/24
> Network 2: 172.16.32.0/24
>
> The gateways:
>
> openswan1:
> eth0: 10.1.1.100
> eth1: 172.16.8.1
> default route via 10.1.1.1
>
> openswan2:
> eth0: 10.2.2.100
> eth1: 172.16.32.1
> default route via 10.2.2.1
>
> The original configuration:
> -------------------------------------------------------------------------
>
> Connection description on openswan1:
>
> conn network2
>       authby=secret
>       rightid=network2
>       auth=esp
>       left=10.1.1.100
>       leftsubnet=172.16.8.0/24
>       leftnexthop=10.1.1.1
>       right=10.2.2.100
>       rightsubnet=172.16.32.0/24
>       rightnexthop=10.2.2.1
>
> Connection description on openswan2:
>
> conn network1
>       authby=secret
>       rightid=network1
>       auth=esp
>       left=10.2.2.100
>       leftsubnet=172.16.32.0/24
>       leftnexthop=10.2.2.1
>       right=10.1.1.100
>       rightsubnet=172.16.8.0/24
>       rightnexthop=10.1.1.1
>
> Routes:
>
> openswan properly managed the routes, adding a route for the target network 
> via eth0 (I'm not using KLIPS).
> -------------------------------------------------------------------------

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.


>
> 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. Openswan will NEVER allow
plaintext traffic over a connection that has a security association connected
to it. In other words, if the tunnel comes up, there is not going to be any
plaintext traffic for the range specified in the 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.

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

> traffic between the two, we can just encrypt everything that moves between 
> them by changing the ipsec config on each:
>
> conn network2
>       authby=secret
>       rightid=network2
>       auth=esp
>       left=10.1.1.100
>       leftsubnet=10.1.1.100/32

This is effectively the same as not specifying the subnet.

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

Paul
-- 

"Happiness is never grand"

 	--- Mustapha Mond, World Controller (Brave New World)