IPsec VPN site-to-site: How should I configure the ipsec.conf files on both sites to get the tunnel up?

Question

What I am trying to do is to create a site-to-site IPsec VPN between my network and my friend's network. We both have a router and two computers on each router, with all computers running Linux. So I guess the topology looks like this

[myPC1 + myPC2]---myRouter------internet-----hisRouter---[hisPC1 + hisPC2]

Both routers are cheap so they don't have anything like OpenWRT.

So the configuration – I guess that should be done in Linux on both sides.

So far we have tried with openSwan both with RSA keys and PSK but after the command

ipsec auto --up net-to-net

we either get the error "no connection named net-to-net" or the error "We cannot identify ourselves with either end of this connection."

I guess we are configuring the ipsec.conf file wrong. Could someone explain how we should configure it correctly to achieve this topology, please?

EDIT...

Here are some facts that might help you understand better my case.
These are all from the PSK example we tested.

My ifconfig:

eth0 Link encap:Ethernet HWaddr 00:0C:29:1B:F5:1C
inet addr:192.168.1.78 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe1b:f51c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:829 errors:0 dropped:0 overruns:0 frame:0
TX packets:704 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1213737 (1.1 MiB) TX bytes:57876 (56.5 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:53 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3664 (3.5 KiB) TX bytes:3664 (3.5 KiB)

His ifconfig

Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 b) TX bytes:240 (240.0 b)

p2p1 Link encap:Ethernet HWaddr 08:00:27:2A:F1:F5
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe2a:f1f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21104 errors:0 dropped:0 overruns:0 frame:0
TX packets:12458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16079321 (15.3 MiB) TX bytes:1012204 (988.4 KiB)

The ipsec.conf file, we both used the exact same file, we also placed it in /etc/init.d

version 2.0    
config setup    
    protostack=netkey    
    nat_traversal=yes    
    #virtual_private=    
    oe=off    

conn net-to-net  
    authby=secret                # Key exchange method  

    left=212.251.112.115         # Public Internet IP address of the
    leftsubnet=10.0.2.0/24       # Subnet protected by the LEFT VPN device  
    leftnexthop=%defaultroute    # correct in many situations  

    right=79.103.7.114           # Public Internet IP address of
    rightsubnet=192.168.1.0/24   # Subnet protected by the RIGHT VPN device  
    rightnexthop=%defaultroute   # correct in many situations

    auto=start                   # authorizes and starts this connection

We also used th exact same ipsec.secrets, which we both placed in /etc/init.d

212.251.112.115 79.103.7.114 : PSK "123"

we got those IPs with curl ifconfig.me After that configuration we run:

service ipsec restart  
ipsec verify

