IPSec behind NAT

[keysman75]

I guys, it's a week i'm working on IpSec VPN. I can't solve this issue. Can anyone tell me where I'm doing the wrong step and help me to solve?
The following is the way my facility was built.

Office A
ROUTER
2.229.125.x (Public IP)
192.168.20.254 (Private IP)

VPNENDPOINT
192.168.20.1
192.168.0.1 (Private LAN)

Office B
Firewall
212.4.7.x (Public IP)
192.168.2.1 (Private IP)

VPNENDPOINT
192.168.2.52
192.168.2.x (Private LAN)

In B Firewall is well-configurated for redirect all traffic to VPNENDPOINT(B).

Configuration for IpSec Office A is
conn catt3
right=2.229.125.x
rightsubnet=192.168.0.0/24
rightnexthop=%defaultroute
left=212.4.7.x
leftsubnet=192.168.0.0/255.255.0.0
leftnexthop=%defaultroute


Configuration for IpSec Office B is
conn officeA
left=2.229.125.x
leftsubnet=192.168.0.0/24
right=212.4.7.x
rightnexthop=192.168.2.1
rightsubnet=192.168.0.0/16

ipsec.secret is the same on both endpoint
2.229.125.x 212.4.7.x : PSK "xxxxxxxxxxxxxx"

Log on Office A IpSec is the following
Jun 24 10:36:19 efw21 ipsec_setup: KLIPS ipsec0 on eth1 192.168.20.1/255.255.255.0 broadcast 192.168.20.255
Jun 24 10:36:19 efw21 ipsec__plutorun: Starting Pluto subsystem...
Jun 24 10:36:19 efw21 ipsec__plutorun: Unknown default RSA hostkey scheme, not generating a default hostkey
Jun 24 10:36:19 efw21 ipsec_setup: ...Openswan IPsec started
Jun 24 10:36:19 efw21 ipsec_setup: Starting Openswan IPsec 2.4.7...
Jun 24 10:36:19 efw21 pluto[18063]: Starting Pluto (Openswan Version 2.4.7 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEZ~BaB]r\134p_)
Jun 24 10:36:19 efw21 pluto[18063]: Setting NAT-Traversal port-4500 floating to on
Jun 24 10:36:19 efw21 pluto[18063]: port floating activation criteria nat_t=1/port_fload=1
Jun 24 10:36:19 efw21 pluto[18063]: including NAT-Traversal patch (Version 0.6c)
Jun 24 10:36:19 efw21 pluto[18063]: 2 bad entries in virtual_private - none loaded
Jun 24 10:36:19 efw21 pluto[18063]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
Jun 24 10:36:19 efw21 pluto[18063]: starting up 1 cryptographic helpers
Jun 24 10:36:19 efw21 pluto[18063]: started helper pid=18064 (fd:6)
Jun 24 10:36:19 efw21 pluto[18063]: Using KLIPS IPsec interface code on 2.6.9-42.0.3.EL.endian16
Jun 24 10:36:19 efw21 pluto[18063]: Changing to directory '/etc/ipsec.d/cacerts'
Jun 24 10:36:19 efw21 pluto[18063]: Changing to directory '/etc/ipsec.d/aacerts'
Jun 24 10:36:19 efw21 pluto[18063]: Changing to directory '/etc/ipsec.d/ocspcerts'
Jun 24 10:36:19 efw21 pluto[18063]: Changing to directory '/etc/ipsec.d/crls'
Jun 24 10:36:19 efw21 pluto[18063]: Warning: empty directory
Jun 24 10:36:20 efw21 pluto[18063]: loading secrets from "/etc/ipsec.secrets"
Jun 24 10:36:20 efw21 pluto[18063]: added connection description "catt3"
Jun 24 10:36:20 efw21 pluto[18063]: listening for IKE messages
Jun 24 10:36:20 efw21 pluto[18063]: adding interface ipsec0/eth1 192.168.20.1:500
Jun 24 10:36:20 efw21 pluto[18063]: adding interface ipsec0/eth1 192.168.20.1:4500
Jun 24 10:36:20 efw21 pluto[18063]: forgetting secrets
Jun 24 10:36:20 efw21 pluto[18063]: loading secrets from "/etc/ipsec.secrets"
Jun 24 10:36:21 efw21 ipsec__plutorun: 022 "catt3": we cannot identify ourselves with either end of this connection
Jun 24 10:36:21 efw21 ipsec__plutorun: ...could not route conn "catt3"
Jun 24 10:36:21 efw21 pluto[18063]: "catt3": We cannot identify ourselves with either end of this connection.
Jun 24 10:36:21 efw21 ipsec__plutorun: 022 "catt3": We cannot identify ourselves with either end of this connection.
Jun 24 10:36:21 efw21 ipsec__plutorun: ...could not start conn "catt3"

