IPSec on OpenVZ multiple ip addresses, using 127.0.0.2 on venet0

Question

I have an OpenVZ box with IPSec enabled.

root@wa000:~# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.38/K2.6.32-042stab094.7 (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                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

I installed openswan and xl2tpd for L2TP VPN. When I restart ipsec:

# service ipsec restart
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec U2.6.38/K2.6.32-042stab094.7...
ipsec_setup: multiple ip addresses, using  127.0.0.2 on venet0

It detected 127.0.0.2, which I believe is a local ip to serve. I want it to serve on my public ip address. But I have no idea how to let ipsec serve on the right ip. I did googling, but nothing seems to be really helpful.

Here is the ifconfig -a output. I replaced the actual IPs with x.x.x.x, y.y.y.y and z.z.z.z.

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:18:51:69:44:e6  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          NOARP  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gretap0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          BROADCAST MULTICAST  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

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:118 errors:0 dropped:0 overruns:0 frame:0
          TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:18229 (18.2 KB)  TX bytes:18229 (18.2 KB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:126133 errors:0 dropped:0 overruns:0 frame:0
          TX packets:102937 errors:0 dropped:724 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11322355 (11.3 MB)  TX bytes:40737353 (40.7 MB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:x.x.x.x  P-t-P:x.x.x.x  Bcast:x.x.x.x  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

venet0:1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:y.y.y.y  P-t-P:y.y.y.y  Bcast:y.y.y.y  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

venet0:2  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:z.z.z.z  P-t-P:z.z.z.z  Bcast:z.z.z.z  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

First post the output of ifconfig -a so you can determine what the right IP and interface actually is, and post your /etc/ipsec.conf file so we can see what's missing. — noitsbecky, Jun 24 '15 at 13:14
Thanks @qasdfdsaq. I posted the output of the `ifconfig -a` as a separate answer as it's too long for here. — Qian Chen, Jun 24 '15 at 13:24
The best thing to do would be to edit that information into your question instead of posting it as an answer. — noitsbecky, Jun 24 '15 at 13:25
Thanks @qasdfdsaq. I edited it in my original question, and deleted the answer. — Qian Chen, Jun 24 '15 at 13:29
Which of those interfaces is the external interface you *want* to listen on? And are you doing this on the OpenVZ host or a client/container? — noitsbecky, Jun 24 '15 at 13:30
Any of the x, y or z. I'm doing this on the OpenVZ container machine. — Qian Chen, Jun 24 '15 at 14:12

score 4 · Answer 1 · answered Jun 26 '15 at 16:53

You didn't specify, but from your ifconfig -a excerpt we can assume you're running ipsec inside OpenVZ VE, not hardware node (HN). Just to be sure — did you check out theirs recommendation for that kind of set-up?
OpenVZ's templates for VEs are really mind-blowing sometimes. I asked the devs why would one want to use 127/8 range IPs on non-loopback interfaces, but their answer was "well, we don't know, somebody else added it and it's legacy now". Absolute crap. You can safely remove this 127.0.0.2 "kludge" from the interface in question, it doesn't do a thing: ip ad del 127.0.0.2/32 dev venet0. The problem is, though, on every VE restart this silly crap would be re-added. If you're controlling the hardware node you can set template to something that wouldn't trigger theirs "kludge" containing networking configuration. If you're not controlling it, well, the workaround is to put this "ip ad del" into something like /etc/rc.local and then re-start ipsec.

score 1 · Answer 2 · answered Jun 24 '15 at 17:13

From https://lists.openswan.org/pipermail/users/2010-June/018901.html

When Openswan starts up, it looks like it picks the first IP Address on the br0 interface to announce what it’s picking. In case it picks wrong one of these days, how do I tell it definitively which IP Address on which interface? Or is this just an opening announcement and I don’t need to worry about it?

It binds to all addresses that are configured at startup. If an address is added later on, currently, pluto needs to be told to rebind these with "ipsec whack --listen"

ipsec_setup: multiple ip addresses, using 10.0.0.10 on br0

The message is a bit confusing. It will "use" the IP address it received a packet of when responding, and it uses the "nearest" IP address when initiating when using "%defaultroute". If will use the ip or resolved host name ip if specified in the conn.

It's possible your OpenVZ interfaces are not being bound automatically as they don't exist at startup.

Additionally, you can force it to listen on only one IP by editing your /etc/ipsec.conf file, adding the correct XX.XX.XX.XX or interface venet0:X specification using the listen=XX.XX.XX.XX or interface=venet0:X directives under the config setup section.

http://linux.die.net/man/5/ipsec.conf

Thanks @qasdfdsaq. I tried adding `listen` and `interface` under `config set` in `/etc/ipsec.conf`, but it's the same. — Qian Chen, Jun 26 '15 at 17:07

IPSec on OpenVZ multiple ip addresses, using 127.0.0.2 on venet0

2 Answers2