and we got the same fail message in the send_redirects, which refused to change to 0

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.1.0-7.fc16.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

    [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

    [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

then we proceeded with

ipsec auto --up net-to-net

and we both got

022 "net-to-net": We cannot identify ourselves with either end of this connection.

I don't know if it helps, perhaps you have already noticed what's wrong but here is one last thing, the status of ipsec:

ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 192.168.1.78
000 interface eth0/eth0 192.168.1.78
000 %myid = (none)
000 debug none
000 
000 virtual_private (%priv):
000 - allowed 0 subnets: 
000 - disallowed 0 subnets: 
000 WARNING: Either virtual_private= is not specified, or there is a syntax 
000          error in that line. 'left/rightsubnet=vhost:%priv' will not work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have 
000          private address space in internal use, it should be excluded!
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0} 
000 
000 "net-to-net": 10.0.2.0/24===212.251.112.115<212.251.112.115>[+S=C]---192.168.1.254...192.168.1.254---79.103.7.114<79.103.7.114>[+S=C]===192.168.1.0/24; unrouted; eroute owner: #0
000 "net-to-net":     myip=unset; hisip=unset;
000 "net-to-net":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "net-to-net":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24; interface: ; 
000 "net-to-net":   newest ISAKMP SA: #0; newest IPsec SA: #0;

One more question is how the NETKEY [Failed] problem could be solved, if it's necessary!

Do you have public IP addresses for both OpenSWAN endpoints? — MadHatter, May 04 '12 at 09:31
yes we do have, I got mine in right and his in left. And he has mine in left and his in right, in the ipsec.conf is this correct? we did this like it is in this guide "blogcoding.wordpress.com/2010/09/25/set-up-a-site-to-site-ipsec-vpn-with-openswan-on-debian" — Deneb, May 04 '12 at 09:38
ok, now we need to know a LOT more about the internal topology of your network. could you draw us a diagram showing the internal address ranges of your network and his network? we don't need to know the public addresses of the external interfaces of each openswan box, but we *do* need to know the internal geometry. — MadHatter, May 04 '12 at 09:59
also, and forgive the question, but your answer about public ip addresses for the openswan endpoints contradicts your diagram in the question. can you confirm that the two openswan endpoints posses public ip addresses on their external interfaces? not that there's some kind of port punchthrough going on, but that each has an interface which possesses a public, routable ip address. i apologise for beating this particular question, but it's extremely important, and you're giving slightly contradictory information. — MadHatter, May 04 '12 at 10:01
how can i see if mine and his openswan posses a public ip? do i have to assign my public ip to openswan in some way other than ipsec.conf? for the internal geometry we found our internal addresses with ifconfig... however i'm confused with which address should go to left and which to right — Deneb, May 04 '12 at 10:06
no, assigning it to openswan will work fine **provided the system you're doing this on is the one that owns the address**. my **very strong** suspicion is that you've put your two public addresses into your ipsec.conf, but neither system actually owns either address, which is why they complain that they cannot identify themselves with either end of the connection. the quickest way to find this out is for you to run `ifconfig -a` on both openswan boxes, and post the results in your question along with your `ipsec.conf`. — MadHatter, May 04 '12 at 10:09
ok i will gather those data and post them in the end of the question. yes we both putted our public ip(which are not static as far as i know) in the ipsec.conf, what could we do about that? if we did two accounts in No-IP.com and put those static IPs in the ipsec.conf could this work ? — Deneb, May 04 '12 at 10:17
I added the steps we took. Please notice that commented #virtual_private= in the ipsec.conf, what are we supposed to complete this with? is it mandatory? i'm asking because most guides don't even include it in the PSK examples. — Deneb, May 05 '12 at 07:08
@Deneb: your answer deserve some proper feedback. Was it working or not ?? — YumYumYum, Jul 30 '13 at 20:33

MadHatter · Accepted Answer · 2017-03-17T07:51:18.240

My word, you do have your work cut out. OK; here's a sort of outline primer, because at the moment you've got the fundamentals so wrong that the details don't matter.

Before anything else, the fact that you haven't got static public addresses for each of your internet connections is a problem. IPSec doesn't easily support tunnels in such configurations [1], so you're going to end up editing your ipsec.conf each time either of your addresses changes. OK?

Now, when I asked you if each OpenSWAN endpoint had a public IP address, and you confidently said "yes", it turns out - as I suspected - that you were wrong. Your ifconfig output shows me that one end has the address 192.168.1.78 and the other has the address 10.0.2.15. You also tell me that one end is (currently) behind the public IP address 212.251.112.115 and the other is behind 79.103.7.114. You don't say which is which, so I'll assume 192.168.1.78 is behind 212.251.112.115 and 10.0.2.15 is behind 79.103.7.114. If that's wrong, just reverse the correspondence. I'll also call the former pair left and the latter pair right. It makes no difference which is which, but it'll help us keep our thinking straight, which'd be a really good idea right about now.

You'll need to set up the public routers at both ends to forward UDP/500 and protocols 50 and 51 (just for completeness) to the OpenSWAN endpoints inside each public address. If you can't manage the two protocol punchthroughs, then investigate the doco on NAT traversal and forward UDP/4500 as well.

Firstly, it is a requirement that each end find its own IP address in the config, so that each end can know which of left and right it is when it starts. So left needs to have an ipsec.conf that contains

conn net-to-net  
    authby=secret
    left=192.168.1.78
    leftsubnet=192.168.1.0/24
    leftnexthop=%defaultroute
    right=79.103.7.114
    rightsubnet=10.0.2.0/24

and an ipsec.secrets that says

192.168.1.78 79.103.7.114: PSK "123"

while right must have an ipsec.conf that contains

conn net-to-net  
    authby=secret
    left=212.251.112.115
    leftsubnet=192.168.1.0/24
    right=10.0.2.15
    rightsubnet=10.0.2.0/24 
    rightnexthop=%defaultroute

and an ipsec.secrets that says

10.0.2.15 212.251.112.115: PSK "123"

Each end really needs to know who it really is, whilst it can pretend that it doesn't care that the remote end is behind a NAT. Do you see?

Furthermore, you'll need to config all the clients on each end so that they have a route to the remote RFC1918 network via the local OpenSWAN endpoint. You'll need to check that /proc/sys/net/ipv4/ip_forward is set to 1 on each endpoint. And it would be a really good idea to turn off any firewalling on the two endpoints, at least for now. You may also need to activate some config variables that tell each endpoint not to care that the remote endpoint thinks it has a different IP address from what the local endpoint thinks it has; from memory, these are leftid= and rightid=, but you're going to have to work that out for yourself.

So that's the basics. If you get the fundamental topology and concepts right, the rest is just debugging the details. Good luck with this.

[1] This isn't quite true. The SWAN implementations support opportunistic IPSec encryption, but this requires that you control your reverse DNS at both ends, and I'm guessing that you don't. Again, read the man pages if you want to know more about this.

Thank you so much for your answer and especially for covering every aspect of my problem! It's true that i got some of the fundamentals wrong, i'm going to read carefully your answer and experiment with these configurations. Once i have any result positive or not i'm going to let you know! — Deneb, May 10 '12 at 08:38
Deneb, I'm glad you found my answer helpful; it took some time to write. I do very strongly encourage you to try **hard** to get this working on your own; you'll learn more, and in addition I may not be able to spend much time teaching you the ins-and-outs of OpenS/WAN diagnostics. But it would be nice to know how you get on! — MadHatter, May 10 '12 at 10:01