LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 06-08-2009, 12:03 PM   #1
azrael808
Member
 
Registered: Dec 2004
Location: London, UK
Distribution: Fedora and CentOS
Posts: 43

Rep: Reputation: 15
Angry CentOS IPSec Tunnel Mode with NAT-Traversal


Hi,

I'm having a real headache trying to set up the following IPSec solution:

Private LAN --- IPSec Endpoint<internal_office_IP> --- NAT device/firewall<external_office_IP> --- Internet --- <public_IP>IPSec Endpoint --- Publicly addressed subnet.

The end goal is to be able to have traffic that travels from the office (private) to the hosting environment (public). Simply tunnelling using SSH is not enough, I need an IPSec tunnel.

I have been using the documentation available on the CentOS site as a guide.

Because one of the end points is behind a NAT device/firewall, I have needed to turn on NAT-traversal, so I added the following directive to the racoon config file on each IPSec endpoint (not mentioned in the CentOS/Red Hat docs BTW):

nat_traversal on;

Now, when I try to initialise the tunnel (by sending traffic to the appropriate subnet), I notice the following error being produced:

ERROR: libipsec failed send update_nat (No algorithm specified)

I've Googled that and all I can find are posts from the same guy, with the exact same problem, but with no responses... And this was way back in 2006!

Does anyone have any experience configuring NAT-traversal with racoon? I'm hoping this is an easy fix, the error message would seem to suggest I need another configuration option somewhere that defines an appropriate algorithm.

I've copied/pasted the output from the endpoint behind the firewall at the end of this post, the output from the endpoint in the publicly available subnet is essentially the same, except for the fact that it identifies the "PEER" as being behind at NAT device and it doesn't see the <internal_office_IP>, instead it sees the <external_office_IP>.

Thanks in advance,

Pete

---------------------------------------------------
racoon debug output on endpoint behind firwall:
---------------------------------------------------
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: respond new phase 1 negotiation: <internal_office IP>[500]<=><public_IP>[500]
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: begin Aggressive mode.
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: received Vendor ID: RFC 3947
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: received Vendor ID: DPD
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: Selected NAT-T version: RFC 3947
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: NOTIFY: couldn't find the proper pskey, try to get one by the peer's address.
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: Adding remote and local NAT-D payloads.
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: Hashing <public_IP>[500] with algo #2
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: Hashing <internal_office IP>[500] with algo #2
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: NAT-T: ports changed to: <public_IP>[4500]<-><internal_office IP>[4500]
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: Hashing <internal_office_IP>[4500] with algo #2
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: NAT-D payload #0 doesn't match
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: Hashing <public_IP>[4500] with algo #2
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: NAT-D payload #1 verified
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: NAT detected: ME
Jun 8 16:17:22 ipsec-gateway0 racoon: 2009-06-08 16:17:22: INFO: ISAKMP-SA established <internal_office_IP>[4500]-<public_IP>[4500] spi:35cb25479378aab6:8d6f489b11a2ad03
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: INFO: respond new phase 2 negotiation: <internal_office_IP>[4500]<=><public_IP>[4500]
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: ERROR: libipsec failed send update_nat (No algorithm specified)
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: ERROR: pfkey update failed.
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: ERROR: failed to process packet.
Jun 8 16:17:23 ipsec-gateway0 racoon: 2009-06-08 16:17:23: ERROR: phase2 negotiation failed.
Jun 8 16:17:53 ipsec-gateway0 racoon: 2009-06-08 16:17:53: INFO: IPsec-SA expired: AH/Tunnel <public_IP>[0]-><internal_office_IP>[0] spi=76770912(0x4936e60)
Jun 8 16:17:53 ipsec-gateway0 racoon: 2009-06-08 16:17:53: INFO: IPsec-SA expired: ESP/Tunnel <public_IP>[0]-><internal_office_IP>[0] spi=214429085(0xcc7ed9d)
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: INFO: initiate new phase 2 negotiation: <internal_office IP>[4500]<=><public_IP>[4500]
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: INFO: NAT detected -> UDP encapsulation (ENC_MODE 1->3).
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: INFO: NAT detected -> UDP encapsulation (ENC_MODE 1->3).
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: ERROR: libipsec failed send update_nat (No algorithm specified)
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: ERROR: pfkey update failed.
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: ERROR: failed to process packet.
Jun 8 16:57:01 ipsec-gateway0 racoon: 2009-06-08 16:57:01: ERROR: phase2 negotiation failed.
Jun 8 16:57:31 ipsec-gateway0 racoon: 2009-06-08 16:57:31: INFO: IPsec-SA expired: AH/Tunnel <public_IP>[0]-><internal_office IP>[0] spi=82925571(0x4f15803)
Jun 8 16:57:31 ipsec-gateway0 racoon: 2009-06-08 16:57:31: INFO: IPsec-SA expired: ESP/Tunnel <public_IP>[0]-><internal_office IP>[0] spi=88756792(0x54a5238)

Last edited by azrael808; 06-10-2009 at 11:41 AM.
 
Old 06-10-2009, 11:57 AM   #2
azrael808
Member
 
Registered: Dec 2004
Location: London, UK
Distribution: Fedora and CentOS
Posts: 43

Original Poster
Rep: Reputation: 15
Worked out the cause of the problem!!!

Essentially, the policies created by the system when the "ifup ipsec0" command was run required both ESP and AH protocols to be used in the creation of the tunnel. Below I have pasted the relevant output generated by running the command "setkey -DP" from one of the endpoints:

Code:
<public_addressed_subnet>[any] <private_subnet>[any] any
	in prio def ipsec
	esp/tunnel/<public_IP>-<internal_office_IP>/require
	ah/tunnel/<public_IP>-<internal_office_IP>/require
	created: Jun 10 12:47:18 2009  lastused:                     
	lifetime: 0(s) validtime: 0(s)
	spid=8 seq=9 pid=2068
	refcnt=1
<private_subnet>[any] <public_addressed_subnet>[any] any
	out prio def ipsec
	esp/tunnel/<internal_office_IP>-<public_IP>/require
	ah/tunnel/<internal_office_IP>-<public_IP>/require
	created: Jun 10 12:47:18 2009  lastused: Jun 10 13:02:54 2009
	lifetime: 0(s) validtime: 0(s)
	spid=1 seq=7 pid=2068
	refcnt=1
<public_addressed_subnet>[any] <private_subnet>[any] any
	fwd prio def ipsec
	esp/tunnel/<public_IP>-<internal_office_IP>/require
	ah/tunnel/<public_IP>-<internal_office_IP>/require
	created: Jun 10 12:47:18 2009  lastused: Jun 10 12:55:54 2009
	lifetime: 0(s) validtime: 0(s)
	spid=18 seq=5 pid=2068
	refcnt=1
AH doesn't work through NAT, because the checksums of the packets are changed as they pass through the NAT device. So, I dropped the policies on both endpoints and recreated, omitting the AH requirement. Below are the commands I ran on the IPSec endpoint in the office, behind the NAT device:

Code:
localhost# setkey -FP
localhost# setkey -c
spdadd <private_subnet> <public_addressed_subnet> any -P out ipsec esp/tunnel/<internal_office_IP>-<public_IP>/require;
spdadd <public_addressed_subnet> <private_subnet> any -P in ipsec esp/tunnel/<public_IP>-<internal_office_IP>/require;
<ctrl+D>
localhost#
A similar set of commands (inverted and using the external IP of the office in place of the internal IP of the IPSec tunnel) was run on the other endpoint to ensure that the AH requirement was dropped.

Running the "setkey -DP" command again confirmed this to me:

Code:
<public_addressed_subnet>[any] <private_subnet>[any] any
	in prio def ipsec
	esp/tunnel/<public_IP>-<internal_office_IP>/require
	created: Jun 10 12:47:18 2009  lastused:                     
	lifetime: 0(s) validtime: 0(s)
	spid=8 seq=9 pid=2068
	refcnt=1
<private_subnet>[any] <public_addressed_subnet>[any] any
	out prio def ipsec
	esp/tunnel/<internal_office_IP>-<public_IP>/require
	created: Jun 10 12:47:18 2009  lastused: Jun 10 13:02:54 2009
	lifetime: 0(s) validtime: 0(s)
	spid=1 seq=7 pid=2068
	refcnt=1
<public_addressed_subnet>[any] <private_subnet>[any] any
	fwd prio def ipsec
	esp/tunnel/<public_IP>-<internal_office_IP>/require
	created: Jun 10 12:47:18 2009  lastused: Jun 10 12:55:54 2009
	lifetime: 0(s) validtime: 0(s)
	spid=18 seq=5 pid=2068
	refcnt=1
Once these new policies were in place, I was able to send traffic via the tunnel!

Pete
 
Old 06-10-2009, 09:35 PM   #3
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,671
Blog Entries: 54

Rep: Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953
Awesome! Thanks for posting back your solution.
 
Old 11-22-2012, 10:29 PM   #4
thekillerbean
Member
 
Registered: Jan 2002
Distribution: Ubuntu 12.04.2 (Precise)
Posts: 89

Rep: Reputation: 16
First, apologies on reviving this rather old, old thread, but I have a question!

What would I be compromising security wise (if anything) by making these changes in a production environment?

I ask 'cause I'm in a situation where this solution is the only one that works! I have 2 Linux servers that never see the internet directly. They are guarded by Cisco Routers on both ends with the Cisco devices doing all the heavy work of NAT'ing. I have been struggling to get this going over the last 4 days and stumbled upon this post after quite a while (and a whole lot) of Googling.

I'm not yet a fully fledged security professional (I just finished my CCNA (ICND1+ICND2) and I'm now working on CCNA Security) but I'm well on my way and will most likely answer my own question in a short while. However, it'd be good to get the opinion of veterans in this field.


Cheers,
ak.
 
Old 11-23-2012, 04:37 PM   #5
thekillerbean
Member
 
Registered: Jan 2002
Distribution: Ubuntu 12.04.2 (Precise)
Posts: 89

Rep: Reputation: 16
Well,

After some light reading on the topic (as I could not contain the suspense), I have discovered that you can indeed use ESP (without AH) when configuring VPN without compromising any security. Therefore, the configuration to do away with AH as indicated above can definitely be used in a production environment.


Cheers,
ak.
 
  


Reply

Tags
centos, ipsec, network, security


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
IPSec Branch Office tunnel and NAT pmcdaid Linux - Networking 6 08-25-2005 06:22 AM
nat-traversal egarnel Linux - Networking 0 09-02-2004 11:31 AM
IPSEC Tunnel behind NAT pssst_yeah_you Linux - Networking 0 06-23-2004 05:54 PM
2.6 IPSEC Tunnel mode gateway mhiggins Linux - Networking 1 02-28-2004 02:50 PM
Config Nat traversal on Mandrake 9.2 superfreeswan why1957 Mandriva 0 02-17-2004 12:08 AM


All times are GMT -5. The time now is 08:39 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration