Home / server / Questions / 677257
In Process
NoNoNo
Asked: 2015-03-22 12:01:03 +0800 CST

subnet-to-subnet libreswan ipsec vpn

  • 772

I'm configuring a "subnet to subnet VPN" between two Centos 7 server using libreswan. Each server has two nic as showed in the following image.

I would allow secure communication between the subnets 172.18.0.0/16 and 172.19.0.0/16 establishing a vpn using 172.17.0.0/16 network but I have problem to allow traffic between these two subnets.

I followed the redhat official documentation in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_Virtual_Private_Networks.html#Site-To-Site_VPN_Using_Libreswan

Actually I stopped firewalld on both nodes.

I checked ipsec prerequisites:

[root@node2 ~]# ipsec verify
Verifying installed system and configuration files

Version check and ipsec on-path                         [OK]
Libreswan 3.8 (netkey) on 3.10.0-123.el7.x86_64
Checking for IPsec support in kernel                    [OK]
 NETKEY: Testing XFRM related proc values
         ICMP default/send_redirects                    [OK]
         ICMP default/accept_redirects                  [OK]
         XFRM larval drop                               [OK]
Pluto ipsec.conf syntax                                 [OK]
Hardware random device                                  [N/A]
Two or more interfaces found, checking IP forwarding    [OK]
Checking rp_filter                                      [OK]
Checking that pluto is running                          [OK]
 Pluto listening for IKE on udp 500                     [OK]
 Pluto listening for IKE/NAT-T on udp 4500              [OK]
 Pluto ipsec.secret syntax                              [OK]
Checking NAT and MASQUERADEing                          [TEST INCOMPLETE]
Checking 'ip' command                                   [OK]
Checking 'iptables' command                             [OK]
Checking 'prelink' command does not interfere with FIPSChecking for obsolete ipsec.conf options                 [OK]
Opportunistic Encryption                                [DISABLED]

The ipsec.conf content is:

config setup
    protostack=netkey

conn mytunnel
    leftid=@node1
    left=172.17.0.101
    leftrsasigkey=0sAQPXn...        
    rightid=@node2
    right=172.17.0.102
    rightrsasigkey=0sAQPxv...
    authby=rsasig

conn mysubnet
     also=mytunnel
     leftsubnet=172.18.0.0/16
     rightsubnet=172.19.0.0/16
     auto=start

I start ipsec service on both node. Then I check that "ipsec status" (here there is the output http://pastebin.com/LYA9uqfJ ) and I don't found any error.

The routing table of node1 is:

[root@node1 ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eno16777736
172.18.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eno33554992

If a try to ping from node1 the ip address 172.19.0.101, I obtain the errror "connect: Network is unreachable"

Is there something missing in my configuration? What can i try to allow secure traffic between these two subnets?

ipsec

2 Answers

  1. Check net.ipv4.ip_forward settings in sysctl.

    Or you can try to run tcpdump on both sides and look what happens.

    Example: 

    tcpdump -n -i interface esp or udp port 500 or udp port 4500

    Also try add iptables rules like this:

    -A FORWARD -i EXTIF -o INIF -j ACCEPT
-A FORWARD -i INIF -o EXTIF -j ACCEPT
-A POSTROUTING -s YOURNET1 ! -d YOURNET2 -j MASQUERADE

    A few more details about what is above:

    • EXTIF is your 172.17.0.0/16 interface

    • INIF is another 172.18.0.0 or 172.19.0.0

    I was used it is HOWTO, my network is working, but not sending keepalive package. Strongswan doesn't have trouble

    • 0

  2. connect: Network is unreachable

    With only routes to 172.17.0.0/16 and 172.18.0.0/24, there is no specific route to 172.19.0.0/16, or a default route that would cover it, which is why you get that error.

    So you have to add either a specific route to the remote subnet, or add a default route on both hosts.

    By the way, you should use ip route to mange routes instead of route.

    • 0