A co-worker pointed out my error.  The solution was to simply use %direct for 
leftnexthop and rightnexthop.

--
Charlie Brown
Software Engineer
Cisco Openstack Private Cloud
charl...@cisco.com

Cisco.com - http://www.cisco.com




On 9/22/16, 5:03 PM, "Paul Wouters" <p...@nohats.ca> wrote:

    On Wed, 21 Sep 2016, Charlie Brown (charlibr) wrote:
    
    > Subject: [Swan] libreswan subnet to subnet (on top of Openstack Neutron)
    > 
    > * Libreswan 3.15 ipsec (libreswan-3.15-5.el7_1.x86_64)
    > * Openstack Icehouse
    > * RHEL 7.1 boxes used as routers
    > 
    > Followed this document (with modifications) 
https://libreswan.org/wiki/Subnet_to_subnet_VPN_with_PSK
    > 
    > I am attempting to create libreswan ipsec tunnels between tenants in an 
Openstack Icehouse cloud.  I
    > have created a shared subnet (10.255.255.0/24) that the RHEL boxes attach 
to in a multi-homed fashion. 
    > Each box has two interfaces. net.ipv4.ip_forward is enabled (1) on each 
box.
    >  
    > 
    >     Router in tenant A                           Router in tenant B
    > 
    >     ------------------------                     ------------------------
    > 
    >     eth0      eth1           <=================> eth1           eth0
    > 
    >     10.0.1.1  10.255.255.10                      10.255.255.20  10.0.2.1
    > 
    >     ------------------------                     ------------------------
    
    > Running this config on each end has the tunnel coming up without any 
errors.  When the tunnel comes up,
    > libreswan adds a new route with a higher priority than the initial static 
route:
    > 
    >      10.0.2.0/24 dev eth1  scope link  src 10.0.1.1
    > 
    >      10.0.2.0/24 via 10.255.255.20 dev eth1  proto static  metric 100
    
    It does that because you set leftsourceip= and rightsourceip=.
    
    The kernel normally picks the "nearest IP" as source IP, so if on tenant
    A you normally type "ping 10.0.2.1", it would pick the nearest IP as
    source, which is 10.255.255.10. Your packet with source 10.255.255.10
    and destination 10.0.2.1 would not be covered by your tunnel that
    only covers 10.0.1.0/24 to <=> 10.0.2.0/24, and the packet would not
    get encrypted (and hopefully a firewall would drop it). When setting
    leftsourceip/rightsourceip, a route is added so that the kernel knows
    it should pick the internal IP 10.0.1.1 instead of the nearest IP
    10.255.255.10. Things then get properly encrypted for the gateways as
    well as the subnets.
    
    > I can ping the remote router's eth0 interface IP address but not any 
hosts in the remote subnet.  This
    > is true from either direction. 
    
    That's usually the result of either forwarding permissions (sysctl or in
    iptables) or rp_filter or accidental NAT'ing of packets destined for IPsec.
    
    >     traceroute to 10.0.2.1 (10.0.2.1), 64 hops max, 52 byte packets
    
    You cannot really use traceroutes for the hops related to the tunnel.
    
    You can run "ipsec verify" to runs some tests including rp_filter.
    
    You can also add some firewall rules to ensure you are not accidentally
    NAT'ing pcakets meant for IPsec. See:
    
    https://libreswan.org/wiki/FAQ#NAT_.2B_IPsec_is_not_working
    
    Paul
    

_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to