IPSEC

growse

growse

growse

Soldato
Joined
18 Oct 2002
Posts
7,139
Location
Ironing
I've got a number of publicly addressed endpoints that I'd like to access remotely over various ports (80 and 22 specifically). However, I'd like to be able to require authentication on those servers so that only someone with the correct credentials/key/certificate can access the server.

The first thought I had was around IPSEC, as this is something that provides both encryption and authentication at the IP level and therefore be transparent to the services themselves.

Every setup guide I've read seems to want to treat all IPSEC scenarios as a VPN-like instance, where a key-exchange is done between the client and the server and then all traffic is routed down to the server.

What I'm really after is to be able to configure my laptop with a policy to do IPSEC with any host in a particular subnet whenever any ip connection is requested to that host. On the server side, I want the servers to be able to require a valid IKE exchange with any connection that originates from outside a certain subnet, or in short, a server policy that requires authentication and encryption

Is this possible? I'm using mainly linux servers but with windows and linux clients. Openswan on the linux side.
 
That sounds like you just need SSL/TLS rather than IPSEC VPNs?

x.509 certs could be employed to automate logons (rather than needing usernames and passwords)

I am very far from confident about the above but I know someone who will be, I'll see if I can get him to peek at the thread for you :)
 
My understanding with ipsec was that with policies you can establish the security on the fly and transparently, which I didn't think you could do with an SSL vpn?
 
Port 22 is mentioned, so why not use the features SSH already provides, the server for example can be configured with a list of acceptable client public keys.
For other ports you could use SSH tunneling.
 
You are right, there are two types of IPSEC configuration, one where you create a tunnel instance between two points as an encrypted p2p link (in which you can route traffic) and the second where IPSEC policies can be configured 'on demand' for certain traffic.

Essentially (and i'll need to check up on this) the difference is in wether the encryption starts:

-Before the IP layer (crypto|IP|DATA|IP|crypto) as a tunnel
-After IP (IP|crypto|DATA|crypto|IP) as p2p

The second meaning that the IP headers are still visible to intermidiate hosts and routers so the traffic can get to it's destination normally.

Documentation is poor on this as you have mentioned and im not sure from memory that it can handle roaming clients (as in the server having a wildcard for the 'client' IP address for possible inbound crypted connections). However I have a pretty good book in PDF somewhere so i'll try and dig it up now.

Tui: finding a nice way to automatically establish SSH tunnels for protocols on demand and then redirect requests to loopback ports would not be nice if the intended user is anyone but a techy.

DRZ: SSLVPN still may be the best way forward if this doesn't work (like I said not sure about the wildcard client side), definatley if you have a lot of clients or users who are not that technical (admittedly a step up in complexity from a background crypto 'just working') but nicer than configuring a tunnel based IPSEC or SSH tunnel system on each client machine.
//TrX
 
Last edited:
Thanks Trx, any advice is appreciated. I didn't mention at the beginning because I didn't want to complicate things, but I'm primarily looking at this for the IPv6 stack, although having it work on IPv4 is a bonus.

I know openswan works with IPv6, and the documentation listed at http://wiki.openswan.org/index.php/Openswan/Configure indicates that it's possible to have a policy where the other end of the connection is wildcarded (right=%any). I guess that's to cover the scenario for the roaming user where they could be connecting from anywhere.

I'm basing a lot of this off dim memories of a Windows IPSEC lab I did a while back, where if you configred the policies right and then initiated a ping connection, it would print that it was dynamically setting up the SAs. On-demand, so to speak.
 
Last edited:
Dim memories of my own experimentation are what i'm basing my research on now :P Although it seems I was right about the difference in packet arrangement between tunnel and transport mode.

Seems the reason there is so little documentation is that transport mode is used to encrypt/authenticate L2TP for the native VPN clients of Windows and Mac OSX, so most of the examples talk about setting is up for this functionality.

Happen to have two non natted public IP'd linux internet hosts i'm currently SSH'ed into, so i'll do some testing. Sadly only one of them is IPv6'd but can create a HE IPv6 tunnel on it if required.

IPSEC functionality is meant to be 'built in' to the IPv6 proto however, so i'm wondering how this will change things (especially on the windows side!).

Will let you know what I find

//TrX
 
Thanks.

Re IPv6 and native ipsec, I was wondering this too, although the main reason for IPV6 is to remove the complication of NAT :)

*edit* currently reading chapter 20 of http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/. Seems to imply that support is in-kernel with ipsec-tools and that I only need racoon as an IKE daemon... Having read that Openswan's ipv6 support is flaky currently, I might give that a go.
 
Last edited:
Currently knee deep in wireshark trying to observe IPSEC transport connection between my Windows7 box and a linux IPv4 Openswan setup.

Looks like a problem that isnt mentioned very much may be true (need to do more research) but it's almost as if Windows's 'IPSEC' implimentation isnt really an IPSEC implimentation, in that it can only be used in conjunction with L2TP.

Hopeing i'm just seeing a missconfiguration here and this isnt actually the case, reading lots of contradictory messages/docs/manpages/technet articles :S

You'd think it would be a more used security mechanism just due to it's transparentness to the end user... even seems to be able to auth via kerberos ffs!... sweet! (if it worked xD)
 
