Project

General

Profile

Site-To-Site VPN hosts can't view other side

Added by Max Bonfield about 6 years ago

Hi,

I've been cracking my head with this and researching like crazy but I am not being able to figure it out.

Been researching this for days and I can't quite understand.

I have two sites, I set up a Ubuntu 16.04 "VPNGateway" on each site.

Installed StrongSwan on both VPNGateways and set it up as this:

Site A (ipsec.conf):

config setup
        charondebug="all" 
        uniqueids=yes
        strictcrlpolicy=no
conn %default
conn tunnel #
        left=198.x.x.2
        leftsubnet=10.6.0.0/16
        right=159.x.x.2
        rightsubnet=10.2.0.0/16
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel

Site B (ipsec.conf):

config setup
        charondebug="all" 
        uniqueids=yes
        strictcrlpolicy=no
conn %default
conn tunnel #
        left=159.x.x.2
        leftsubnet=10.2.0.0/16
        right=198.x.x.2
        rightsubnet=10.6.0.0/16
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel

Both servers share the secret and the IPSec tunnel is established.

This is the "IPSec statusall" (just one side for reference, the other side matches simmetrically):

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-112-generic, x86_64):
  uptime: 44 hours, since Feb 04 05:40:07 2018
  malloc: sbrk 2433024, mmap 0, used 360224, free 2072800
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown
Listening IP addresses:
  198.x.x.2
  10.10.0.10
  10.6.25.47
Connections:
      tunnel:  198.x.x.2...159.x.x.2  IKEv2, dpddelay=30s
      tunnel:   local:  [198.x.x.2] uses pre-shared key authentication
      tunnel:   remote: [159.x.x.2] uses pre-shared key authentication
      tunnel:   child:  10.6.0.0/16 === 10.2.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
      tunnel[81]: ESTABLISHED 31 minutes ago, 198.x.x.2[198.x.x.2]...159.x.x.2[159.x.x.2]
      tunnel[81]: IKEv2 SPIs: 0071d652004d08e7_i f0e006f00403a1cf_r*, pre-shared key reauthentication in 11 minutes
      tunnel[81]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
      tunnel{72}:  INSTALLED, TUNNEL, reqid 72, ESP SPIs: ca9c80ec_i cb1d2dae_o
      tunnel{72}:  AES_CBC_256/HMAC_SHA2_256_128, 38868 bytes_i (744 pkts, 0s ago), 322044 bytes_o (748 pkts, 0s ago), rekeying in 7 hours
      tunnel{72}:   10.6.0.0/16 === 10.2.0.0/16

I set up forwarding on both servers:

echo "1"> /proc/sys/net/ipv4/ip_forward

I've added the following iptables rules (pertinent to each side):

iptables -t nat -A POSTROUTING -s 10.2.0.0/16 -o eth1 -j MASQUERADE

iptables -A FORWARD -s 10.6.0.0/16 -d 10.2.0.0/16 -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT

iptables -A FORWARD -s 10.2.0.0/16 -d 10.6.0.0/16 -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT

This is the routing table on the same server (the other one mirrors):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         198.x.x.1    0.0.0.0         UG    0      0        0 eth0
10.10.0.0       *               255.255.0.0     U     0      0        0 eth0
10.6.0.0      *               255.255.0.0     U     0      0        0 eth1
198.x.x.0    *               255.255.255.0   U     0      0        0 eth0

If I ping from one VPNGateway to the other for the 10.2 or 10.6 IP, I get a reply. If I ping from one VPNGateway to a host on the other end for the 10.2 or 10.6 IP I get a reply.

But, if I ping from any host on either network, to any the 10 ip on the opposite VPNGateway or to any host on the remote network, I get no response.

I tried setting up different routes to 10.2 on the 10.6 hosts and vice versa to no avail.

Every host is two homed. eth0 has a public IP and eth1 has the 10 IP.

This is what the routing table looks like on a 10.6 host:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         67.*.*.1    0.0.0.0         UG    0      0        0 eth0
10.10.0.0       *               255.255.0.0     U     0      0        0 eth0
10.6.0.0      *               255.255.0.0     U     0      0        0 eth1
67.x.x.0    *               255.255.240.0   U     0      0        0 eth0

I thought this route would work: route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.6.25.47 dev eth1

But it didn't. Tried some other routes (most of the I knew were wrong but was trying to figure out stuff).

Tried disabling the public net and setting the Default GW to be the 10.6 address from the VPNGateway, to no avail.

I am out of ideas.... can anyone please give me a hand?

Thanks!


Replies (2)

RE: Site-To-Site VPN hosts can't view other side - Added by Toshi MARUYAMA about 6 years ago

Is this related with Redmine?

RE: Site-To-Site VPN hosts can't view other side - Added by Mischa The Evil about 6 years ago

Toshi MARUYAMA wrote:

Is this related with Redmine?

I don't think so. Seems the TS came here via the strongSwan Redmine instance, which seems related to the question asked.

    (1-2/2)