[Openswan Users] Success with broadcast through GRE

[Michael Jurney]

This is a quick summary of the changes I ended up making in order to get 
broadcast traffic moving properly between my two openswan gateways.  I 
was originally going to rebroadcast netbios traffic from one subnet to 
the other with a udp proxy, but I ended up not needing to.

The problem:  Samba machines on two networks connected with an openswan 
tunnel needed to be able to send broadcast traffic to each others' 
segments, but the ipsec tunnel wouldn't pass broadcast traffic.

The solution:  Instead of using a net-to-net ipsec configuration, 
connect the networks with GRE, then establish an ipsec tunnel between 
the public interfaces of the openswan gateways.

These configurations are from my testbed configuration.  The 10/8 
networks act as the public segments, and the 172.16/16 networks act as 
the private segments:

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


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!

In order to get the 'private' into 'virtual private network', we need to 
encrypt traffic between the gateways.  Because we're already tunneling 
the 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
        leftnexthop=10.1.1.1
        right=10.2.2.100
        rightsubnet=10.2.2.100/32
        rightnexthop=10.2.2.1

Connection description on openswan2:

conn network1
        authby=secret
        rightid=network1
        auth=esp
        left=10.2.2.100
        leftsubnet=10.2.2.100/32
        leftnexthop=10.2.2.1
        right=10.1.1.100
        rightsubnet=10.1.1.100/32
        rightnexthop=10.1.1.1

-------------------------------------------------------------------------


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.  GRE packets are easily 
inspected with tools like tcpdump and ethereal, so care must be taken to 
make sure that you watch for openswan failures and react appropriately.

Thanks everyone for your help over the last few days - I hope this 
summary is informative and useful.

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