5

This is my first attempt at a site-to-site VPN. I chose to use IPec because it appeared to be the best solution for what I needed to accomplish. I've followed several different tutorials over the last week with little success. Right now I can not seem to get pings to succeed when pinging the opposite subnet. I know I'm missing something, I just don't know what.

Best I can tell, I should see something in the routes table. Right now traffic bound for the other subnet is going out without being encapsulated, and get dropped by the first router that picks up on the non-routable private IP destination.

I've tried adding MASQUERADE and RELATED,ESTABLISHED rules to iptables, thinking might help. I ended up flushing that idea. Right now iptables's default policy is accept on all chains on both Ubuntu boxes. Something I will adjust when IPsec is working.

output from "service ipsec status"

IPsec running  - pluto pid: 1059
pluto pid 1059
1 tunnels up
some eroutes exist

/etc/ipsec.conf at both sites

version 2 

config setup
    dumpdir=/var/run/pluto/

    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v6:fd00::/8,%v6:fe80::/10
    protostack=netkey
    force_keepalive=yes
    keep_alive=60


conn site1-site2
    leftsubnets=10.248.248.64/16
    rightsubnet=10.131.250.194/16
    auto=start
    left=162.243.XXX.XXX
    right=178.62.YYY.YYY

    leftid=@site1
    rightid=@site2
    authby=secret
    ike=aes128-sha1;modp1024
    phase2=esp
    phase2alg=aes128-sha1;modp1024
    aggrmode=no
    ikelifetime=8h
    salifetime=1h
    dpddelay=10
    dpdtimeout=40
    dpdaction=restart
    type=tunnel
    forceencaps=yes

