[Openswan Users] Success with broadcast through GRE

[lean]

Thank you very much... I need it when I'll finish to set up my 
configurations.
At this moment I can't reach the subnets but the SA is correctly done 
(as I said before in another post).


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