Windows is a secondary priority, if that makes any difference. But I'm 100% convinced that windows can do opportunistic encryption fine. Whether it can mandate authentication, or respond to mandatory authentication policies in a sane way, I've no idea :(
 
Yeah I am pretty convinced it should/does too. Think i'm running into a NAT passthrough issue here, have openswan debugging enabled which has helped to this point but wether nat_traversal=on or off, still running into the the same no established connection error on the server side.

The Win7 box is behind nat, and while both Windows IPSEC and Openswan say they do nat traversal, maybe there is an issue.

Think I need a better test setup and more sleep, maybe two IPv6 hosts and start a fresh look at this.

Interesting topic tho, let me know if you have any sucess in the meantime.

//TrX
 
OK, I'm getting warm. My test setup currently is:

1) Windows 7 32-bit client (2a01:348:6:142::2)
2) Ubuntu Server (2001:470:1f09:784::15), with ipsec-tools and racoon installed.

What I did.

On the server side, I've created some entries in /etc/ipsec-tools.conf which defines the policies for the ipsec connections. This only requires AH for the connection, and not ESP. At the moment it's point to point, but it looks like this:

Code: 
#!/usr/sbin/setkey -f

# NOTE: Do not use this file if you use racoon with racoon-tool
# utility. racoon-tool will setup SAs and SPDs automatically using
# /etc/racoon/racoon-tool.conf configuration.
#

## Flush the SAD and SPD
#
flush;
spdflush;

## Some sample SPDs for use racoon
#
# spdadd 10.10.100.1 10.10.100.2 any -P out ipsec
#    esp/transport//require;
#
# spdadd 10.10.100.2 10.10.100.1 any -P in ipsec
#    esp/transport//require;
#


spdadd 2001:470:1f09:784::15 2a01:348:6:142::2 any -P out ipsec
        ah/transport//require;

spdadd 2a01:348:6:142::2 2001:470:1f09:784::15 any -P in ipsec
        ah/transport//require;

Then, I've configured the racoon daemon to know to negotiate an SA for both directions of the connection:

Code: 
#
# NOTE: This file will not be used if you use racoon-tool(8) to manage your
# IPsec connections. racoon-tool will process racoon-tool.conf(5) and
# generate a configuration (/var/lib/racoon/racoon.conf) and use it, instead
# of this file.
#
# Simple racoon.conf
#
#
# Please look in /usr/share/doc/racoon/examples for
# examples that come with the source.
#
# Please read racoon.conf(5) for details, and alsoread setkey(8).
#
#
# Also read the Linux IPSEC Howto up at
# http://www.ipsec-howto.org/t1.html
#

path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

remote 2a01:348:6:142::2 {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

#remote 172.31.1.1 {
#        exchange_mode main,aggressive;
#        proposal {
#                encryption_algorithm 3des;
#                hash_algorithm sha1;
#                authentication_method pre_shared_key;
#                dh_group modp1024;
#        }
#        generate_policy off;
#}
#

sainfo address 2001:470:1f09:784::15[any] any address 2a01:348:6:142::2[any] any {
#        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}


sainfo address 2a01:348:6:142::2 any address 2001:470:1f09:784::15 any {
#        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

On the windows client, I've defined a "Conenction Security Rule" in the firewall dialog that requires inbound and outbound pre-shared-key authentication for any host in the server's subnet. The PSKs on both ends are the same.

Doing this, I can start the racoon daemon, and when I do a ping connection, I get a negotiation success, and a ping response!

Code: 
2010-03-15 14:11:46: INFO: respond new phase 1 negotiation: 2001:470:1f09:784::15[500]<=>2a01:348:6:142::2[500]
2010-03-15 14:11:46: INFO: begin Identity Protection mode.
2010-03-15 14:11:46: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
2010-03-15 14:11:46: INFO: received Vendor ID: FRAGMENTATION
2010-03-15 14:11:46: INFO: ISAKMP-SA established 2001:470:1f09:784::15[500]-2a01:348:6:142::2[500] spi:16f4442d2c017efa:f31b10b9fd0bd39e
2010-03-15 14:11:46: INFO: respond new phase 2 negotiation: 2001:470:1f09:784::15[500]<=>2a01:348:6:142::2[500]
2010-03-15 14:11:46: ERROR: not matched
2010-03-15 14:11:46: ERROR: not matched
2010-03-15 14:11:46: ERROR: not matched
2010-03-15 14:11:46: INFO: IPsec-SA established: AH/Transport 2a01:348:6:142::2[0]->2001:470:1f09:784::15[0] spi=33552302(0x1fff7ae)
2010-03-15 14:11:46: INFO: IPsec-SA established: AH/Transport 2001:470:1f09:784::15[500]->2a01:348:6:142::2[500] spi=184587366(0xb009466)

This is mostly epic win. The only thing I need to be able to do now is to configure certificate-based authentication, fiddle to get ESP working, allow the server to accept connections from anywhere and test it on a linux client.

I've proved it can work though. :)

*edit* just got on-the-fly policy generation and ESP working.
 
Last edited:
Yo,
Couldnt work on it today, real work and stuffs! But just had much the same sucess as you after dumping openswan for ipsec-tools and racoon! Think the thing holding back the conf was openswan (and NAT-T on my end).

Are all your clients going to be IPv6?

Niceone anyway!

//TrX
 
Clients will be IPv6, yes.

Pretty much got everything working now as I want. The only stumbling block is that I can't use a PSK with a subnet specification, but given that I'm planning on using PKI certs, this isn't really an issue.
 
PKI is much more scaleable to maintain security if your solution grows anyway!

Sounds good, should definatley blog this if you have one, i'm sure two of us cant be the only people who have been looking for an IPSEC setup like this.

If not/cba I will, mainly for my own reference in future.

//TrX
 
You must log in or register to reply here.
Back
Top Bottom