Using ipsec auto --status on Office A
000 "catt3": 192.168.0.0/16===212.4.7.x---192.168.20.254...192.168.20.254---2.229.125.x===192.168.0.0/24; unrouted; eroute owner: #0
000 "catt3": srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec _updown;
000 "catt3": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "catt3": policy: PSK+ENCRYPT+TUNNEL; prio: 16,24; interface: ; encap: esp;
000 "catt3": dpd: action:hold; delay:30; timeout:120;
000 "catt3": newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "catt3": IKE algorithms wanted: BLOWFISH(7)_128-SHA1(2)-5, BLOWFISH(7)_128-SHA1(2)-2, BLOWFISH(7)_128-MD5(1)-5, BLOWFISH(7)_128-MD5(1)-2, IDEA(5)_000-SHA1(2)-5, IDEA(5)_000-SHA1(2)-2, IDEA(5)_000-MD5(1)-5, IDEA(5)_000-MD5(1)-2, flags=strict
000 "catt3": IKE algorithms found: BLOWFISH(7)_128-SHA1(2)_160-5, BLOWFISH(7)_128-SHA1(2)_160-2, BLOWFISH(7)_128-MD5(1)_128-5, BLOWFISH(7)_128-MD5(1)_128-2, IDEA(5)_192-SHA1(2)_160-5, IDEA(5)_192-SHA1(2)_160-2, IDEA(5)_192-MD5(1)_128-5, IDEA(5)_192-MD5(1)_128-2,
000 "catt3": ESP algorithms wanted: AES(12)_128-SHA1(2), AES(12)_128-MD5(1), 3DES(3)_000-SHA1(2), 3DES(3)_000-MD5(1), flags=strict
000 "catt3": ESP algorithms loaded: AES(12)_128-SHA1(2), AES(12)_128-MD5(1), 3DES(3)_000-SHA1(2), 3DES(3)_000-MD5(1), flags=strict

On Office B
Jun 24 11:24:33 c1p8 ipsec__plutorun: 022 "officeA": We cannot identify ourselves with either end of this connection.
Jun 24 11:24:33 c1p8 ipsec__plutorun: ...could not start conn "officeA"

ipsec auto --status (Office B)
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 192.168.2.52
000 %myid = (none)
000 debug none
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=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=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=251, name=(null), keysizemin=0, keysizemax=0
000
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
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
000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
000
000 "officeA": 192.168.0.0/24===2.229.125.x...192.168.2.1---212.4.7.x===192.168.0.0/16; unrouted; eroute owner: #0
000 "officeA": srcip=unset; dstip=unset
000 "officeA": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "officeA": policy: PSK+ENCRYPT+TUNNEL+PFS; prio: 24,16; interface: ;
000 "officeA": dpd: action:hold; delay:30; timeout:128;
000 "officeA": newest ISAKMP SA: #0; newest IPsec SA: #0;

Thanks a lot!

Christian

[IJskes]

I do not understand all you did. But i think you sort of messed up on the subnetting.

You cannot use 192.168.0.0 / 16 on one side, and 192.168.20.0 / 24 on the other. That will cause routability issues. And therefor nothing would seem to work.

I suggest you draw a picture of what networks you want on what side, and then change the required settings.
I think you need to change you private ip-address on one side, so it will not conflict with networks on the other sides.

[aruntomar2001]

Dear Christian,

Your config is wrong.

1. Settings at both the endpoint i.e vpn's should be the same. so basically create the config file at one vpn and copy it to the other vpn also.
2. you forgot to mention:
authby=secret
3. if you are trying to setup part of the same network in another office it's called extruding. it's possible, but i would suggest try to setup simple thing first, like host to host, then subnet to subnet. and i would suggest to keep the network/subnets at both the offices different, so that there is no confusion.
4. also make sure, that you've complied kernel with klips enabled.
5. also use %defaultroute for rightnexthop and leftnexthop.

you will get an IPsec SA succeeded msg, that will tell that the tunnel is established perfectly.

Hope this helps.
Arun.

[rabinnh]

Maybe I'm missing it but I don't see how you set endpoint identities. Subnet to subnet IPSec normally uses the public IP addresses as part of the IDs (local and remote IDs) at each endpoint. This is problematic behind a NAT firewall. Furthermore, make sure the the firewalls have IPSec NAT traversal enabled.

I suggest that you use a local identity at each end (such as an email address construct) and as a previous poster suggested, setup IP <-> IP before you try subnet <-> subnet.

Setting up IPSec tunnels can be a bear in the best of situations - behind NAT firewalls? Best of luck.

My solution was to get rather inexpensive NAT firewalls and configure them firewall to firewall, something like the ZyWall USG 20.

[keysman75]

Hi guys, thanks for your answer, after two days of hard-studying I understood where was mistake. Let me explain in a better way my facility:

Office A
Server Firewall/VPNEndPoint with 2 NIC and IP's 192.168.0.1 and 192.168.20.1
Router with Internal IP 192.168.20.254 and public IP a.b.c.d

Office B
Server Firewall with 2 NIC and IP's 192.186.2.1 and public IP x.y.z.k
Server VPNEndPoint with IP 192.168.2.52

Target was connection between subnet 192.168.0.0/24 to 192.168.2.0/24.

Both VPNEndoints was behind Firewall/Router. NAT Configuration was the problem.

I applied NAT-Traversal concepts to solve the issue.

The configuration's files are the same on both vpnenpoint but slightly different.

Now I will show you only the left/right entries of the ipsec.conf files.

Office A:
nat_traversal=yes
:
right=x.y.z.k
rightid=@right
rightsubnet=192.168.2.0/24
rightnexthop=%defaultroute
left=192.168.20.1
leftsubnet=192.168.0.0/24
leftnexthop=192.168.20.254
leftid=@left

Office B:
nat_traversal=yes
:
right=192.168.2.52
rightid=@right
rightnexthop=192.168.2.1
rightsubnet=192.168.2.0/24
left=a.b.c.d
leftid=@left
leftsubnet=192.168.0.0/24
leftnexthop=192.168.20.254

And ipsec.secret's files are the same on both endpoints.

@left @right : PSK "<yoursecretkey>"

Thanks a lot to everybody answered to my question!!