LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   CentOS IPSec Tunnel Mode with NAT-Traversal (https://www.linuxquestions.org/questions/linux-security-4/centos-ipsec-tunnel-mode-with-nat-traversal-731442/)

azrael808 06-08-2009 11:03 AM
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)

azrael808 06-10-2009 10:57 AM
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

unSpawn 06-10-2009 08:35 PM
Awesome! Thanks for posting back your solution.

thekillerbean 11-22-2012 09:29 PM
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.

thekillerbean 11-23-2012 03:37 PM
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.


All times are GMT -5. The time now is 04:08 AM.