Thread: [Ipsec-tools-devel] IPSec connection between host (Cent OS 4.2) to host (Solaris9)
Brought to you by:
mit_warlord,
netbsd
From: Rafiqul A. <raf...@gm...> - 2006-02-06 20:01:18
|
Hello all, I am trying to configure the IPSec connection between RedHAT, and Solaris - host to host in Transport mode. I have configured the RedHat host as follow= s (/etc/setkey.conf): flush; spdflush; add <redhat IP> <Solaris IP> ah 0x200 -A hmac-md5 <128 bit Keys:K1> add <Solaris IP> <redhat IP> ah 0x300 -A hmac-md5 <128 bit Keys:K2> spdadd <redhat IP> <Solaris IP> any -P out ipsec ah/transport//require; apdadd <Solaris IP> <redhat IP> any -P in ipsec ah/transport//require; And then I loaded the above file, using /sbin/setkey -f /etc/setkey.conf On the Solaris side, I configured as follows (/etc/inet/ipsecinit.conf): {saddr <solaris IP> daddr <redhat IP>} apply {auth_algs MD5 sa shared} {saddr <redhat IP> daddr <solaris IP>} permit {auth_algs MD5} Loaded above config, by using >ipsecconf -f /etc/inet/ipsecinit.conf >/etc/init.d/inetinit start (I thought I had to do it since I am not rebooting ?) and then, > ipseckey ipseckey> add ah spi 0x200 src <solaris IP> dst <redhat IP> authalg HMAC-MD= 5 authkey <K1> ipseckey> add ah spi 0x300 src <redhat IP> dst <solaris IP> authalg HMAC-MD= 5 authkey <K2> After that, I cannot ping each other...sort of loose the connection wheneve= r I try to load any configuration on each side. Can anybody help me out on figuraing out this ? Please note, redhat to redhat (host to host) works well for me, although I did not try solaris to solaris (host to host). But I really need to make redhat to solaris for now= . Thanks for your help....... Rafi -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-06 20:30:21
|
On Mon, Feb 06, 2006 at 02:01:14PM -0600, Rafiqul Ahsan wrote: > add <redhat IP> <Solaris IP> ah 0x200 -A hmac-md5 <128 bit Keys:K1> > > add <Solaris IP> <redhat IP> ah 0x300 -A hmac-md5 <128 bit Keys:K2> ... > ipseckey> add ah spi 0x200 src <solaris IP> dst <redhat IP> authalg > HMAC-MD5 authkey <K1> > > ipseckey> add ah spi 0x300 src <redhat IP> dst <solaris IP> authalg > HMAC-MD5 authkey <K2> Those SPIs don't match. In the first case, you've used SPI 0x200 and K1 for packets from RedHat to Solaris. In the second case, you've used SPI 0x200 and K1 for packets from Solaris to RedHat. Once you've fixed that, try pinging from Red Hat to Solaris, and from Solaris to Red Hat, and checking you see AH packets in both directions (with tcpdump and/or snoop). If so, you know the only thing likely to be wrong is the SPI and/or keys. Manual keying is not very good practice - although with legacy systems it's sometimes all you can get to work. Regards, Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-06 22:00:06
|
Brian, and all... looks like things are working....I was able to ping from both machine...after I fix the SPI mismatch. Now, here is the snoop output from Solaris, when I was pining from Linux to Solaris...where are those AH packet ? Can you please see the out put log below ? and please help me understanding about it... FYI : v210ap1 is Solaris, and 10.19.171.30 is my linux machine... Thanks for your reply..again. rafi 10.19.171.30 -> v210ap1 ICMP Echo request (ID: 48482 Sequence number: 15) v210ap1 -> 10.19.171.30 ICMP Echo reply (ID: 48482 Sequence number: 15= ) v210ap1 -> 173.6.64.12 TELNET R port=3D46287 v210ap1 -> 173. 173.6.64.12 -> v210ap1 TELNET C port=3D46287 v210ap1 -> 173.6.64.12 TELNET R port=3D46287 173.6.64.12 -> v210 173.6.64.12 -> v210ap1 TELNET C port=3D46287 10.19.171.30 -> v210ap1 ICMP Echo request (ID: 48482 Sequence number: 16) v210ap1 -> 10.19.171.30 ICMP Echo reply (ID: 48482 Sequence number: 16= ) v210ap1 -> 173.6.64.12 TELNET R port=3D46287 v210ap1 -> 173. 173.6.64.12 -> v210ap1 TELNET C port=3D46287 v210ap1 -> 173.6.64.12 TELNET R port=3D46287 173.6.64.12 -> v210 173.6.64.12 -> v210ap1 TELNET C port=3D46287 ? -> (multicast) ETHER Type=3D022C (LLC/802.3), size =3D 53 byt= es 10.19.171.30 -> v210ap1 ICMP Echo request (ID: 48482 Sequence number: 17) v210ap1 -> 10.19.171.30 ICMP Echo reply (ID: 48482 Sequence number: 17= ) v210ap1 -> 173.6.64.12 TELNET R port=3D46287 v210ap1 -> 173. 173.6.64.12 -> v210ap1 TELNET C port=3D46287 v210ap1 -> 173.6.64.12 TELNET R port=3D46287 173.6.64.12 -> v210 173.6.64.12 -> v210ap1 TELNET C port=3D46287 10.19.171.30 -> v210ap1 ICMP Echo request (ID: 48482 Sequence number: 18) v210ap1 -> 10.19.171.30 ICMP Echo reply (ID: 48482 Sequence number: 18= ) v210ap1 -> 173.6.64.12 TELNET R port=3D46287 v210ap1 -> 173. 173.6.64.12 -> v210ap1 TELNET C port=3D46287 v210ap1 -> 173.6.64.12 TELNET R port=3D46287 173.6.64.12 -> v210 173.6.64.12 -> v210ap1 TELNET C port=3D46287 ? -> (multicast) ETHER Type=3D022C (LLC/802.3), size =3D 53 byt= es 10.19.171.30 -> v210ap1 ICMP Echo request (ID: 48482 Sequence number: 19) v210ap1 -> 10.19.171.30 ICMP Echo reply (ID: 48482 Sequence number: 19= ) v210ap1 -> 173.6.64.12 TELNET R port=3D46287 v210ap1 -> 173. On 2/6/06, Brian Candler <B.C...@po...> wrote: > > On Mon, Feb 06, 2006 at 02:01:14PM -0600, Rafiqul Ahsan wrote: > > add <redhat IP> <Solaris IP> ah 0x200 -A hmac-md5 <128 bit Keys:K1> > > > > add <Solaris IP> <redhat IP> ah 0x300 -A hmac-md5 <128 bit Keys:K2> > ... > > ipseckey> add ah spi 0x200 src <solaris IP> dst <redhat IP> authalg > > HMAC-MD5 authkey <K1> > > > > ipseckey> add ah spi 0x300 src <redhat IP> dst <solaris IP> authalg > > HMAC-MD5 authkey <K2> > > Those SPIs don't match. In the first case, you've used SPI 0x200 and K1 > for > packets from RedHat to Solaris. In the second case, you've used SPI 0x200 > and K1 for packets from Solaris to RedHat. > > Once you've fixed that, try pinging from Red Hat to Solaris, and from > Solaris to Red Hat, and checking you see AH packets in both directions > (with > tcpdump and/or snoop). If so, you know the only thing likely to be wrong > is > the SPI and/or keys. > > Manual keying is not very good practice - although with legacy systems > it's > sometimes all you can get to work. > > Regards, > > Brian. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-06 22:25:56
|
On Mon, Feb 06, 2006 at 04:00:01PM -0600, Rafiqul Ahsan wrote: > Now, here is the snoop output from Solaris, when I was pining from > Linux to Solaris...where are those AH packet ? Is that 'snoop' output? I don't trust it. Try using 'tcpdump' on the Linux side instead: # tcpdump -i eth0 -n -s1500 Add -v or -X for more detailled display. As I'm sure you realise, AH is the Authentication Header. No encryption takes place; just an extra signature is added to each packet to validate that the packet really was sent from where it claims to be from. If you want to encrypt, so that a packet sniffer like tcpdump/snoop cannot see the content of the packets, then you want ESP instead. Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-06 22:48:58
|
Got it.... I see AH in tcpdump output on the Linux. I am not able to issue tcpdump command on the solaris machine (solaris could not find it either /usr/sbin, or /usr/bin...). My next experiment would be to add ESP with 3des algorithm, and AH with SHA alg. Many many thanks !!!! Rafi On 2/6/06, Brian Candler <B.C...@po...> wrote: > > On Mon, Feb 06, 2006 at 04:00:01PM -0600, Rafiqul Ahsan wrote: > > Now, here is the snoop output from Solaris, when I was pining from > > Linux to Solaris...where are those AH packet ? > > Is that 'snoop' output? I don't trust it. Try using 'tcpdump' on the Linu= x > side instead: > > # tcpdump -i eth0 -n -s1500 > > Add -v or -X for more detailled display. > > As I'm sure you realise, AH is the Authentication Header. No encryption > takes place; just an extra signature is added to each packet to validate > that the packet really was sent from where it claims to be from. > > If you want to encrypt, so that a packet sniffer like tcpdump/snoop canno= t > see the content of the packets, then you want ESP instead. > > Brian. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Rafiqul A. <raf...@gm...> - 2006-02-07 21:22:43
|
I was succesfull in configuaring AH with both alg, MD5, and SHA1. When I tr= y to add Encryption - I get a problem...here is what I am doing . In Linux, here is my config /etc/setkey.con flush; spdflush; add <Linux IP> <Solaris IP> ah 0x200 -A hmac-sha1 <Key1> add <Solaris IP> <Linux IP> ah 0x300 -A hmac-sha1 <Key2> add <Linux IP> <Solaris IP> esp 0x201 -E 3des-cbc <Key3> add <Solaris IP> <Linux IP> esp 0x301 -E rdes-cbc <Key4> apdadd <Linux IP> <Solaris IP> any -P out ipsec esp/transport//require ah/transport//require; spdadd <Solaris IP> <Linux IP> any -P in ipsec esp/transport//require ah/transport//require; So as usually, I did "/sbin/setkey -f /etc/setkey.conf" At Solaris, My /etc/inet/ipsecinit.conf is {saddr <Solaris IP> daddr <Linux IP>} apply {encr_algs 3des-cbc encr_auth_algs SHA1 sa shared} {saddr <Linux IP> daddr <Solaris IP>} permit {encr_algs 3des-cbc encr_auth_algs SHA1} As usually I did, ipseconf -a /etc/inet/ipsecinit.conf (checked with ipseconf..looks like the policy updated) Here is what command I issued : >ipseckey ipseckey> add ah spi 0x200 src <Linux IP> dst <Solaris IP> auth_alg HMAC-SHA1 authkey <Key1> ipseckey> add ah spi 0x300 src <Solaris IP> dst <Linux IP> auth_alg HMAC-SHA1 authkey <Key 2> ipseckey> add esp spi 0x201 src <Linux IP> dst <Solaris IP> encr_alg 3des-cbc encrkey <Key 3> ipseckey> add esp spi 0x301 src <Solaris IP> dst <Linux IP> encr_alg 3des-cbc encrkey <Key 4> ipseckey> dump shows me all the correct keys (Key1, and Key2), but Key3, and Key4 few digits different than what I enetered. And I repeated this, the result is consistent. Also, after that I can ping from Linux to Solaris, but I cannot ping from Solaris to linux. So, I am not sure if this is the right way to execite ipseckey in Solaris for AH, ESP IPSec connection. I am also doubtfull about /etc/inet/ipsecinit.conf..is that right ? Can anybody help me please ? I would really appreciate it very much.... Awaits your suggestion... Thanks Rafi On 2/6/06, Rafiqul Ahsan <raf...@gm...> wrote: > > Got it.... > I see AH in tcpdump output on the Linux. I am not able to issue tcpdump > command on the solaris machine (solaris could not find it either /usr/sbi= n, > or /usr/bin...). > > My next experiment would be to add ESP with 3des algorithm, and AH with > SHA alg. > > Many many thanks !!!! > > Rafi > > > On 2/6/06, Brian Candler <B.C...@po...> wrote: > > > > On Mon, Feb 06, 2006 at 04:00:01PM -0600, Rafiqul Ahsan wrote: > > > Now, here is the snoop output from Solaris, when I was pining from > > > Linux to Solaris...where are those AH packet ? > > > > Is that 'snoop' output? I don't trust it. Try using 'tcpdump' on the > > Linux > > side instead: > > > > # tcpdump -i eth0 -n -s1500 > > > > Add -v or -X for more detailled display. > > > > As I'm sure you realise, AH is the Authentication Header. No encryption > > takes place; just an extra signature is added to each packet to validat= e > > that the packet really was sent from where it claims to be from. > > > > If you want to encrypt, so that a packet sniffer like tcpdump/snoop > > cannot > > see the content of the packets, then you want ESP instead. > > > > Brian. > > > > > > -- > Rafiqul Ahsan 630-717-1698(h) > 2120 Periwinkle Ln 630-689-1457(h) > Naperville, IL 60540 847-812-6176(c) > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-07 21:52:39
|
On Tue, Feb 07, 2006 at 03:22:37PM -0600, Rafiqul Ahsan wrote: > I was succesfull in configuaring AH with both alg, MD5, and SHA1. When > I try to add Encryption - I get a problem...here is what I am doing . I suggest you run ESP without AH. That's the most common way of operating and good enough for most people - if you don't have the ESP key you can't modify the packet without turning it into garbage, so it's effectively authenticated. According to RFC 4301: "IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. Note that ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.)" If you really need ESP with AH, then you'll need to read the manual pages and RFCs more carefully, and to understand the various ways in which ESP and AH can be combined (i.e. combined or nested) The simplest is combined mode, where ESP provides both encryption and integrity. Under the "EXAMPLES" section in the setkey manpage I see this: add 10.0.11.41 10.0.11.33 esp 0x10001 -E des-cbc 0x3ffe05014819ffff -A hmac-md5 "authentication!!" ; As for the Solaris end, you'll have to read their documentation. But as I say, this offers little benefit over just using ESP with an encrytion key. Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-07 22:33:37
|
Brian, and all.. Thanks, I was able to do ESP only. But I may have to do both ESP, and AH.. According to the example for combined , I have seen setkey man pages too - does this mean we have to create two separate security associations , for each direction ? like spi has to be different then for each direction - right ? I found in Solaris something like this --- add esp spi random-number src addr dst addr auth_alg HMAC-SHA1 encr_alg 3des-cbc authkey <Key1> encrkey <Key2> I have to repeast above for each direction.... I actually tried with above - Linux, and Solaris config - does not seem to be working... Can you please refer some RFCs ? Where I can get it ? Thanks for your reply.... Rafi On 2/7/06, Brian Candler <B.C...@po...> wrote: > > On Tue, Feb 07, 2006 at 03:22:37PM -0600, Rafiqul Ahsan wrote: > > I was succesfull in configuaring AH with both alg, MD5, and SHA1. > When > > I try to add Encryption - I get a problem...here is what I am doing = . > > I suggest you run ESP without AH. That's the most common way of operating > and good enough for most people - if you don't have the ESP key you can't > modify the packet without turning it into garbage, so it's effectively > authenticated. According to RFC 4301: > > "IPsec implementations MUST support ESP and MAY > support AH. (Support for AH has been downgraded to MAY because > experience has shown that there are very few contexts in which ESP > cannot provide the requisite security services. Note that ESP can be > used to provide only integrity, without confidentiality, making it > comparable to AH in most contexts.)" > > If you really need ESP with AH, then you'll need to read the manual pages > and RFCs more carefully, and to understand the various ways in which ESP > and > AH can be combined (i.e. combined or nested) > > The simplest is combined mode, where ESP provides both encryption and > integrity. Under the "EXAMPLES" section in the setkey manpage I see this: > > add 10.0.11.41 10.0.11.33 esp 0x10001 > -E des-cbc 0x3ffe05014819ffff > -A hmac-md5 "authentication!!" ; > > As for the Solaris end, you'll have to read their documentation. But as I > say, this offers little benefit over just using ESP with an encrytion key= . > > Brian. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-08 09:32:51
|
On Tue, Feb 07, 2006 at 04:33:33PM -0600, Rafiqul Ahsan wrote: > Thanks, I was able to do ESP only. But I may have to do both ESP, and > AH.. Why? If you know so much about cryptography that you can override the expert opinion expressed in RFC 4301, then I'm sure you can work out the details for yourself. > According to the example for combined , I have seen setkey man pages > too - does this mean we have to create two separate security > associations , for each direction ? like spi has to be different then > for each direction - right ? Yes. One SA for A to B, one for B to A. But I don't know what spd statements you'd need; perhaps just a single esp//transport. As I say, if you're going to do something unusual and not normally required, then I'm afraid you're likely to be on your own in getting it to work. In any case, if you're doing manual keying you're not using ipsec-tools, so you'd be better off asking for help elsewhere (e.g. on a Linux networking list, or on a KAME project mailing list, since KAME is the basis of the Linux IPSEC stack I believe, and they'll know what all the setkey options do) > Can you please refer some RFCs ? Where I can get it ? A number of sites, including www.rfc-editor.org although if you had just typed "RFC 4301" into Google you would have found it instantly. RFC 4301 to 4309 are the most recent core specs. However, I'd be the first to admit that the IPSEC RFC's are not the most approachable documents; they are formal specifications, and they expect a good understanding of the fundamentals of cryptography. You'd probably be better off buying a good book on the subject. I don't have one I can recommend specifically on IPSEC, but for background cryptography Bruce Schneier's "Applied Cryptography" is hard to beat. HTH, Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-08 21:24:43
|
This idea works with single spd statement esp//transport. However if I use two statement both esp, and ah - in Linux when I ping it says process not running. Anyway, with esp, ah nested combined configuration on both Linx (/etc/setkey.conf), and Solaris (/etc/inet/ipseckey) - I was successfully able to configure Linux-Solaris esp/ah combined IPSec connection. I tested by pinging each other - and it does. However, I tried to capture the traffi= c between these two hosts using tcpdump - I can only see ESP, I could not see AH - is it because tcpdump ? Any other utility you suggest to capture both ESP, and AH Headers ? Thanks for all your help on resolving my issues. Rafi On 2/8/06, Brian Candler <B.C...@po...> wrote: > > On Tue, Feb 07, 2006 at 04:33:33PM -0600, Rafiqul Ahsan wrote: > > Thanks, I was able to do ESP only. But I may have to do both ESP, an= d > > AH.. > > Why? If you know so much about cryptography that you can override the > expert > opinion expressed in RFC 4301, then I'm sure you can work out the details > for yourself. > > > According to the example for combined , I have seen setkey man pages > > too - does this mean we have to create two separate security > > associations , for each direction ? like spi has to be different the= n > > for each direction - right ? > > Yes. One SA for A to B, one for B to A. But I don't know what spd > statements > you'd need; perhaps just a single esp//transport. > > As I say, if you're going to do something unusual and not normally > required, > then I'm afraid you're likely to be on your own in getting it to work. > > In any case, if you're doing manual keying you're not using ipsec-tools, > so > you'd be better off asking for help elsewhere (e.g. on a Linux networking > list, or on a KAME project mailing list, since KAME is the basis of the > Linux IPSEC stack I believe, and they'll know what all the setkey options > do) > > > Can you please refer some RFCs ? Where I can get it ? > > A number of sites, including www.rfc-editor.org > although if you had just typed "RFC 4301" into Google you would have foun= d > it instantly. > > RFC 4301 to 4309 are the most recent core specs. However, I'd be the firs= t > to admit that the IPSEC RFC's are not the most approachable documents; > they > are formal specifications, and they expect a good understanding of the > fundamentals of cryptography. You'd probably be better off buying a good > book on the subject. > > I don't have one I can recommend specifically on IPSEC, but for backgroun= d > cryptography Bruce Schneier's "Applied Cryptography" is hard to beat. > > HTH, Brian. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-08 21:38:10
|
On Wed, Feb 08, 2006 at 03:24:34PM -0600, Rafiqul Ahsan wrote: > This idea works with single spd statement esp//transport. However if I > use two statement both esp, and ah - in Linux when I ping it says > process not running. > > > > Anyway, with esp, ah nested combined configuration on both Linx > (/etc/setkey.conf), and Solaris (/etc/inet/ipseckey) - I was > successfully able to configure Linux-Solaris esp/ah combined IPSec > connection. I tested by pinging each other - and it does. However, I > tried to capture the traffic between these two hosts using tcpdump - I > can only see ESP, I could not see AH - is it because tcpdump ? Any > other utility you suggest to capture both ESP, and AH Headers ? That's correct. The authentication information is hidden inside the encrypted ESP payload, so you can't see it with tcpdump. That is, unless you tell tcpdump about your ESP keys, which would allow it to decrypt the packets for display. Under FreeBSD I see in the manpage for tcpdump: -E Use spi@ipaddr algo:secret for decrypting IPsec ESP packets that are addressed to addr and contain Security Parameter Index value spi. This combination may be repeated with comma or newline seperation. But beware the warning later on: The option assumes RFC2406 ESP, not RFC1827 ESP. The option is only for debugging purposes, and the use of this option with a true `secret' key is discouraged. By presenting IPsec secret key onto command line you make it visible to others, via ps(1) and other occasions. In addition to the above syntax, the syntax "file name" may be used to have tcpdump read the provided file in. The file is opened upon receiving the first ESP packet, so any special per- missions that tcpdump may have been given should already have been given up. I don't know if Linux's tcpdump has this feature. However, your packets are being successfully sent using ESP and decrypted at the far end, which basically proves everything is OK. If you want to prove that authentication is working too, you can change the authentication key at one or other side, and watch it stop working. Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-13 18:02:47
|
Recently I configured ESP, & AH combined for Linux to Soalris (host to host= ) IPSec communication. Although I was able to setup the connection, I have fe= w questions on how AH, and ESP works: AH provides the authentication services, and ESP provides the privacy. What I mean is ESP encrypts the payload only, and not the header. But what AH does ? Does this encrypt header ? When we say, ESP, and AH combined - we actually mean the format of the packet is IP+AH+ESP+Payload. Can anybody give me a clearer picture in terms of packet, what is happening with AH, and ESP - and how we are handling the payload, and header for each protocol? Thanks for your reply. Rafiqul On 2/8/06, Brian Candler <B.C...@po...> wrote: > On Wed, Feb 08, 2006 at 03:24:34PM -0600, Rafiqul Ahsan wrote: > > This idea works with single spd statement esp//transport. However if > I > > use two statement both esp, and ah - in Linux when I ping it says > > process not running. > > > > > > > > Anyway, with esp, ah nested combined configuration on both Linx > > (/etc/setkey.conf), and Solaris (/etc/inet/ipseckey) - I was > > successfully able to configure Linux-Solaris esp/ah combined IPSec > > connection. I tested by pinging each other - and it does. However, I > > tried to capture the traffic between these two hosts using tcpdump - > I > > can only see ESP, I could not see AH - is it because tcpdump ? Any > > other utility you suggest to capture both ESP, and AH Headers ? > > That's correct. The authentication information is hidden inside the > encrypted ESP payload, so you can't see it with tcpdump. > > That is, unless you tell tcpdump about your ESP keys, which would allow i= t > to decrypt the packets for display. > > Under FreeBSD I see in the manpage for tcpdump: > > -E Use spi@ipaddr algo:secret for decrypting IPsec ESP packets > that > are addressed to addr and contain Security Parameter Index > value > spi. This combination may be repeated with comma or > newline > seperation. > > But beware the warning later on: > > The option assumes RFC2406 ESP, not RFC1827 ESP. The option > is > only for debugging purposes, and the use of this option > with a > true `secret' key is discouraged. By presenting IPsec > secret > key onto command line you make it visible to others, via > ps(1) > and other occasions. > > In addition to the above syntax, the syntax "file name" ma= y > be > used to have tcpdump read the provided file in. The fil= e > is > opened upon receiving the first ESP packet, so any special > per- > missions that tcpdump may have been given should already > have > been given up. > > I don't know if Linux's tcpdump has this feature. > > However, your packets are being successfully sent using ESP and decrypted > at > the far end, which basically proves everything is OK. If you want to prov= e > > that authentication is working too, you can change the authentication key > at > one or other side, and watch it stop working. > > Brian. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-13 18:56:11
|
On Mon, Feb 13, 2006 at 12:02:42PM -0600, Rafiqul Ahsan wrote: > host) IPSec communication. Although I was able to setup the > connection, I have few questions on how AH, and ESP works: Perhaps you need to get a good book on the subject, or do some googling and read some introductory material out there. > AH provides the authentication services, and ESP provides the privacy. Actually, I think you're using ESP only, but with an encryption algorithm plus an integrity algorithm. Although I believe it's possible to combine AH with ESP, I think I may have confused you by suggesting this in the first instance. > What I mean is ESP encrypts the payload only, and not the header. That depends. If you are using transport mode, then the IP header is not affected. If you are using tunnel mode, then the original IP header is encrypted, and a fresh IP header appended (possibly with different source and destination IPs to the original) > But > what AH does ? Does this encrypt header ? When we say, ESP, and AH > combined - we actually mean the format of the packet is > IP+AH+ESP+Payload. AH doesn't encrypt anything. It's an Authentication Header, so just adds a cryptographic checksum to each packet. If you're interested in packet formats, see RFC 4302 for AH, and RFC 4303 for ESP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Top-Level Format of an ESP Packet Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-14 20:09:59
|
Now that I am back trying to get both ah, and esp working, and trying to avoid using nested add in the linux, and solaris. Instead, I am using add for each SA: like in Solaris (/etc/inet/setkey): add ah spi 0x200 src 10.19.171.30 dst 10.19.171.18 authalg sha1 authkey 027baf8c 8f8316ce66c9a28ab6cc5e6ce0c962ba add ah spi 0x300 src 10.19.171.18 dst 10.19.171.30 authalg sha1 authkey 1622e1b6 0f9c358f1c5dfdca5df4951d1bd85693 add esp spi 0x201 src 10.19.171.30 dst 10.19.171.18 encr_alg aes encrkey 07d9039 49121b5ee53cafa7ca56c3f0b add esp spi 0x301 src 10.19.171.18 dst 10.19.171.30 encr_alg aes encrkey 1488c50 e61d3dea8bd9e4dad68cb7fc9 /etc/inet/ipsecinit.conf {saddr 10.19.171.18 daddr 10.19.171.30} apply {encr_algs aes encr_auth_algs sha1 sa shared } {saddr 10.19.171.30 daddr 10.19.171.18} permit {encr_algs aes encr_auth_alg= s sha 1} And in Linux : flush; spdflush; #AH using sha1 160 bits add 10.19.171.30 10.19.171.18 ah 0x200 -A hmac-sha1 0x027baf8c8f8316ce66c9a28ab6cc5e6ce0c962ba; add 10.19.171.18 10.19.171.30 ah 0x300 -A hmac-sha1 0x1622e1b60f9c358f1c5dfdca5df4951d1bd85693; #ESP SAs using aes-cbc 128 bit long keys add 10.19.171.30 10.19.171.18 esp 0x201 -E aes-cbc 0x07d903949121b5ee53cafa7ca56c3f0b; add 10.19.171.18 10.19.171.30 esp 0x301 -E aes-cbc 0x1488c50e61d3dea8bd9e4dad68cb7fc9; #security policies spdadd 10.19.171.30 10.19.171.18 any -P out ipsec esp/transport//require ah/transport//require; spdadd 10.19.171.18 10.19.171.30 any -P in ipsec esp/transport//require ah/transport//require; Result : I can ping from Llinux to Solaris. But I cannot ping from Solaris to Linux. I really need to find out why can I not ping other way around...any body ca= n help me out there ? Regards Rafi On 2/13/06, Brian Candler <B.C...@po...> wrote: > > On Mon, Feb 13, 2006 at 12:02:42PM -0600, Rafiqul Ahsan wrote: > > host) IPSec communication. Although I was able to setup the > > connection, I have few questions on how AH, and ESP works: > > Perhaps you need to get a good book on the subject, or do some googling > and > read some introductory material out there. > > > AH provides the authentication services, and ESP provides the > privacy. > > Actually, I think you're using ESP only, but with an encryption algorithm > plus an integrity algorithm. > > Although I believe it's possible to combine AH with ESP, I think I may > have > confused you by suggesting this in the first instance. > > > What I mean is ESP encrypts the payload only, and not the header. > > That depends. If you are using transport mode, then the IP header is not > affected. If you are using tunnel mode, then the original IP header is > encrypted, and a fresh IP header appended (possibly with different source > and destination IPs to the original) > > > But > > what AH does ? Does this encrypt header ? When we say, ESP, and AH > > combined - we actually mean the format of the packet is > > IP+AH+ESP+Payload. > > AH doesn't encrypt anything. It's an Authentication Header, so just adds = a > cryptographic checksum to each packet. > > If you're interested in packet formats, see RFC 4302 for AH, and RFC 4303 > for ESP. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- > | Security Parameters Index (SPI) | ^Int. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- > | Sequence Number | |ered > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- > | Payload Data* (variable) | | ^ > ~ ~ | | > | | |Conf. > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- > | | Padding (0-255 bytes) | |ered* > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | > | | Pad Length | Next Header | v v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ > | Integrity Check Value-ICV (variable) | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1. Top-Level Format of an ESP Packet > > Brian. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Rafiqul A. <raf...@gm...> - 2006-02-21 22:13:06
|
Dear all, I am in need of configuring setkey.conf at Linux - with port only. I found policy with port at Solaris, as follows: {dport 23} apply {encr_algs aes encr_auth_algs sha1 sa shared} {sport 23} permit {encr_algs aes encr_auth_algs sha1} But cannot find any example on how to configure with ports on Linux. Can you please help me ? Thanks Rafi |
From: Brian C. <B.C...@po...> - 2006-02-21 22:21:49
|
On Tue, Feb 21, 2006 at 04:12:58PM -0600, Rafiqul Ahsan wrote: > > Dear all, > > > > I am in need of configuring setkey.conf at Linux - with port only. I > found policy with port at Solaris, as follows: > > {dport 23} apply {encr_algs aes encr_auth_algs sha1 sa shared} > {sport 23} permit {encr_algs aes encr_auth_algs sha1} > > > > But cannot find any example on how to configure with ports on Linux. > > > > Can you please help me ? Read the setkey manpage: spdadd [-46n] src_range dst_range upperspec policy ; Add an SPD entry. ... src_range dst_range These are selections of the secure communication specified as IPv4/v6 address or IPv4/v6 address range, and it may accompany TCP/UDP port specification. This takes the following form: address address/prefixlen address[port] address/prefixlen[port] prefixlen and port must be decimal number. The square bracket around port is really necessary. They are not manpage metachar- acters. For FQDN resolution, the rules applicable to src and dst apply here as well. |
From: Rafiqul A. <raf...@gm...> - 2006-02-22 21:29:36
|
Brian, and all.. I have configured according to the "man setkey", and man says to specify port only at the policy configuration (see below). However, at Solaris /etc/inet/ipsecinit.sample says we can mention port at /etc/inet/ipceinit.conf file (see below). Result : 1. I am able to ping, and ftp each other, but when I try to capture ftp using tcpdump, I dont see any encryption( I am expecting ftp packet to be encrypted here since I am using port 21)..instead, I see just like a regula= r ftp packet as follows : IP 10.19.171.18.ftp > 10.19.171.30.32806: P 1:32(31) ack 1 win 49232 <nop,nop,ti mestamp 11304416 148936017> 2. When I ping, I dont see encryption either (which is good, because ping does not use port 21). I would appreciate your help on resolving this serious issue.... Awaits your response. Rafi here is Linux setkey.conf file add 10.19.171.30 10.19.171.18 esp 0x200 -E 3des-cbc 0x4a705c81a07f3d6900c7361e356802d9e5ca2a7d62cff851 -A hmac-sha1 0x027baf8c8f8316ce66c9a28ab6cc5e6ce0c962ba; add 10.19.171.18 10.19.171.30 esp 0x300 -E 3des-cbc 0xce87e82c826ec482bfdc0501cb34eed44ca4888892470793 -A hmac-sha1 0x1622e1b60f9c358f1c5dfdca5df4951d1bd85693; spdadd 10.19.171.30[21] 10.19.171.18[21] any -P out ipsec esp/transport//require; spdadd 10.19.171.18[21] 10.19.171.30[21] any -P in ipsec esp/transport//require; ---------------------------------------------------------------------------= -------- here is Solaris ipsecinit.conf file {dport 21} apply {encr_algs 3des encr_auth_algs sha1 sa shared } {sport 21} permit {encr_algs 3des encr_auth_algs sha1} ---------------------------------------------------------------------------= ------- and ipseckey file add esp spi 0x200 src 10.19.171.30 dst 10.19.171.18 authalg sha1 encralg 3des-cb c \ authkey 027baf8c8f8316ce66c9a28ab6cc5e6ce0c962ba \ encrkey 4a705c81a07f3d6900c7361e356802d9e5ca2a7d62cff851 add esp spi 0x300 src 10.19.171.18 dst 10.19.171.30 authalg sha1 encralg 3des-cb c \ authkey 1622e1b60f9c358f1c5dfdca5df4951d1bd85693 \ encrkey ce87e82c826ec482bfdc0501cb34eed44ca4888892470793 On 2/21/06, Brian Candler <B.C...@po...> wrote: > > On Tue, Feb 21, 2006 at 04:12:58PM -0600, Rafiqul Ahsan wrote: > > > > Dear all, > > > > > > > > I am in need of configuring setkey.conf at Linux - with port only. I > > found policy with port at Solaris, as follows: > > > > {dport 23} apply {encr_algs aes encr_auth_algs sha1 sa shared} > > {sport 23} permit {encr_algs aes encr_auth_algs sha1} > > > > > > > > But cannot find any example on how to configure with ports on Linux. > > > > > > > > Can you please help me ? > > Read the setkey manpage: > > spdadd [-46n] src_range dst_range upperspec policy ; > Add an SPD entry. > ... > src_range > dst_range > These are selections of the secure communication specified as > IPv4/v6 address or IPv4/v6 address range, and it may accompan= y > TCP/UDP port specification. This takes the following form: > > address > address/prefixlen > address[port] > address/prefixlen[port] > > prefixlen and port must be decimal number. The square bracke= t > around port is really necessary. They are not manpage > metachar- > acters. For FQDN resolution, the rules applicable to src and > dst > apply here as well. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-23 08:30:34
|
Well, I'm getting a bit tired of this now. This will be my last reply. > ftp using tcpdump, I dont see any encryption( I am expecting ftp > packet to be encrypted here since I am using port 21)..instead, I see > just like a regular ftp packet as follows : > > IP 10.19.171.18.ftp > 10.19.171.30.32806: P 1:32(31) ack 1 win 49232 ^^^ ^^^^^ actual packet source port: 21 destination port: 32806 > spdadd 10.19.171.30[21] 10.19.171.18[21] any -P out ipsec > esp/transport//require; > spdadd 10.19.171.18[21] 10.19.171.30[21] any -P in ipsec > esp/transport//require; policy definition source port: 21 destination port: 21 Spot the mismatch? Let me say the following, as I think far too much noise has been generated on this thread over the last few weeks. This list is for the development of the *ipsec-tools* software package, which implements Internet Key Exchange (IKE). This means that: (1) Any questions about Solaris IPSEC configuration are *off topic* for this list. Try the sun-managers list. (2) Any questions about manual keying are *off topic* for this list. Try the KAME list, or a Linux networking list. Whilst some general IPSEC discussion does take place here, and also it is reasonable to ask for help debugging *key exchange* problems between ipsec-tools and some other IKE implementation, we can't sit here all day and attempt to build your solution for you, especially when that solution does not involve ipsec-tools at all. I think there comes a point where you have to do your own research - sorry. Of course, I can't speak on behalf of any other member of this list. But if anyone disagrees with me, I'm more than happy for them to answer your questions for you. I won't any more. Regards, Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-24 05:12:34
|
Thanks Brian, I understand. Also your solution was helpful. I will try not to place any issues that are not related to ipsec-tool package. Sorry for the inconvenience, and thank you so much for your help. R On 2/23/06, Brian Candler <B.C...@po...> wrote: > > Well, I'm getting a bit tired of this now. This will be my last reply. > > > ftp using tcpdump, I dont see any encryption( I am expecting ftp > > packet to be encrypted here since I am using port 21)..instead, I se= e > > just like a regular ftp packet as follows : > > > > IP 10.19.171.18.ftp > 10.19.171.30.32806: P 1:32(31) ack 1 win 49232 > ^^^ ^^^^^ > > actual packet > source port: 21 > destination port: 32806 > > > spdadd 10.19.171.30[21] 10.19.171.18[21] any -P out ipsec > > esp/transport//require; > > spdadd 10.19.171.18[21] 10.19.171.30[21] any -P in ipsec > > esp/transport//require; > > policy definition > source port: 21 > destination port: 21 > > Spot the mismatch? > > Let me say the following, as I think far too much noise has been generate= d > on this thread over the last few weeks. > > This list is for the development of the *ipsec-tools* software package, > which implements Internet Key Exchange (IKE). This means that: > > (1) Any questions about Solaris IPSEC configuration are *off topic* for > this > list. Try the sun-managers list. > > (2) Any questions about manual keying are *off topic* for this list. Try > the > KAME list, or a Linux networking list. > > Whilst some general IPSEC discussion does take place here, and also it is > reasonable to ask for help debugging *key exchange* problems between > ipsec-tools and some other IKE implementation, we can't sit here all day > and > attempt to build your solution for you, especially when that solution doe= s > not involve ipsec-tools at all. I think there comes a point where you hav= e > to do your own research - sorry. > > Of course, I can't speak on behalf of any other member of this list. But > if > anyone disagrees with me, I'm more than happy for them to answer your > questions for you. I won't any more. > > Regards, > > Brian. > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Dan M. <da...@su...> - 2006-02-06 20:34:33
|
On Mon, Feb 06, 2006 at 02:01:14PM -0600, Rafiqul Ahsan wrote: > > On the Solaris side, I configured as follows (/etc/inet/ipsecinit.conf): > > {saddr <solaris IP> daddr <redhat IP>} apply {auth_algs MD5 sa shared} > {saddr <redhat IP> daddr <solaris IP>} permit {auth_algs MD5} Brian Candler already pointed out the mismatched SPI problem. Some other things: - DO NOT run /etc/init.d/inetinet again. The ipsecconf(1m) command is sufficient, and the /etc/init.d/inetinit will load /etc/inet/ipsecinit.conf with ipsecconf(1m) at boot time. - In S9 and later, you can use the cleaner bidirectional syntax: # One line for both directions... { laddr <solaris> raddr <redhat> } ipsec { auth_algs md5 sa shared} Hope this helps. -- Daniel L. McDonald - Solaris Networking & Security Engineering Mail: da...@su... | * MY OPINIONS ARE NOT NECESSARILY SUN'S! * 1 Network Drive Burlington, MA |"rising falling at force ten http://blogs.sun.com/danmcd/ | we twist the world and ride the wind" - Rush |
From: Rafiqul A. <raf...@gm...> - 2006-02-06 21:16:12
|
Thanks to Brian, and Dan for your valued comments. I will definitely fix th= e SPI mispatch problem but there is one basic problem I see. And I think it i= s worth mentioning here... Without touching Solaris (without config, or loading config), if I load the config on the Linux side, I loose connectivity with Solaris. So, I think this is a problem, and is certainly not related to SPI mismatch or anything= , because I am not doing anything on Solaris (I made Solaris clean by fusshin= g out the records from SAD/SPD. Any suggestion why it is happening ? Thanks again for helping on this new issue... Rafi On 2/6/06, Dan McDonald <da...@su...> wrote: > > On Mon, Feb 06, 2006 at 02:01:14PM -0600, Rafiqul Ahsan wrote: > > > > On the Solaris side, I configured as follows (/etc/inet/ipsecinit.conf)= : > > > > {saddr <solaris IP> daddr <redhat IP>} apply {auth_algs MD5 sa shared} > > {saddr <redhat IP> daddr <solaris IP>} permit {auth_algs MD5} > > Brian Candler already pointed out the mismatched SPI problem. > > Some other things: > > - DO NOT run /etc/init.d/inetinet again. The ipsecconf(1m) comman= d > is sufficient, and the /etc/init.d/inetinit will load > /etc/inet/ipsecinit.conf with ipsecconf(1m) at boot time. > > - In S9 and later, you can use the cleaner bidirectional syntax: > > # One line for both directions... > { laddr <solaris> raddr <redhat> } ipsec { auth_algs md5 sa shared= } > > Hope this helps. > > -- > Daniel L. McDonald - Solaris Networking & Security Engineering > Mail: da...@su... | * MY OPINIONS ARE NOT NECESSARILY > SUN'S! * > 1 Network Drive Burlington, MA |"rising falling at force ten > http://blogs.sun.com/danmcd/ | we twist the world and ride the wind" = - > Rush > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |
From: Brian C. <B.C...@po...> - 2006-02-06 21:22:34
|
On Mon, Feb 06, 2006 at 03:15:53PM -0600, Rafiqul Ahsan wrote: > Without touching Solaris (without config, or loading config), if I > load the config on the Linux side, I loose connectivity with Solaris. Yes, of course you will. Firstly, you told the Linux box to ignore all packets from the Solaris box unless they are signed with AH (Authentication Header). Secondly, you didn't tell the Solaris box about your SPI. It will drop on the floor all AH/ESP packets which arrive with an unknown SPI. Brian. |
From: Rafiqul A. <raf...@gm...> - 2006-02-06 21:23:10
|
I just wanted to clarify my last email with this example : My /etc/setkey.conf file has ... flush; spdflush; add <redhat IP> <Solaris IP> ah 0x200 -A hmac-md5 <128 bit Keys:K1> add <Solaris IP> <redhat IP> ah 0x300 -A hmac-md5 <128 bit Keys:K2> spdadd <redhat IP> <Solaris IP> any -P out ipsec ah/transport//require; apdadd <Solaris IP> <redhat IP> any -P in ipsec ah/transport//require; And then I loaded the above file, using /sbin/setkey -f /etc/setkey.conf I immediately loose connection with Solaris. I cannot ping anymore, and onl= y can ping if I flush out this. My Solaris is not configured at this point yet... Similarly on the Solaris side, On the Solaris side, I configured as follows (/etc/inet/ipsecinit.conf): {saddr <solaris IP> daddr <redhat IP>} apply {auth_algs MD5 sa shared} {saddr <redhat IP> daddr <solaris IP>} permit {auth_algs MD5} whenever I load this config file, using ipsecconf - I loos connectivity immediately with Linux, eventhough my linux does not have any config loaded= . Any thoughts on this how to address the problem ? Best Regards Rafi On 2/6/06, Rafiqul Ahsan <raf...@gm...> wrote: > > Thanks to Brian, and Dan for your valued comments. I will definitely fix > the SPI mispatch problem but there is one basic problem I see. And I thin= k > it is worth mentioning here... > > Without touching Solaris (without config, or loading config), if I load > the config on the Linux side, I loose connectivity with Solaris. So, I th= ink > this is a problem, and is certainly not related to SPI mismatch or anythi= ng, > because I am not doing anything on Solaris (I made Solaris clean by fussh= ing > out the records from SAD/SPD. > > Any suggestion why it is happening ? > > Thanks again for helping on this new issue... > > Rafi > > > On 2/6/06, Dan McDonald <da...@su...> wrote: > > > > On Mon, Feb 06, 2006 at 02:01:14PM -0600, Rafiqul Ahsan wrote: > > > > > > On the Solaris side, I configured as follows > > (/etc/inet/ipsecinit.conf): > > > > > > {saddr <solaris IP> daddr <redhat IP>} apply {auth_algs MD5 sa shared= } > > > {saddr <redhat IP> daddr <solaris IP>} permit {auth_algs MD5} > > > > Brian Candler already pointed out the mismatched SPI problem. > > > > Some other things: > > > > - DO NOT run /etc/init.d/inetinet again. The ipsecconf(1m) > > command > > is sufficient, and the /etc/init.d/inetinit will load > > /etc/inet/ipsecinit.conf with ipsecconf(1m) at boot time. > > > > - In S9 and later, you can use the cleaner bidirectional syntax: > > > > # One line for both directions... > > { laddr <solaris> raddr <redhat> } ipsec { auth_algs md5 sa > > shared} > > > > Hope this helps. > > > > -- > > Daniel L. McDonald - Solaris Networking & Security Engineering > > Mail: da...@su... | * MY OPINIONS ARE NOT NECESSARILY > > SUN'S! * > > 1 Network Drive Burlington, MA |"rising falling at force ten > > http://blogs.sun.com/danmcd/ | we twist the world and ride the wind= " > > - Rush > > > > > > -- > Rafiqul Ahsan 630-717-1698(h) > 2120 Periwinkle Ln 630-689-1457(h) > Naperville, IL 60540 847-812-6176(c) > -- Rafiqul Ahsan 630-717-1698(h) 2120 Periwinkle Ln 630-689-1457(h) Naperville, IL 60540 847-812-6176(c) |