[Openswan Users] Success with broadcast through GRE

[Christopher Malott]

Just a question from somebody who doesn't spend much time working with 
this....but....

Why couldn't you establish a GRE over IPSEC tunnel, instead of IPSEC 
over GRE? Then just modify the Openswan Up/Down scripts to establish the 
tunnel automatically when you bring the SA up? Then you wouldn't have to 
worry about the unencrypted traffic shooting around until somebody 
noticed the IPSEC link was dead.....

This was noted a few years ago in the FreeS/Wan days by Ken Bantoft. 
Here is a link to the original thread.

http://www2.frell.ambush.de/archives/freeswan-users/6297.html

Maybe I'm missing something?

Best Regards,
Christopher Malott

Michael Jurney wrote:
> 
> 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.
>