output from “ipsec verify” at both sites (IP forwarding is on in /etc/sysctl.conf)

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                 [OK]
Linux Openswan U2.6.38/K3.13.0-24-generic (netkey)
Checking for IPsec support in kernel                [OK]
 SAref kernel support                       [N/A]
 NETKEY:  Testing XFRM related proc values          [OK]
                                [OK]
                                [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Two or more interfaces found, checking IP forwarding            [FAILED]
Checking NAT and MASQUERADEing                                  [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

Site1:/etc/ipsec.secrets

# this file is managed with debconf and will contain the automatically created RSA keys
include /var/lib/openswan/ipsec.secrets.inc

162.243.XXX.XXX 178.62.YYY.YYY : PSK “sameRandomString“

Site1:output from “ip xfrm policy”

src 10.248.0.0/16 dst 10.131.0.0/16 
    dir out priority 2608 
    tmpl src 162.243.XXX.XXX dst 178.62.YYY.YYY
        proto esp reqid 16385 mode tunnel
src 10.131.0.0/16 dst 10.248.0.0/16 
    dir fwd priority 2608 
    tmpl src 178.62.YYY.YYY dst 162.243.XXX.XXX
        proto esp reqid 16385 mode tunnel
src 10.131.0.0/16 dst 10.248.0.0/16 
    dir in priority 2608 
    tmpl src 178.62.YYY.YYY dst 162.243.XXX.XXX
        proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 

Site1:output from “ip route”

default via 162.243.XXX.1 dev eth0 
10.128.128.0/24 dev eth1  proto kernel  scope link  src 10.128.128.64 
162.243.XXX.0/24 dev eth0  proto kernel  scope link  src 162.243.XXX.XXX 

Site2:/etc/ipsec.secrets

# this file is managed with debconf and will contain the automatically created RSA keys
include /var/lib/openswan/ipsec.secrets.inc

178.62.YYY.YYY 162.243.XXX.XXX : PSK “sameRandomString“

Site2:output from “ip xfrm policy”

src 10.131.0.0/16 dst 10.248.0.0/16 
    dir out priority 2608 
    tmpl src 178.62.YYY.YYY dst 162.243.XXX.XXX
        proto esp reqid 16385 mode tunnel
src 10.248.0.0/16 dst 10.131.0.0/16 
    dir fwd priority 2608 
    tmpl src 162.243.XXX.XXX dst 178.62.YYY.YYY
        proto esp reqid 16385 mode tunnel
src 10.248.0.0/16 dst 10.131.0.0/16 
    dir in priority 2608 
    tmpl src 162.243.XXX.XXX dst 178.62.YYY.YYY
        proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 

Site2:output from “ip route”

default via 178.62.YYY.1 dev eth0 
10.131.0.0/16 dev eth1  proto kernel  scope link  src 10.131.250.194 
178.62.YYY.0/18 dev eth0  proto kernel  scope link  src 178.62.YYY.YYY 

A segment of /var/log/auth.log on site2

Jul 24 18:41:14 gb pluto[3365]: packet from 162.243.XXX.XXX:500: received Vendor ID payload [Openswan (this version) 2.6.38 ]
Jul 24 18:41:14 gb pluto[3365]: packet from 162.243.XXX.XXX:500: received Vendor ID payload [Dead Peer Detection]
Jul 24 18:41:14 gb pluto[3365]: packet from 162.243.XXX.XXX:500: received Vendor ID payload [RFC 3947] method set to=115 
Jul 24 18:41:14 gb pluto[3365]: packet from 162.243.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115
Jul 24 18:41:14 gb pluto[3365]: packet from 162.243.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115
Jul 24 18:41:14 gb pluto[3365]: packet from 162.243.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 115
Jul 24 18:41:14 gb pluto[3365]: packet from 162.243.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: responding to Main Mode
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: STATE_MAIN_R1: sent MR1, expecting MI2
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both are NATed
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: STATE_MAIN_R2: sent MR2, expecting MI3
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: Main mode peer ID is ID_IPV4_ADDR: '162.243.XXX.XXX'
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: new NAT mapping for #3, was 162.243.XXX.XXX:500, now 162.243.XXX.XXX:4500
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: Dead Peer Detection (RFC 3706): enabled
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #3: the peer proposed: 10.131.0.0/16:0/0 -> 10.248.0.0/16:0/0
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4: responding to Quick Mode proposal {msgid:9e504ac0}
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4:     us: 10.131.0.0/16===178.62.YYY.YYY<178.62.YYY.YYY>
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4:   them: 162.243.XXX.XXX<162.243.XXX.XXX>===10.248.0.0/16
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4: keeping refhim=4294901761 during rekey
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4: Dead Peer Detection (RFC 3706): enabled
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jul 24 18:41:14 gb pluto[3365]: "site1-site2/1x0" #4: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP/NAT=>0x5b14c281 <0xd731b1b1 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=162.243.XXX.XXX:4500 DPD=enabled

Any help is greatly appreciated.

autisticgeek
  • 53
  • 1
  • 1
  • 3
  • I don't see anything about a firewall. Is it possible there's one blocking ICMP traffic between your test machines? – jski Jul 25 '14 at 00:11
  • Where are you PINGing from and to? Is either source, destination, or both, one of the tunnel endpoints? – MadHatter Jul 25 '14 at 00:34
  • They can ping one another's outside addresses, so no upstream firewall preventing that. – autisticgeek Jul 25 '14 at 18:27
  • The failure occurs when I try to ping from site1 to the internal address of site2, and vice versa. – autisticgeek Jul 25 '14 at 18:28
  • While traversing Serverfault to see if I could help anyone else I came across a similar issue at [http://serverfault.com/questions/386000/ipsec-vpn-site-to-site-how-should-i-configure-the-ipsec-conf-files-on-both-site](http://serverfault.com/questions/386000/ipsec-vpn-site-to-site-how-should-i-configure-the-ipsec-conf-files-on-both-site) This made me question if left should be the local outside address on each machine. I had understood that in /etc/ipsec.conf, the conn should be identical on both. Do I have this incorrect? Should they identical or inverse of one another? – autisticgeek Jul 25 '14 at 19:33
  • What do you mean by "*the internal address of site2*"? According to your `ipsec.conf`, each site has a `/16`, so neither one has only one internal address. I ask again: which machine are you pinging from, and which machine and address are you pinging to? – MadHatter Jul 26 '14 at 06:13

1 Answers1

4

To me it sounds like you are trying to get the site-to-site tunnel gateways to communicate via their internal IP addresses instead of their public IP addresses. In order to do this using a single tunnel you need to configure the left and right internal source addresses. See below...

leftsourceip=10.248.248.64
rightsourceip=10.131.250.194

Add those lines and restart ipsec and you can then ping using the internal gateway.

Jacob Haug
  • 170
  • 7
  • This worked. Adding those lines to the config added routes to the routing table. The gateways on both sides can now ping the internal interfaces on the opposite gateway. – autisticgeek Jul 27 '14 at 00:38