Re: [strongSwan] left vs. right in ipsec.conf

[Graham Hudspith]

Justin,

I've found it useful in the past to think of "left" as the "local" machine
and "right" as the "remote" machine.

You'll have an ipsec.conf on both machines and the "left" in each file will
refer to the "local" machine where "local" is from that machine's point of
view.

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Enforcing multiple-authentication locally when the remote does not

[Graham Hudspith]

Martin,

On 26 February 2013 12:37, Martin Willi  wrote:

> Hi Graham,
>
> > I've configured the local machine to expect to perform certs
> authentication
> > followed by EAP-AKA.
>
> How did you configure this? I assume the configuration on the initiator
> looks something like:
>
>   rightauth=pubkey
>   leftauth=pubkey
>   leftauth2=eap
>
>
Yes, exactly that.


> > If I then configure the remote to expect certs authentication only *and*
> to
> > not advertise that it supports multiple-authentication exchanges (by
> > setting charon.multiple_authentication to "no" in strongswan.conf), then
> > the tunnel comes up. Not as expected. Not good.
>
> When defining a leftauth, this defines the rule for authenticating
> ourselves to right. It does not imply an constraints for the remote
> side. Beside public key and PSK authentication, this makes sense for
> many EAP methods, where only the client is actually authenticated.
>
> With EAP-AKA (and other mutual EAP methods, such as EAP-SIM or EAP-TLS),
> both peers get actually authenticated with EAP. But just defining
> leftauth does not define such a constraint, and the initiator does not
> insist on the EAP exchange.
>
>
Understood. I think of it as the local (initiator) offering to perform
certs plus additional (eap) authentication and if the remote (i.e. the
SeGW) is happy with just certs only then this is no skin off the local's
nose and the local will happily bring up the tunnel as well. The offer of
an additional authentication round involving eap is only of benefit to the
remote and if the remote chooses to forego that, then who is the local to
argue ?

> Is there any way to configure the local end to demand that
> > multiple-authentication exchanges take place and to reject the tunnel if
> > the remote does not ?
>
> To strictly require the authentication of right with EAP, you can define
> a rightauth2, something like:
>
>   rightauth=pubkey
>   rightauth2=eap
>   leftauth=pubkey
>   leftauth2=eap
>
> This will set up the constraint that the responder first authenticates
> itself with a public key, and then with EAP. If it does not (or a
> non-mutual EAP method is used), the connection attempt fails.
>
>
Hmm, not sure I understand this. What I want is to configure the local to
demand that the remote issue an eap challenge to the local. What I think
you have implemented is that both sides issue eap challenges to each other ?

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Enforcing multiple-authentication locally when the remote does not

[Graham Hudspith]

Hi All,

I've been playing about with "multiple-authentication exchanges" (see RFC
4739).

I've configured the local machine to expect to perform certs authentication
followed by EAP-AKA.

If I configure the remote to expect the same, the tunnel comes up just as
expected. Good.

If I then configure the remote to expect certs authentication only, it
rejects the tunnel setup when the local end attempts the EAP-AKA round
("peer requested EAP, config inacceptable"). Also good.

If I then configure the remote to expect certs authentication only *and* to
not advertise that it supports multiple-authentication exchanges (by
setting charon.multiple_authentication to "no" in strongswan.conf), then
the tunnel comes up. Not as expected. Not good.

So, in the second scenario, the remote (by default) sends the "multiple
auth supported" flag in the IKE_SA_INIT response, the local sends both
the "multiple auth supported" and "another auth follows" flags in the first
IKE_AUTH request and after the second IKE_AUTH request (starting the
EAP-AKA round), the remote end rejects the tunnel attempt because it is not
expecting multiple-authentication exchanges.

In the third scenario, the remote no longer sends the "multiple auth
supported" flag in the IKE_SA_INIT response, the local also does not send
the "multiple auth supported" in the first IKE_AUTH request, the remote is
happy with just the certs-only authentication and the local does not object
either.

Is this correct behaviour ?

Is there any way to configure the local end to demand that
multiple-authentication exchanges take place and to reject the tunnel if
the remote does not ?

Regards,


Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Possible to broadcast packets down each IPsec tunnel from the SeGW ?

[Graham Hudspith]

Hi Iris,


The way I solved this in the end was to write my own program that created a
raw UDP socket. I wanted this socket to be able to send broadcast packets,
so I set the SO_BROADCAST option. I also wanted complete control over
specifying the IP header as well as the UDP contents, so I set the
IP_HDRINCL option.

I then composed my IP+UDP packet (as an array of unsigned char) and then
sent this down the raw socket to the inner IP address of the remote system.
This was running the program on the SeGW itself.

The IP header within my hand-built packet contents left the source IP
address as all-zeros (this was then populated by the Linux kernel on the
way out). The destination IP address was the subnet broadcast address. The
IP checksum was also all-zeros (and was also then populated by the Linux
kernel on the way out). I found it easier to also specify the UDP checksum
as all-zeros (i.e. "no" checksum).

Running wireshark, you can see an ESP packet going from the SeGW to the
remote end. Delving inside the ESP packet encrypted contents, you can see
that the IP destination address was still the broadcast address. So, using
the example numbers from below, I tell the raw socket to send the data to
10.17.0.1, the ESP packet is sent to the real IP address (something like
192.168.50.42), but the IP destination address specified inside the
encrypted ESP data is 10.17.0.255.

So, doing all of this, you can see the broadcast packet being delivered to
the remote end. However, we then found a problem in that the received
packet was being dropped and NOT being delivered to the application running
on the remote system.

We cured this by installing an extra xfrm policy on the remote end when the
IPsec tunnel is established. Something like:

ip xfrm policy add dir in src 0.0.0.0/0 dst 10.17.0.0/24 tmpl src 0.0.0.0
dst 10.17.0.255 proto esp mode tunnel

Of course, when the tunnel is taken down, the policy needs to be removed:

ip xfrm policy delete dir in src 0.0.0.0/0 dst 10.17.0.0/24

This only worked when the remote end was provided with a netmask on tunnel
setup. In this case, the netmask was 255.255.255.0.

This was all a bit of a hack, nothing as elegant as Martin's solution.
However, it got us out of a hole and allowed us to test the reception of
the broadcast packet. We'll leave it up to the SeGW vendor to actually
implement proper delivery of the broadcast packets to all attached clients !

Hope this helps (and makes sense),

Graham


On 24 November 2011 08:52, Iris Su  wrote:

> Hi  Martin,
>
> I'm interested in this topics (broadcast packets down each IPSec tunnel)
> as well. However, I still have some problem about this solution.
>
> Below is my understanding based on Graham's example.
>
>  our strongSwan-based SeGW defines a conn config entry in ipsec.conf
> where IPsec tunnels established using that config are assigned inner IP
> addresses from a pool (e.g. 10.17.0.0/24).
>
> Server may assign an IP (e.g. 10.17.0.1) to client A and assign another IP
> (e.g. 10.17.0.2) to client B.
>
> On Client A, it will have one outgoing xfrm policy -
> src 10.17.0.1/32 dst 0.0.0.0/0 dir out  ..
>  On Client B, it will have one outgoing xfrm policy -
> src 10.17.0.2/32 dst 0.0.0.0/0 dir out  ..
>
> Both client can send out broadcast traffic over tunnel without error
> since the broadcast address (10.17.0.255) is within the outgoing xfrm
> policy.
>
> On the other hand, the server side will have 2 outgoing xfrm policies -
> src 0.0.0.0/0 dst 10.17.0.1/32 dir out  .. to Client A
> src 0.0.0.0/0 dst 10.17.0.2/32 dir out  .. to Client B
> If we create a socket on server side which listen for broadcast
> packet, re-inject the packet to client A and client B, the packet will be
> transfered into a unicast one (with destination IP changed to 10.17.0.1 and
> 10.17.0.2, accordingly), is that correct?
>
> In that case, client A and client B still received a unicast packet, not
> broadcast one.
>
> Please tell me if my understanding correct or not, and let's discuss is it
> possible to send out broadcast packets (with dest address 10.17.0.254) to
> client A and client B.
>
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Possible to broadcast packets down each IPsec tunnel from the SeGW ?

[Graham Hudspith]

Hi All,

This is probably a FAQ, but I'll give it a go anyway ...

Is it possible to send a packet to a subnet's broadcast address on the
secure side of a SeGW and have the packet sent down each IPsec tunnel whose
inner IP address belongs to that subnet ?

For instance, our strongSwan-based SeGW defines a conn config entry in
ipsec.conf where IPsec tunnels established using that config are assigned
inner IP addresses from a pool (e.g. 10.17.0.0/24).

If I run a program on the SeGW that formats up a UDP packet and sends it
directly to one of the IPsec tunnels using that tunnel's inner IP address
(i.e. 10.17.0.8), the UDP packet goes over the tunnel to the remote
endpoint.

However, if I run the same program and specify the address pool's broadcast
address as the destination (i.e. 10.17.0.255), nothing happens. Certainly,
no UDP traffic is sent over the tunnel.

Can anyone shed any light on this please ?

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Checking of certificate CN and subjectAltName against IDr

[Graham Hudspith]

Hi All,

We have a question here concerning verification of the SeGW's certificate by
the local tunnel initiator.

We configure our initiator with the FQDN of the SeGW. The initiator resolves
this FQDN to an IP address and then sends the tunnel setup requests to that
IP address with the IDr set to the FQDN.

The SeGW eventually responds, in an IKE_AUTH, with it's certificate.

The initiator then verifies that certificate.

Now, it is this verification we'd like some insight into.

Obviously, the certificate is checked against the remote end's Root CA that
the initiator has a copy of.

What we'd like to know, if anyone can throw any light on the subject (pun
intended), is the additional checking that takes place.

Does strongSwan (on the initiator) check that the original FQDN/IDr is also
in the certificate ?

If the certificate has only a "subject" and no "subjectAltName", does
strongSwan check that the IDr matches the CN specified in the "subject" of
the certificate ?

If the certificate has both a "subject" and "subjectAltName", does
strongSwan check that the IDr matches EITHER the CN specified in the
"subject" OR one of the multiple "subjectAltName" entries ?

A customer of ours is convinced that if both a "subject" and one (or
more) "subjectAltName" are present, the initiator must check that the IDr
matches (one of) the "subjectAltName" entries AND must also check that the
IDr does NOT match the "subject"'s CN.

I would have thought that as long as the IDr matches EITHER one of the
"subjectAltName" entries OR the "subject"'s CN, then the check has passed.

Hope this makes sense.

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] When is DH re-negotiated ?

[Graham Hudspith]

Martin,

Thanks for the reply. Couple of follow-ons ...


On 24 March 2011 12:15, Martin Willi  wrote:

> > Here, for our initiators, we give this choice to the SeGW by
> > specifying that we accept either (e.g. "aes-sha1-modp1024,aes-sha1!").
>
> > My understanding is that by specifying the above, we are leaving it up
> > to the SeGW to choose whether to always re-negotiate the DH when the
> > CHILD_SA is rekeyed (by sending back to us "aes-sha1-modp1024") or to
> > never re-negotiate the DH when the CHILD_SA is rekeyed (by sending
> > back to us "aes-sha1").
>
> As long as the rekeying is always initiated by the SeGW, your
> understanding is correct.
>
>
In this case, I believe that it is always us (the client) that initiates
rekeying. So, by proposing "aes-sha1-modp1024,aes-sha1!", you could say that
we are giving the SeGW a choice of whether it wants us to perform a DH or
non-DH CHILD_SA rekey ?


> So, if the former, does this mean that a new DH is re-negotiated
> > everytime we rekey the CHILD_SA AND a new DH is re-negotiated
> > everytime we rekey the IKE_SA ?
>
> > If the latter, does this mean that a new DH is re-negotiated ONLY when
> > we rekey the IKE_SA ?
>
> > Finally, if the latter, can the SeGW vary when the DH is re-negotiated
> > (i.e. re-negotiate the DH every THIRD time the CHILD_SA is rekeyed) ?
>
> Yes, yes. And yes ;-).


So, if we propose "aes-sha1-modp1024,aes-sha1!" and the SeGW returns
"aes-sha1" and it is up to us whether or not we actually perform a DH or
non-DH CHILD_SA rekey, it would probably be rude for us to attempt a DH
CHILD_SA rekey when the SeGW has indicated a preference for a non-DH one ?
:-)

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] When is DH re-negotiated ?

[Graham Hudspith]

All,


Hopefully this is a quick answer for someone ?

When we set up a tunnel, we have to specify a DH group along with the
acceptable encryption and authentication algorithms for the IKE_SA
(e.g. "aes-sha-modp1024!").

Is DH re-negotiated everytime we rekey the IKE_SA ?

Also, when we set up a tunnel, we have the option of specifying (or not) the
DH group for when CHILD_SAs are rekeyed. Here, for our initiators, we give
this choice to the SeGW by specifying that we accept either
(e.g. "aes-sha1-modp1024,aes-sha1!").

My understanding is that by specifying the above, we are leaving it up to
the SeGW to choose whether to always re-negotiate the DH when the CHILD_SA
is rekeyed (by sending back to us "aes-sha1-modp1024") or to
never re-negotiate the DH when the CHILD_SA is rekeyed (by sending back to
us "aes-sha1").

So, if the former, does this mean that a new DH is re-negotiated everytime
we rekey the CHILD_SA AND a new DH is re-negotiated everytime we rekey the
IKE_SA ?

If the latter, does this mean that a new DH is re-negotiated ONLY when we
rekey the IKE_SA ?

Finally, if the latter, can the SeGW vary when the DH is re-negotiated (i.e.
re-negotiate the DH every THIRD time the CHILD_SA is rekeyed) ?

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Wilcard matching in ipsec.conf rightid param

[Graham Hudspith]

Dear All,


I wonder if anyone can help me with a strongSwan config issue ?

I'm trying to configure a SeGW running strongSwan (v4.5.1) to accept
incoming tunnel attempts and assign them to different virtual address pools.

I thought the easiest way to do this was to create different config entries
with different address pools specified by the rightsourceip param.

Unfortunately, I can't get the wildcarding to work as I would like, meaning
that I have to have ONE config entry for each client when I would actually
like to reduce these down to the bare minimum using wildcarding.

So, as an example, I have three clients coming in using IDi's of
310751...@foo.abc751.def310.bar.org, 235003...@foo.abc003.def235.bar.org and
235010...@foo.abc010.def235.bar.org

I would like the first of these to have it's own ipsec.conf entry:

conn foo-abc751-def310
...
rightid=*@foo.abc751.def310.bar.org
rightsourceip=10.17.0.0/24
...

and I was hoping to cover the other two with a combined ipsec.conf entry:

conn foo-def235
...
rightid=*@foo.abc*.def235.bar.org
rightsourceip=10.17.1.0/24
...

However, this does not work. When either of these two try to come in, charon
logs that no peer config was found and rejects the tunnel. Instead, I have
to split them up:

conn foo-abc003-def235
...
rightid=*@foo.abc003.def235.bar.org
rightsourceip=10.17.1.0/24
...

conn foo-abc010-def235
...
rightid=*@foo.abc010.def235.bar.org
rightsourceip=10.17.2.0/24
...

I could probably get away with specifying the same address pool in both of
these cases (i.e. 10.17.1.0/24), but I would REALLY like to combine the two
entries.

This also applies to ipsec.secrets, where I want to specify a combined
secret entry:

*@foo.abc*.def235.bar.org : THE secret

rather than split the entries up:

*@foo.abc003.def235.bar.org : THE secret
*@foo.abc010.def235.bar.org : THE secret

Using *@foo.abc???.def235.bar.org would also be perfectly acceptable, but
I've seen no mention of this in the documentation or code.

Does this make sense ? Sound reasonable ?

Or I trying to do things in completely the wrong way (and someone can
suggest a much better way) ?

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] One IPsec client talk to another through the SeGW ?

[Graham Hudspith]

Andreas,

We've solved the problem here. Actually, there never was a problem.

When first chatting to the people here, NO secure communication was
happening.

After your last message, I did a little digging and, as so often happens in
these cases, reality was a little different.

It seems that Hosts A and B were able to ping each other through their IPsec
tunnels via the SeGW. In fact, we can even ssh through the tunnels from Host
A to Host B.

What was NOT happening was reception of UDP traffic sent from Host A to a
specific port on Host B (and vice versa). Once I got them to adjust the
firewall on Host B to open the udp port, everything started working too.

They were confused by the fact that we had already added a firewall rule
allowing all UDP traffic from an IPsec tunnel. They did not realise that
such traffic is decrypted and then sent back through the firewall again,
thus needing the specific UDP port opening too.

Sorry to have wasted your time.

Regards,

Graham.


On 4 March 2011 12:48, Graham Hudspith  wrote:

> Andreas,
>
> Thanks for that. Unfortunately, all of these abstract labels are making my
> head hurt. Let's try some real numbers.
>
> Host A and Host B have local IP addresses in the 192.16.50.xxx subnet.
>
> The SeGW has an unsecure IP address (i.e. on eth0) in the 172.16.xxx.xxx
> subnet and a secure IP address (i.e. on eth1) in the 172.17.xxx.xxx subnet.
>
> The SeGW is configured to hand out virtual IP addresses to Hosts A and B
> using the 10.15.xxx.xxx subnet.
>
> So, we want Host A to be able to talk to other entities in the
> 10.15.xxx.xxx subnet using IPsec (i.e. Host A <-> Host B via SeGW) and ALSO
> we want Host A and Host B to be able to talk to entities on the secure side
> of the SeGW (i.e. other servers on the 172.17.xxx.xxx subnet).
>
> So, currently, on the SeGW we have:
>
> conn a-b-gw
>
> left=segw.foobar.com
> leftsubnet=0.0.0.0/0
> leftfirewall=yes
> rightsourceip=10.15.0.0/24
>
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] One IPsec client talk to another through the SeGW ?

[Graham Hudspith]

Andreas,

Thanks for that. Unfortunately, all of these abstract labels are making my
head hurt. Let's try some real numbers.

Host A and Host B have local IP addresses in the 192.16.50.xxx subnet.

The SeGW has an unsecure IP address (i.e. on eth0) in the 172.16.xxx.xxx
subnet and a secure IP address (i.e. on eth1) in the 172.17.xxx.xxx subnet.

The SeGW is configured to hand out virtual IP addresses to Hosts A and B
using the 10.15.xxx.xxx subnet.

So, we want Host A to be able to talk to other entities in the 10.15.xxx.xxx
subnet using IPsec (i.e. Host A <-> Host B via SeGW) and ALSO we want Host A
and Host B to be able to talk to entities on the secure side of the SeGW
(i.e. other servers on the 172.17.xxx.xxx subnet).

So, currently, on the SeGW we have:

conn a-b-gw

left=segw.foobar.com
leftsubnet=0.0.0.0/0
leftfirewall=yes
rightsourceip=10.15.0.0/24


Does this make sense ?

Regards,

Graham.





On 4 March 2011 10:58, Andreas Steffen wrote:

> this is an easy one:
>
> ipsec.conf of host A:
>
> conn a-b
> left=IP_A
> right=IP_GW
> rightsubnet=IP_B/32
>
> ipsec.conf of gateway GW:
>
> conn a-gw
> left=IP_GW
> leftsubnet=IP_B
> right=IP_A
>
> conn b-gw
> left=IP_GW
> leftsubnet=IP_A
> right=IP_B
>
> ipsec.conf of host B
>
> conn b-a
> left=IP_B
> right=IP_GW
> rightsubnet=IP_A/32
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] One IPsec client talk to another through the SeGW ?

[Graham Hudspith]

All,

Warning - probable noob question coming up ...

We've been using strongSwan quite happily for a couple of years now, with
the IPsec clients connecting to a SeGW and talking to hosts on the secure
side.

Now, however, we have a requirement for one IPsec client to talk to another
IPsec client down one tunnel and looped back at the SeGW through the other
tunnel.

I've had a look through all of the current strongSwan examples but could not
spot one that would mimic this situation.

Is it possible ?

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] SeGW-initiated rekey fails - DH group unacceptable

[Graham Hudspith]

Martin,

Thanks for the swift reply.

On 1 December 2010 13:11, Martin Willi  wrote:

> Hi Graham,
>
> > selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
> > DH group MODP_2048 inacceptable, requesting MODP_1024
>
> > The client sends back N(INVAL_KE) to the server and we then get into
> > an endless cycle of trying to renegotiate the tunnel rekey.
>
> The procedure looks correct so far, but the server should retry rekeying
> with the correct group. What does the server show in its log? Does it
> receive the MODP_1024 request, but retries again with MODP_2048?
>
>
Unfortunately, I was running with minimal tracing on the server. The tracing
on the client would suggest not.


> > is this a bug in strongSwan ?
>
> Looks like.
>
>
Yikes !

Unfortunately, this being a live server and all, I've switch over to using
"esp=aes-sha1" on the server. We'll have to wait ~8 hours to see if that
works. If I get some time next week, I'll try and set up a separate server
and point one of the clients at it.

> the server a hacked version of strongSwan 4.3.2.
>
> Have you tried a more recent version on the server? Haven't found a
> related changelog, but maybe we have fixed this issue in the last
> one-and-a-half years.
>
>
Ah. Unfortunately, our copy of 4.3.2 is heavily hacked and the area that is
hacked was completely re-architected by yourselves in 4.3.3 :-)

We are looking to do some new work with the server code in the New Year and
as a prerequisite, I shall be moving our "hacks" to the latest release of
strongSwan then. I'll let you know what happens.

Cheers,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] SeGW-initiated rekey fails - DH group unacceptable

[Graham Hudspith]

Hi All,

Up till recently, we have been setting up tunnels between client and server
using DH Group 2 (aka MODP_1024). We are starting to transition over to DH
Group 14 (aka MODP_2048) and are coming up against problems. I'm hoping
someone can please shed some light ?

The clients are using a hacked version of strongSwan 4.3.6, the server a
hacked version of strongSwan 4.3.2. We want to support a mixed set of
clients, some using 1024-bit DH and the rest using 2048-bit DH.

The initial tunnels come up fine.

If we set the clients to perform periodic rekeying, everything stays fine.

However, those clients that do NOT perform periodic rekeying are kicking
back when the server eventually lifetime rekeys.

So, when the client sets up the tunnel, it sets:

ike=aes-sha-modp1024!
esp=aes-sha1-modp1024,aes-sha1!


The server config is set up thus:

conn %default

ikelifetime=24h

keylife=8h

rekeymargin=3m

keyingtries=1

keyexchange=ikev2

dpdaction=clear

dpddelay=270

left=foo.bar.com

left...@foo.bar.com

leftsubnet=0.0.0.0/0

esp=aes-sha1-modp2048,aes-sha1-modp1024

mobike=no

auto=add


conn certs-only

authby=rsasig

leftcert=sgw.pem

right...@*.bar.com

rightsourceip=10.13.0.0/24


As the initial tunnel comes up, the client logs:

16[CFG] received proposals:
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

16[CFG] configured proposals:
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

16[CFG] selected proposal:
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024


and:

12[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

12[CFG] configured proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

12[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ


Eight hours later, the server decides to rekey and we see the client log:

08[ENC] parsed CREATE_CHILD_SA request 0 [ N(REKEY_SA) SA No KE TSi TSr ]

08[LIB] size of DH secret exponent: 2047 bits

08[CFG] looking for a child config for 10.13.0.98/32 === 0.0.0.0/0

08[CFG] proposing traffic selectors for us:

08[CFG]  10.13.0.98/32 (derived from dynamic)

08[CFG] proposing traffic selectors for other:

08[CFG]  0.0.0.0/0 (derived from 0.0.0.0/0)

08[CFG]   candidate "conn_1" with prio 5+5

08[CFG] found matching child config "conn_1" with prio 10

08[CFG] selecting proposal:

08[CFG]   no acceptable DIFFIE_HELLMAN_GROUP found

08[CFG] selecting proposal:

08[CFG]   proposal matches

08[CFG] received proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ,
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ

08[CFG] configured proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

08[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ

08[KNL] getting SPI for reqid {3}

08[KNL] got SPI c4beec6b for reqid {3}

08[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024

08[ENC] added payload of type NOTIFY to message


As far as I can make out, the server has proposed "aes-sha1-modp2048" and
"aes-sha1-modp1024" (and extra ones), the client has recognised that it can
accept "aes-sha1-modp1024" and "aes-sha1" and chosen from the proposals to
accept "aes-sha1-modp1024" but then barfed.

The client sends back N(INVAL_KE) to the server and we then get into an
endless cycle of trying to renegotiate the tunnel rekey.

Is this because I have made the client specify
"esp=aes-sha1-modp1024,aes-sha1!"
whereas the server is using "esp=aes-sha1-modp2048,aes-sha1-modp1024" ?

It will be hard to change the "esp" line used by the client, but it is easy
(and desirable) to change the server config. Is there any way I can
configure the server to allow clients to renegotiate their DH during a rekey
and support a mix of clients that want either 1024-bit or 2048-bit DH ?

Or will I have to turn off DH renegotiation during a rekey (by getting the
server to use plain "esp=aes-sha1") until I have managed to get all of the
clients to transition to using 2048-bit DH only ?

Or (and I doubt this) is this a bug in strongSwan ?

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Remove all elements from a hashtable_t

[Graham Hudspith]

Martin, Tobias,

Thanks for the info. I'm glad you confirmed there was no "secret" method of
emptying the hashtable that I'd missed. Also that my suspicions about
invalidating the enumerator if I enumerated-and-removed were correct.

In the end (a Friday afternoon deadline approaching) I decided to simply
free all of the memory consumed by the elements in the hashtable followed by
deleting the hashtable and creating a new one. I would only do this once, on
startup, if a particular sort of error occurred. Not too expensive.

If I get a chance, I'll try out your patch, this may take some weeks to
getting around to though.

Cheers,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Remove all elements from a hashtable_t

[Graham Hudspith]

Hello All,

Quick development question for you (nice on a Friday afternoon).

I've a hashtable_t containing elements and I want to delete all elements
from that hashtable_t. And use the hashtable_t again afterwards.

I can see that hashtable_t supports getting, setting and removing of
elements. These are only applicable if you know the element key before hand.

I can see that hashtable_t also supports an enumerator_t to iterate over the
elements.

It seems to me that the only way to delete all elements in the hashtable_t
is to create an enumerator, enumerate over the elements and call remove for
each element found.

Does the hashtable_t+enumerator_t support this mode of operation ? I'm
worried about pulling the rug out from under the feet of the enumerator_t by
deleting items in the middle of the hashtable_t while I'm enumerating
through it.

Or, is there a better way of doing this ?

If all else fails, it may be better to free all the memory that the elements
point to and to then destroy the hashtable_t and create a new one.

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Options available for using a certificate hierarchy or chain

[Graham Hudspith]

Hello All,

We've been using strongSwan as our IPsec solution for a while now (thanks to
Martin, Andreas and everyone else who has helped us get this far!).

However, we've come up against a problem trying to implement the certificate
hierarchy designed by our device-security guys.

They've come up with a four-certificate chain solution, i.e. self-certified
root CA -> class CA -> group CA -> device certificate.

Unfortunately, when I set up one of our devices to use this chain (i.e. root
CA on the SeGW, class and group CAs and device certificate on the device),
the tunnel is set up fine, but during the initial IKE_AUTH packet sent from
the device to the SeGW, the amount of certificate data sent is so large that
IP fragmentation kicks in and three IP fragments are sent.

We've been warned by our SeGW partners that most SeGWs will not accept IP
fragments due to the security risk and that we need to trim back the data
sent to make everything fit inside one IP packet. This matches up with one
of the answers given in the strongSwan FAQ.

Our PKI guys are incredulous about this situation. They wonder "how have the
IPsec standards managed to get into this situation ?".

Can anyone suggest any solutions ?

I see that hash-and-url is one proposed solution, and although it is
implemented by strongSwan, does anyone have a feel for how widespread that
is among other IPsec SeGW implementations ?

The PKI guys have grudgingly agreed to cut out one level of CA from the
chain, but this would still involve sending one CA plus the device
certificate across in the IKE_AUTH packet, and that would still involve IP
fragmentation.

Another solution would be to preload the intermediate CAs onto the SeGW (as
well as our root CA). This works in our lab, when we also use strongSwan as
a test SeGW, but I've been informed that most of our customers would NOT be
interested in this solution. They want to load ONE root CA onto their SeGW
and nothing else.

Are there any options left ?

Thanks,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Specifying a "relaxed" ESP encryption/authentication proposal for CHILD_SA setup and rekeying

[Graham Hudspith]

Martin,

Thanks for that. Using the config param:

esp=aes-sha1-modp1024,aes-sha1!

and a strongSwan rebuilt with your patch, everything now works. Both SeGWs
are happy. Phew!

Cheers,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Specifying a "relaxed" ESP encryption/authentication proposal for CHILD_SA setup and rekeying

[Graham Hudspith]

Hello All,

We've a problem here with a couple of errant security-gateways when trying
to connect our strongswan-using software to them.

Originally, we specified a connection to use the following params:

ike=aes-sha-modp1024!
esp=aes-sha1

The first segw was *unhappy* with this, because the CHILD_SA creation
included a LIST of proposals (of all of the possible combinations PREPENDED
by the one we specified, above). The first segw did not like the fact that
we were sending a list instead of just the combination we had agreed.

So, we changed the esp= line:

esp=aes-sha1!


This forced the local end to only propose the specified combination.

The first segw became happy.

Next, the second segw was unhappy. Eventually, they managed to tell us it
was because we were not specifying the diffie-hellman group in the CHILD_SA
creation proposal. So, we changed the esp= line again:

esp=aes-sha1-modp1024!


The second segw became happy. We could set up a tunnel and rekeying
proceeded smoothly.

Unfortunately, the first segw became unhappy again :-(

Initial tunnel setup went okay, rekeying of the IKE_SA went okay, but
rekeying of the CHILD_SA failed. Looking at the strongswan trace, it seemed
that we were proposing to use "AES_CBC_128/HMAC_SHA1_96/MODP_1024" (as
expected) and the segw was responding with a smaller proposal of
"AES_CBC_128/HMAC_SHA1_96".
The local end's strongswan code received this proposal, looked for it in the
list of configured proposals, could not find it and failed the rekey
operation.

I've tried:

esp=aes-sha1-modp1024


but this then failed because we ended up proposing a list of choices, again.
I've also tried:

esp=aes-sha1-modp1024,aes-sha1!


but this seems to confuse the SECOND segw (after successful initial tunnel
setup, the second segw goes into an infinite immediate rekeying loop). I
haven't even tried this configuration on the first segw.

The operator of the first segw does not think there is a problem with their
segw and insists that the previous version of our software (using a
different IPsec stack not strongswan) worked fine and that we should make
our latest version of our software compatible with the old version.

Looking at the old version, it made the same proposal as the new one
("AES_CBC_128/HMAC_SHA1_96/MODP_1024") and when it received the same
responding proposal ("AES_CBC_128/HMAC_SHA1_96") warned that the remote end
had not specified the diffie-hellman group BUT it would carry on anyway and
set up the new CHILD_SA.

Any ideas, anyone ?

I'm tempted to try and argue that the problem is with their segw, because it
specifies the diffie-hellman group during the initial setup of the CHILD_SA
and it is only during the rekeying of the CHILD_SA that they do not specify
the diffie-hellman group.

However, I'm sure they will:

(a) state that they are not breaking any standards by doing so
(b) it is more efficient to NOT specify a new diffie-hellman exchange during
a rekey of the CHILD_SA (or something)
(c) play the old "your new software breaks compatibility with your old
software" card

Is this a problem with strongswan ?

Or, have I configured it wrong ?

Or, will I have to give in with trying to stick to the same connection
configuration for both security-gateways ?

Or, will I have to hack the strongswan code to work around this ?

Any suggestions gratefully received !

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Getting Strongswan to NOT use port 500 ?

[Graham Hudspith]

Dear All,

We're happily using strongSwan 4.3.5+, but we've come up against a situation
where the route between us and the Security-Gateway has a firewall which is
configured to open port 4500 only and to NOT open port 500.

Is there any way to configure strongSwan to go straight to using port 4500
(or, try port 500 and then try port 4500) ?

Or is it hack-the-code time ?

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Obscure RFC compliance of strongSwan

[Graham Hudspith]

Hello All,


A customer of ours is asking for ticklist of RFCs that our product complies
with. We use strongSwan for our IPsec functionality. I've looked at the
"IPsecStandards" page on the wiki and ticked off many of the relevant wanted
RFCs.

However, they also want to know compliance with the following, unmentioned,
RFCs:

rfc2709: Security Model with Tunnel-mode IPsec for NAT
Domains

rfc3715: IPsec-Network Address Translation (NAT) Compatibility
Requirements

These look like ancient, IPsecv2/IKEv1 informational/optional texts to me.
Can we state that strongSwan complies with them ?

Or, should we assert that these are obsolete and not relevant ?

Or, that these are operational in nature and that if strongSwan is
configured correctly, the operational procedures will be complied with ?

Thanks for any pointers,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] IP fragmentation woes

[Graham Hudspith]

My apologies in advance for bringing this subject up. This seems to appear
every few months, but none of the previous threads help me, I'm afraid.

I've set up an IPsec tunnel using strongSwan 4.3.5 and linux 2.6.29.
Everything appears to start off okay (traffic flows) and then the far end
sends some traffic which results in IP fragmentation.

Wireshark shows the two IP fragments being presented to our network
interface, and the reassembled single IP packet too.

However, this reassembled IP packet is not received by the application at
our end of the tunnel.

The first fragment is 1514 bytes long (14 bytes ethernet header, 1500 bytes
IP), of which 1480 bytes constitutes the payload. The "more fragments" flag
is set and the "fragment offset" is 0.

The second fragment is 60 bytes long (14 bytes ethernet header, 40 bytes IP
and 6 bytes ethernet trailer), of which 20 bytes constitutes the payload.
The "more fragments" flag is clear and the "fragment offset" is 1480.

The reassembled IP packet is 1500 bytes long (8 bytes UDP, 1492 bytes ESP).
After decrypting (losing 51 bytes ESP overhead), the enclosed payload
consists of another IP packet of 1441 bytes length (8 bytes UDP, 1413 bytes
data). This IP packet has the "dont fragment" flag set and the "fragment
offset" is 0.

I initially thought this might be a firewall problem (i.e the ESP packet
gets through the firewall, is decrypted and then sent back through the
firewall), so I removed all firewall rules.

However, these reassembled packets still do not get through the tunnel to
our application.

Can anyone please throw some light onto an explanation ? or, even, a fix :-)

More importantly, can anyone please suggest how we can query (or debug)
linux to determine where these packets are going to ?

I would love to be able to turn on some sort of tracing that said "packet
*blah* received and dropped because of *blah* reason".

Advice on how to go about investigating this problem (never mind fixing it)
would be most appreciated.

Help !?!

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Does strongswan always delete routes ?

[Graham Hudspith]

Martin, Andreas,

We're in the process of opting out of strongSwan managing routes when
setting up and tearing down tunnels (by setting strongswan.conf's
charon.install_routes option to 'no').

However, although strongswan is no longer installing the routes, whenever
the tunnel goes down it looks like strongswan is still deleting the routes.
Is this correct ? Desired ?

If so, you may want to (ahem) amend the documentation warning developers of
this :-)

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Restricting access to list of subnets

[Graham Hudspith]

All,

Having learnt how to provide access to the local subnet when the tunnel is
up, I now want to restrict the list of subnets available through the tunnel.
In other words, I want everything to go OFF-tunnel unless it is in the
supplied list of subnets.

So, I set up a normal tunnel and provide a comma-separated list of allowed
subnets (e.g. "rightsubnet=172.20.0.0/16,1.1.0.0/16").

As hoped for, strongSwan leaves the default ip route alone so that by
default, traffic is "off-tunnel" and adds a set of ip routes that direct the
desired traffic down the tunnel.

So far, so good.

[ Strongswan is also using the list of allowed subnets to set up ip xfrm
policies. I'm not sure if I want these or understand them, but I'll leave
them be until I learn more about xfrm. ]

By accident, I found out that strongSwan is also using the list of allowed
subnets as "responder" traffic-selectors in the ISAKMP messages to set up
the tunnel.

Is this correct ? Desired ?

Why would the remote end of the tunnel be interested in how I want to direct
traffic on- or off-tunnel ? Surely routing policy is a local decision ?

Or, as usual, have I got hold of the wrong end of the stick ? Are responder
traffic-selectors meant to tell the remote end what traffic to send us down
the tunnel and I should add explicit routes (and not use "rightsubnets") to
direct which locally-generated traffic goes on- or off-traffic ?

Hope this all makes sense. I can provide examples if anyone has not got a
clue what I'm going on about.

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Access to local subnet when tunnel up

[Graham Hudspith]

Dimitrios,

That is a brilliant idea, thank you. Out-of-the-box thinking. Or is that
out-of-the-table ? :-)

Graham.

2009/11/15 Dimitrios Siganos 

> I can think of another option might might make the whole setup cleaner.
>
> Introduce another route table (e.g. 219), which has priority over the
> table 220, and has the route for the local network. To setup that you
> need to look at the "ip rule" commands.
>
> This way, no matter what charon/pluto do, the route in table 219 will
> always have precedence.
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Access to local subnet when tunnel up

[Graham Hudspith]

Andreas,

Thanks for the reply. I'm afraid I'm not an expert on xfrm policies. Could
you please give an example of the add command you had in mind?

However, as Daniel states, your diagnosis does not sound quite right to me.

Just going via the ip routing tables (and ignoring xfrm), it seems that
specific routes take precedence over default routes and strongswan uses a
separate table (220) because any default route added there takes precedence
over a default route in the default table.

However, an unintended consequence is that a default route in table 220
takes precedence over a specific route in the default table. So, as my
original posting showed, either we need to:

   - get strongswan to add an equivalent specific route to table 220 as
   already present in the default table, or
   - get strongswan to NOT use table 220 but to manage the routes in the
   default table, or
   - get strongswan to NOT manage routes at all (via the
   charon.install_routes option in strongswan.conf) and manage the routes
   ourselves, based on events from charon

Or, is there a fourth option?

Daniel,

Thanks for chipping in!

2009/11/13 Daniel Mentz

>

>
> could you please post the output of
>
> ip xfrm policy
>
>
Here you go ...

Regards,

Graham.

# *ip xfrm policy*

src 0.0.0.0/0 dst 1.1.35.49/32

dir fwd priority 2000

tmpl src segw.somewhere.com dst 192.168.50.154

proto esp reqid 1 mode tunnel

src 0.0.0.0/0 dst 1.1.35.49/32

dir in priority 2000

tmpl src segw.somewhere.com dst 192.168.50.154

proto esp reqid 1 mode tunnel

src 1.1.35.49/32 dst 0.0.0.0/0

dir out priority 1680

tmpl src 192.168.50.154 dst segw.somewhere.com

proto esp reqid 1 mode tunnel

src 0.0.0.0/0 dst 0.0.0.0/0

dir 3 priority 0

src 0.0.0.0/0 dst 0.0.0.0/0

dir 4 priority 0

src 0.0.0.0/0 dst 0.0.0.0/0

dir 3 priority 0

src 0.0.0.0/0 dst 0.0.0.0/0

dir 4 priority 0
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Access to local subnet when tunnel up

[Graham Hudspith]

Hello All,

We're grappling with an access-to-local-subnet-when-the-tunnel-is-up
problem.

After a tunnel is brought up, the routing table is thus:

*# ip route show*

192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.154
default via 192.168.50.1 dev eth0

*# ip route show table 220*

default via 192.168.50.1 dev eth0 proto static src 1.1.35.49

where 1.1.35.49 is the tunnel's inner IP address.

What we want is traffic destined for the local subnet (192.168.50.xx) goes
via eth0 from the unit's IP address (192.168.50.154)  and everything else to
go via the tunnel.

Unfortunately, that does not happen. If I ping something on the local
subnet, it gets sent via the tunnel. The default route added in table 220
seems to take precedence over the subnet route in the default table.

I've found two different ways to fix this.

(1) Add the equivalent subnet route to table 220 ...

ip route add 192.168.50.0/24 dev eth0  proto kernel  scope link  src
192.168.50.154 table 220

or

(2) (Quickly) delete the default routes from table 220 and the default table
and then add in a new default route to the default table that is equivalent
to the old one on table 220 ...

ip route del default via 192.168.50.1 dev eth0  proto static  src 1.1.35.7
table 220
ip route del default via 192.168.50.1 dev eth0
ip route add default via 192.168.50.1 dev eth0  proto static  src 1.1.35.7

and then pings to the local subnet go via the local subnet and pings down
the tunnel go via the tunnel.

This is with strongSwan 4.3.5.

Is this a bug in strongSwan ?

Or, is this the expected (desired?) behaviour ?

Or, am I misconfiguring something ?

If this is the expected behaviour, how can I make strongSwan behave the way
I want it too ? Recompile without support for table 220 ?

Any hints gratefully received !

Regards,

Graham.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Specifying ikelifetime or keylife but not both

[Graham Hudspith]

Andreas Steffen wrote:
> make sure to disable reauthentication (reauth=no) since reauthentication
> takes down the IKE_SA and all dependent CHILD_SAs and starts
> renegotiation from scratch.
>
> Unfortunately rekey=no disables both IKE_SA and CHILD_SA rekeying so
> the only workaround is to set ikelifetime and lifetime alternatively
> to a high value, e.g. 24h.
>
>   
Thanks for that, Andreas. In the end, I set the lifetime of the unwanted 
SA to:

LONG_MAX - time(0) - (24 * 60 * 60)

which should be long enough, I hope!

Another question for you (or anyone else who wants to chip in!) ...

What should happen if the IKE_SA and CHILD_SA are set to rekey at the 
same time ?

A quick test reveals that both the IKE and CHILD SAs rekey (i.e. the two 
procedures happen). But, can't it happen more efficiently (e.g. just 
rekey the IKE SA?). Or am I barking up the wrong tree ?

Regards,

Graham.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Specifying ikelifetime or keylife but not both

[Graham Hudspith]

Hi.

Is it possible to specify a value for ikelifetime (e.g. 10m) but leave 
lifetime turned off (e.g. 0) ?

And vice versa ?

During testing we want to be able to checking child-rekeying without 
worrying about ike-rekeying, and vice versa.

I realise that we could set the unwanted one to something very, very, 
large, but it would be nice to have a value which means "off altogether".

When I try to set ike-rekeying to 0 and child-rekeying to 10m, charon 
seems to interpret the 0 value a "immediate" and immediately rekeys.

Cheers,

Graham.

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Sending eth1 traffic down eth0 tunnel

[Graham Hudspith]

> I infer that the kernel does not check the routing table when it selects
> an IP address as the source address.
>
> Try something like
>
> iptables -t nat -A POSTROUTING -s 172.16.250.0/24 -d 172.17.0.0/16 -i
> eth1 -o eth0 -j SNAT --to-source 10.10.2.147
>
> If the address 10.10.2.147 is not static then you might need to come up
> with some fancy scripts that change the iptable rules everytime the
> IPsec tunnel comes up.
>
> -Daniel
>

Daniel,

Thanks a lot for taking the time to reply!

>From reading Rusty's Rough Guide to NATing, I thought there must be
something to do along these lines, but my inexperience just left me
grasping at the idea with no way to translate into practice.

Your suggestion NEARLY works, but produces:

root:/opt/strongswan/sbin# iptables -t nat -A POSTROUTING \
-s 172.16.250.0/24 -d 172.17.0.0/16 \
-i eth1 -o eth0 \
-j SNAT --to-source 10.10.2.24
iptables v1.4.1.1: Can't use -i with POSTROUTING

Try `iptables -h' or 'iptables --help' for more information.

However, trying:

root:/opt/strongswan/sbin# iptables -t nat -A POSTROUTING \
-s 172.16.250.0/24 -d 172.17.0.0/16 \
-o eth0 \
-j SNAT --to-source 10.10.2.24

works a treat! This is in addition to (AND before) the original MASQUERADE
rule:

root:/opt/strongswan/sbin# iptables -t nat -A POSTROUTING \
-s 172.16.250.0/24 \
-o eth0 \
-j MASQUERADE

Without the latter rule, traffic down the tunnel works fine but traffic
outside the tunnel does not work.

Now, everything works ! Cheers !

You're right, having to use the inner tunnel address as an arg to the
iptables command is a pain.

What I'll have to do is define a new chain, add a jump-to-new-chain
command into the POSTROUTING chain and then programmatically add and
delete rules from this new chain as the tunnel comes up and goes down.
This allows me to keep the original, static, MASQUERADE rule in place in
the POSTROUTING chain and executed after the jump-to-new-chain rule
returns.

When I get the exact syntax worked out, I'll post a follow-up for
posterity's sake ...

Thanks,

Graham.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Sending eth1 traffic down eth0 tunnel

[Graham Hudspith]

>
> the problem might be that although jupiter's satellites are NAT-ed to
jupiter's eth0 address 192.168.50.159, jupiter itself uses the virtual
IP address 10.10.2.147 within the IPsec tunnel. I know
> from personal experience that NAT-ing clients behind a gateway
> to the gateway's outer IP address will successfully route traffic
through the tunnel (at least with Linux kernels >= 2.1.16 which
> fixed a longstanding bug) but since the POSTROUTING -t nat chain is the
last hook in the path it will not heed the source routing rule defined
by table 220. Can you do without a virtual IP on jupiter?
>

Andreas,

Thanks for that swift reply.

I tried setting up the tunnel WITHOUT specifying the sourceip option
in the ipsec.conf.

The tunnel does come up, and the left side of the tunnel is assigned
jupiter's IP address.

However, if I send a ping from jupiter to one of saturn's satellites,
the pings go down the tunnel to the remote
security-gateway (saturn) and onwards to the far subnet (saturn's
satellites), BUT the reply seems to come from saturn back cleartext on the
LAN rather than through the tunnel.

The ping replies are not routed back to the originator on jupiter.

If I send a ping from one of jupiter's satellites to one of saturn's
satellites, this does now go down the tunnel. However, the results are
the same, in that the ping reply is sent cleartext from saturn on the
LAN rather than down the tunnel.

Any ideas what I can do to fix this (only allowed to alter jupiter,
sadly) ?

Regards,

Graham.




___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Sending eth1 traffic down eth0 tunnel

[Graham Hudspith]

Hi,

I have a situation which I hope someone can please help me with.

I have a machine (called jupiter) on our lan. Using it's eth0 NIC (we're
talking linux, of course), jupiter can ping and connect to other machines
on the lan. One machine it can reach (called saturn) acts as a gateway to
a further network of machines (e.g. mimas, rhea, titan, etc.). These
"satellite" machines can not be contacted directly by jupiter, they are
hiding behind saturn. To get at them, jupiter has to set up a strongSwan
tunnel.

Once the tunnel is set up, jupiter can ping and connect to all of saturn's
satellites.

So far, so good.

Now, we also have a network of machines hiding from the lan behind
jupiter. These "satellites" of jupiter (e.g. io, europa, ganymede, etc.)
are connected to jupiter's eth1 NIC. I've turned on ipv4 forwarding on
jupiter and added an iptables nat rule to jupiter to allow these
satellites access to the lan.

However, the problem is that I have not found a way to allow jupiter's
satellites access, through the tunnel, to saturn's satellites ?

Is there something obvious I have missed ?

Now for the details ...

Our default gateway is 192.168.50.1

saturn has ip address 172.16.2.2

saturn's satellites have ip addresses in the range 172.17.x.x, e.g. titan
(one of saturn's satellites) has ip address 172.17.100.151

jupiter has ip address 192.168.50.159 (acquired by dhcp from the lan for
eth0) and 172.16.250.1 (statically assigned by jupiter for eth1).

jupiter's satellites have ip addresses in the range 172.16.250.100-200
served by dnsmasq running on jupiter for eth1.

At start-up, jupiter allows access to the lan for it's satellites via:

iptables -t nat -A POSTROUTING -s 172.16.250.0/24 -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

Jupiter then sets up a strongswan (v4.3.2) tunnel using the following
ipsec.conf:

config setup
charondebug="dmn 4, mgr 4, ike 4, chd 4, job 4, cfg 4, knl 4, net 4, enc
4, lib 4"
plutostart=no

conn %default
ikelifetime=24h
keylife=8h
rekeymargin=3m
keyingtries=1
keyexchange=ikev2

conn access-saturn-satellites
left=%defaultroute
leftid=036439001...@gan.mnc390.mcc364.3gppnetwork.org
leftsendcert=never
leftsourceip=%config
right=saturn.foobar.com
right...@saturn.foobar.com
rightsubnet=172.17.0.0/16
authby=eap
forceencaps=yes
ike=aes128-sha-modp1024!
mobike=no
auto=start

With the tunnel set up, ganymede (one of jupiter's satellites) can ping
machines on the lan, but NOT ping saturn's satellites. The icmp request
packets are sent out by jupiter onto the lan (and are therefore ignored)
instead of being sent out over the tunnel to saturn.

r...@jupiter:/opt/strongswan/sbin# ip addr show
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth1:  mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 00:17:3f:9b:8c:ad brd ff:ff:ff:ff:ff:ff
inet 172.16.250.1/24 brd 172.16.250.255 scope global eth1
inet6 fe80::217:3fff:fe9b:8cad/64 scope link
   valid_lft forever preferred_lft forever
3: eth0:  mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 00:16:76:ca:bb:27 brd ff:ff:ff:ff:ff:ff
inet 192.168.50.159/24 brd 192.168.50.255 scope global eth0
inet 10.10.2.147/32 scope global eth0
inet6 fe80::216:76ff:feca:bb27/64 scope link
   valid_lft forever preferred_lft forever


r...@jupiter:/opt/strongswan/sbin# ip route show
192.168.50.0/24 dev eth0  proto kernel  scope link  src 192.168.50.159
172.16.250.0/24 dev eth1  proto kernel  scope link  src 172.16.250.1
169.254.0.0/16 dev eth1  scope link  metric 1000
default via 192.168.50.1 dev eth0  metric 100


r...@jupiter:/opt/strongswan/sbin# ip route show table 220
172.17.0.0/16 via 192.168.50.1 dev eth0  proto static  src 10.10.2.147


r...@jupiter:/opt/strongswan/sbin# iptables -L -t filter -n
Chain INPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  172.17.0.0/1610.10.2.147 policy match
dir in pol ipsec reqid 1 proto 50

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  172.17.0.0/1610.10.2.147 policy match
dir in pol ipsec reqid 1 proto 50
ACCEPT all  --  10.10.2.147  172.17.0.0/16   policy match
dir out pol ipsec reqid 1 proto 50

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  10.10.2.147  172.17.0.0/16   policy match
dir out pol ipsec reqid 1 proto 50


r...@jupiter:/opt/strongswan/sbin# iptables -L -t nat -n
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt 

Re: [strongSwan] Support for AKA-Identity and AKA-Reauthentication in the EAP-AKA plugin

[Graham Hudspith]

Martin,

Thanks for your swift reply. I've gone away and read the RFC on
EAP-AKA and had a think about what you said.

The problem with not supporting AKA-Identity is that it stops
everything else (in an EAP-AKA environment) from working. Get
AKA-Identity implemented and you do not need to do anything else.

Trying to decipher the RFC, it seems that people might implement
"Fast Reauthentication" not because it lightens the load on the
client (as you state, it probably wont), nor because it lightens the
network traffic (it uses the same number of messages) but to lighten
the load on the AAA infrastructure behind the Security Gateway. I'm
thinking of many clients requiring EAP-AKA authentication and the
load they will place on the AAA provider. Fast Reauthentication (I
guess) will restrict the heavy load to just the Security Gateway.

Anyway, that apart, whereas responding to an AKA-Identity request is
mandatory (when the EAP server sends it), taking any notice of the
"Next Reauth ID" offered as part of the following AKA-Challenge
request is entirely optional.

So, the path we have chosen to follow is to implement support for
AKA-Identity now, but to always get it to return the full, local,
identity (e.g. the peer identity in EAP-speak), which is always
0+i...@realm in this case.

Then to ignore the offered Next-Reauth-ID in the following
AKA-Challenge - the existing code already does this, thank goodness.

This means that the NEXT time we try to bring up the tunnel, the
identity sent in the AKA-Identity response is STILL the full, local,
identity, which forces the EAP server to go for another full
AKA-Challenge. Not what the EAP server intended, I'm sure, but it
gets us a tunnel until we can find the time and inclination to
implement Fast Reauthentication.

I can let you have the AKA-Identity support as a patch if you want.
However, it looks a lot (*cough*) like the code you have already
implemented to support SIM-Identity in the EAP-SIM module :-)

Regards,

Graham.



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Support for AKA-Identity and AKA-Reauthentication in the EAP-AKA plugin

[Graham Hudspith]

Hello All,

Having been connecting quite successfully to one brand of Security Gateway
and using EAP-AKA authentication throughout, our system (using strongSwan
4.3.2) has come off the rails when we attempted to connect to another
brand of Security Gateway.

This is because the new SeGW, whilst using EAP-AKA authentication,
enforces use of the AKA-Identity and AKA-Authentication messages.

To my surprise, a quick examination of the code shows that, yes, these two
messages are NOT supported by strongSwan and provoke an
AT_CLIENT_ERROR_CODE response.

Not surprisingly, the new SeGW is less than happy about this and sends us
a (rude, IMHO) Notification(AUTH_FAILED) message.

Are there plans to implement support for this anytime soon ?

Or is it time to print out RFC-4187 and start coding :-(

Regards,

Graham.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Understanding IPsec through a firewall

[Graham Hudspith]

>
> Or a module we may have built for the kernel but not actually installed ?
>

Sigh! Time to answer my own question (I hope).

Looking at our kernel config, I see that is selected.

Looking in kernelbuild/net/netfilter I can see an xt_policy.ko module.

However, this module is not installed on the embedded system. Ho hum.

I hope this will be a quick fix ...

Cheers,

Graham.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Understanding IPsec through a firewall

[Graham Hudspith]

Gerd,

Thanks very much for the confirmation and pointer on how to do things
properly.

>> I'm not too keen on opening the firewall to all UDP packets using that
>> UDP
>> port number. Is there a more elegant method ?
>
> Yes, you could use the policy match of iptables. E.g. "-m policy --pol
> ipsec"
> matches only pakets coming in decrypted or going out encrypted.
>

Unfortunately, I can't get "-m policy --pol ipsec" to work :-(

Here is the current firewall on my embedded system (i.e. no rules added):

# iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

I changed the ipsec.conf on my x86 ubuntu laptop to say "leftfirewall=yes"
and captured the commands executed by /libexec/ipsec/_updown to add a
firewall rule for all traffic coming in via the tunnel:

iptables -I INPUT 1 -i eth0 -p 0 -s 172.17.0.0/16 -d 10.10.2.78/32 -m
policy --pol ipsec --proto esp --reqid 1 --dir in -j ACCEPT

When I execute a similar command on my embedded system, I get:

# iptables -I INPUT 1 -i eth0 -p 0 -s 172.17.0.0/16 -d 10.10.0.51/32 -m
policy --pol ipsec --proto esp --reqid 1 --dir in -j ACCEPT

iptables: No chain/target/match by that name

Even trying to cut down the command to the bare minimum has no success:

# iptables -A INPUT -p 0 -m policy --pol ipsec --proto esp --dir in -j ACCEPT

iptables: No chain/target/match by that name

Any clues what can be causing this ?

The iptables version on the embedded system is 1.4.2 (vs. 1.4.1.1 on the
x86 ubuntu laptop). Looking at the way we configure and build iptables, it
looks like a vanilla configure with nothing excluded or added.

Is there some kernel build config option we are missing ?

Or a module we may have built for the kernel but not actually installed ?

Any hints gratefully accepted !

Regards,

Graham.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Understanding IPsec through a firewall

[Graham Hudspith]

We've come across a problem sending UDP packets through a tunnel when the
tunnel goes through a firewall and I was hoping someone can
explain/confirm what is going on (please).

Our machine sets up a tunnel to a secure gateway and then opens a UDP
socket through that tunnel to a machine on the far side of the secure
gateway.

We have found that although we can send UDP packets to the far machine,
the return UDP packets were not reaching the local application UNTIL we
opened up the left UDP port in the firewall (all UDP ports are blocked by
default).

So, it appears that the UDP packets come through the tunnel, are decrypted
and then looped-back through the firewall ?

I'm not too keen on opening the firewall to all UDP packets using that UDP
port number. Is there a more elegant method ?

I've a sneaking suspicion someone is going to suggest setting
left=firewall in ipsec.conf and letting charon call _updown to adjust the
iptables ?

I can imagine that charon knows how to invoke the __updown script with the
correct left and right IP addresses, but how does it know which UDP ports
we will be using through the tunnel ?

Regards,

Graham.

P. S. As ever, if there is a webpage that explains this all, I would be
glad of any pointers!


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Problem setting UDP encapsulation option in charon ?

[Graham Hudspith]

We've recently transitioned from strongSwan 4.2.16 to 4.3.2 and found that
our charon plugin (replacing stroke with our own initialisation scheme)
stopped working w.r.t forcing UDP encapsulation.

We've fixed the problem in our plugin, but I thought I'd better share my
concerns with the community ...

Investigation shows that the stroke message to add a connection declares
force_encap as an int and ike_cfg_create() (called by the charon stroke
plugin) takes a force_encap argument which is a bool.

At least on our embbeded platform, the bool type is typedef'ed as a signed
char with true being 1 and false being 0.

The force_encap int in the stroke add message is assigned, after some cpp
processing, the value (1 << 24, aka 16777216) after reading the config
file and sent to the charon daemon. The charon stroke plugin receives this
message and passes the force_encap int as an argument to ike_cfg_create().
The compiler coerces the int to a signed char and seems to lose the top 24
bits, meaning that ike_cfg_create() receives the bool force_encap as false
instead of true.

The following program:

 snip snip 
#include 

#define bool signed char
#define true 1
#define false 0

void ike_cfg_create(bool force_encap)
{
printf("ike_cfg_create: force_encap = %d\n", force_encap);
}

int main()
{
int force_encap = 1 << 24;

printf("main: force_encap = %d\n", force_encap);

ike_cfg_create(force_encap);

return 0;
}
 snip snip 

outputs the following on our system:

main: force_encap = 16777216
ike_cfg_create: force_encap = 0

Is this a problem that needs fixing in the main code too ?

Regards,

Graham.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Which plugins do what and which can I leave out?

[Graham Hudspith]

>>
>> Which plugins can I get rid of when openssl is being used ?
>>
> if you enable openssl then you can get rid of the following plugins:
>
>   aes des sha1 sha2 md5 gmp
>
> you still need hmac (always), pubkey and x509 (with rsa signatures)
> and xcbc (with aes-xcbc authentication).
>

Thanks for that, Andreas. By adding the following configure flags

 --disable-des \
 --disable-md5 \
 --disable-sha2 \
 --disable-gmp \
 --disable-xcbc \
 --disable-pluto \
 --disable-tools \
 --enable-openssl \
 --disable-static \

I've managed to shrink the installed strongSwan footprint by 50%.

Even though I'm no longer building the gmp plugin, I notice that the
eap-aka plugin still requires the gmp library ...

>> I tried adding openssl to the list of plugins in strongswan.conf and
>> removing the following:
>>
>> aes des sha1 sha2 md5 gmp xcbc fips-prf
>>
>> However, with these removed, the tunnel does not come up. A little
>> experimentation shows that I have to add fips-prf (okay, I can
>> understand this one) and sha1 back in.
>>
>> Why do I need to add sha1 back in ?
>>
> shouldn't be required, see the following openssl scenario:
>
> http://www.strongswan.org/uml/testresults43/openssl/rw-cert/moon.strongswan.conf
>

Sadly, if I remove the sha1 plugin from strongswan.conf, the tunnel
refuses to come up. I'll leave this for now and investigate later ...

Thanks for the help,

Graham.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Which plugins do what and which can I leave out?

[Graham Hudspith]

Dear All,

I've tried finding information on the plugins used by strongSwan and
have failed miserably. I'm hoping someone here can please throw some
light on the matter.

We're using eap-sim and eap-aka mechanisms to set up the tunnel. So
I have configured and built strongSwan with --disable-pluto to save
space in the installation.

We've also got openssl already installed, so I've also built with
--enable-openssl.

Now I'm looking to trim back the strongSwan plugins we don't need to
build and install.

Part 1
==

Which plugins can I get rid of when openssl is being used ?

I tried adding openssl to the list of plugins in strongswan.conf and
removing the following:

aes des sha1 sha2 md5 gmp xcbc fips-prf

However, with these removed, the tunnel does not come up. A little
experimentation shows that I have to add fips-prf (okay, I can
understand this one) and sha1 back in.

Why do I need to add sha1 back in ?

Doesn't the openssl plugin provide the same sha1 capability (via
openssl) ?

Part 2
==

Is there a description anywhere of what the various plugins do ?

Which plugins require other plugins ?

Which can be removed when using openssl ?

If I use "fips-prf", can I remove "random" ? Or are they not
alternatives ?

It would also be useful if the UML tests included strongswan.conf
files that indicated the minimum/specific list of plugins required
per test rather than seeming to include the "standard set" plus any
specialist ones required.

There is a page in the strongSwan wiki here
 which
lists the cipher suites supported for IKEv2. Does this show that
/only/ the algorithms marked with an "o" will be picked up from
openssl when the openssl plugin is used ? And that no other
algorithms which are *not* marked with an "o" will be picked up from
openssl (e.g. sha1 will not come from openssl) ?

Hope these questions aren't too noob for everyone!

Graham.

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Strongswan 4.2.14 broken on ARM ?

[Graham Hudspith]

> I've removed any reads to unaligned integers in the parser code [1],
generator looks OK so far. I don't have an ARM box, so any feedback is
very welcome.
>
> Thanks
> Martin
>
> [1]http://wiki.strongswan.org/repositories/diff/strongswan?rev=42748858
>
>

Martin,

Thanks for that patch.

With a small bit of adjustment, I managed to apply the patch to my
copy of the 4.2.14 code, :-), and rebuild.

It seems to work fine, so far.

I did have a small problem the first time I brought the ARM up, in
that the initial SA came up fine but then something started creating LOTS
of child SAs. I pulled the plug on the ARM box after we got to 100 child
SAs. Unfortunately, I did not have any charon logging turned on, so had no
logs to comb through.

Since then, restarting the ARM box and bringing up the connection has
exhibited no problems (and no unwanted child SAs).

So, looking good (but feeling slightly nervous about it needing wider
testing).

Regards,

Graham.







___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Strongswan 4.2.14 broken on ARM ?

[Graham Hudspith]

> Hi,
>
> I wonder if anyone can please help me with a problem I'm having getting
> strongSwan (4.2.14) running on the ARM ?
>
> I've played about getting strongSwan working on x86 setting up a tunnel to
> a server. I then compiled strongSwan for ARM and copied across the config
> files I used on x86.
>
> The ARM version fails to set up the tunnel.
>

I hate replying to my own email, but I've been playing around with the ARM
compiler.

>
> Can anyone explain this and how to fix it easily ?
>

It seems that there is a word (or, half-word) alignment thing going on here.

I've written another test program which iterates through the array of 6
bytes, converting each one to a uint16.

The array is:

   0x27, 0xff, 0x03, 0xFA, 0x04, 0x30

On the x86, the output is:

   => 0x27ff
bytes = 0xbfc8bffe, byte_pos = 0xbfc8bffe, &bytes[0] = 0xbfc8bffe
*byte_pos = 0x27
*((u_int16_t*) byte_pos) = 65319 = 0xff27
ntohs(*((u_int16_t*) byte_pos)) = 10239 = 0x27ff


   => 0xff03
bytes = 0xbfc8bffe, byte_pos = 0xbfc8bfff, &bytes[1] = 0xbfc8bfff
*byte_pos = 0xff
*((u_int16_t*) byte_pos) = 1023 = 0x03ff
ntohs(*((u_int16_t*) byte_pos)) = 65283 = 0xff03


   => 0x03fa
bytes = 0xbfc8bffe, byte_pos = 0xbfc8c000, &bytes[2] = 0xbfc8c000
*byte_pos = 0x03
*((u_int16_t*) byte_pos) = 64003 = 0xfa03
ntohs(*((u_int16_t*) byte_pos)) = 1018 = 0x03fa


   => 0xfa04
bytes = 0xbfc8bffe, byte_pos = 0xbfc8c001, &bytes[3] = 0xbfc8c001
*byte_pos = 0xfa
*((u_int16_t*) byte_pos) = 1274 = 0x04fa
ntohs(*((u_int16_t*) byte_pos)) = 64004 = 0xfa04


   => 0x0430
bytes = 0xbfc8bffe, byte_pos = 0xbfc8c002, &bytes[4] = 0xbfc8c002
*byte_pos = 0x04
*((u_int16_t*) byte_pos) = 12292 = 0x3004
ntohs(*((u_int16_t*) byte_pos)) = 1072 = 0x0430

You can see that the bytes are bring read correctly (e.g. 0x27ff, 0xff03,
0x03fa, etc.).

On the ARM, the output is:

   => 0xe427
bytes = 0xbedcebfd, byte_pos = 0xbedcebfd, &bytes[0] = 0xbedcebfd
*byte_pos = 0x27
*((u_int16_t*) byte_pos) = 10212 = 0x27e4
ntohs(*((u_int16_t*) byte_pos)) = 58407 = 0xe427


   => 0xff03
bytes = 0xbedcebfd, byte_pos = 0xbedcebfe, &bytes[1] = 0xbedcebfe
*byte_pos = 0xff
*((u_int16_t*) byte_pos) = 1023 = 0x03ff
ntohs(*((u_int16_t*) byte_pos)) = 65283 = 0xff03


   => 0xff03
bytes = 0xbedcebfd, byte_pos = 0xbedcebff, &bytes[2] = 0xbedcebff
*byte_pos = 0x03
*((u_int16_t*) byte_pos) = 1023 = 0x03ff
ntohs(*((u_int16_t*) byte_pos)) = 65283 = 0xff03


   => 0xfa04
bytes = 0xbedcebfd, byte_pos = 0xbedcec00, &bytes[3] = 0xbedcec00
*byte_pos = 0xfa
*((u_int16_t*) byte_pos) = 1274 = 0x04fa
ntohs(*((u_int16_t*) byte_pos)) = 64004 = 0xfa04


   => 0xfa04
bytes = 0xbedcebfd, byte_pos = 0xbedcec01, &bytes[4] = 0xbedcec01
*byte_pos = 0x04
*((u_int16_t*) byte_pos) = 1274 = 0x04fa
ntohs(*((u_int16_t*) byte_pos)) = 64004 = 0xfa04

Which is plain wrong.

Whenever the byte in memory is half-word-aligned, reading it as a uint16
works as expected. The other half of the time, the compiler is adjusting
the pointer (back one) to make it half-word-aligned before reading the two
bytes as a uint16.

I can find at least 26 occasions in the strongSwan code where this
reading-a-byte-pointer-as-a-uint16-pointer idiom occurs.

I have not searched for the byte-pointer->uint32-pointer case yet :-(

Graham.
#include 
#include 

#define MORE_TRACING

int main()
{
u_int8_t bytes[] =
{
0x27, 0xff, 0x03, 0xFA, 0x04, 0x30
};

u_int8_t bit_pos;

u_int8_t* byte_pos;

byte_pos = bytes;

int i;

for(i = 0; i < 5; ++i)
{
u_int16_t output_pos;

// u_int16_t intermediate = *(byte_pos + 1) << 8 | *(byte_pos + 0);

// output_pos = ntohs(intermediate);

output_pos = ntohs(*((u_int16_t*) byte_pos));

printf("   => 0x%04x\n", output_pos);

#ifdef MORE_TRACING
printf("\tbytes = 0x%x, byte_pos = 0x%x, &bytes[%d] = 0x%x\n",
(unsigned int) bytes,
(unsigned int) byte_pos,
i,
(unsigned int) &bytes[i]);

printf("\t*byte_pos = 0x%02x\n", *byte_pos);
printf("\t*((u_int16_t*) byte_pos) = %d = 0x%04x\n",
*((u_int16_t*) byte_pos), *((u_int16_t*) byte_pos));
printf("\tntohs(*((u_int16_t*) byte_pos)) = %d = 0x%04x\n",
ntohs(*((u_int16_t*) byte_pos)), ntohs(*((u_int16_t*) byte_pos)));

printf("\n\n");
#endif /* MORE_TRACING */

byte_pos++;
}

return 0;
}___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Strongswan 4.2.14 broken on ARM ?

[Graham Hudspith]

Hi,

I wonder if anyone can please help me with a problem I'm having getting
strongSwan (4.2.14) running on the ARM ?

I've played about getting strongSwan working on x86 setting up a tunnel to
a server. I then compiled strongSwan for ARM and copied across the config
files I used on x86.

The ARM version fails to set up the tunnel.

Turning on tracing to level 3 everywhere gets me the following line in the
client (left?) /var/log/messages:

charon: 08[MGR] checkout IKE_SA
charon: 13[ENC]   parsing rule 0 U_INT_8
charon: 13[ENC]=> 39
charon: 13[ENC]   parsing rule 1 FLAG
charon: 13[ENC]=> 0
charon: 13[ENC]   parsing rule 2 RESERVED_BIT
charon: 13[ENC]   parsing rule 3 RESERVED_BIT
charon: 13[ENC]   parsing rule 4 RESERVED_BIT
charon: 13[ENC]   parsing rule 5 RESERVED_BIT
charon: 13[ENC]   parsing rule 6 RESERVED_BIT
charon: 13[ENC]   parsing rule 7 RESERVED_BIT
charon: 13[ENC]   parsing rule 8 RESERVED_BIT
charon: 13[ENC]   parsing rule 9 PAYLOAD_LENGTH
charon: 13[ENC]=> 3
charon: 13[ENC] encrypted payload could not be decrypted and parsed
charon: 13[ENC] could not decrypt payloads
charon: 13[IKE] IKE_AUTH response with message ID 1 processing failed

The client is trying to use ike=aes128-sha-modp1024!, esp=aes128-sha1,
3des-md5 and EAP-SIM.

The client has sent out the initial IKE_SA_INIT request and been happy
with the IKE_SA_INIT response. The client has then sent out the first
IKE_AUTH request and has then had trouble processing the first IKE_AUTH
response.

Working back from the "encrypted payload could not be decrypted and
parsed" error in the code, I can see that message.c:decrypt_payloads() has
managed to decrypt and parse one payload (the ID_RESPONDER one) and has
started on the CERTIFICATE payload.

The code manages to decrypt this payload okay and starts to parse it (see
parser.c:parse_payload()).

The payload starts with the following bytes:

0x27, 0x00, 0x03, 0xFA, 0x04, 0x30

On the x86, the code parses the first byte as one uint_8 = 39 decimal (27
hex), 8 1-bit fields and a uint_16 payload-length = 1018 decimal (03FA
hex).

On the ARM, the code parses the first byte as one uint_8 = 39 (decimal), 8
1-bit fields and a uint_16 payload-length = 3 decimal (0003 hex) !!

The code, rightly, thinks this is rubbish and fails the rest of the parse.

I've worked my way through the code in parser.c (e.g. parse_payload(),
parse_uint8(), parse_bit() and parse_uint16()) and managed to reduce them
to a small test program (hopefully attached).

If I compile and run this on the x86, I get:

  parsing rule 0 U_INT_8
   => 39
  skipping rules 1 FLAG ... 8 RESERVED_BIT
  parsing rule 9 PAYLOAD_LENGTH
   => 1018

output. On the ARM, I get:

  parsing rule 0 U_INT_8
   => 39
  skipping rules 1 FLAG ... 8 RESERVED_BIT
  parsing rule 9 PAYLOAD_LENGTH
   => 65283

To make things more clear what it going on, I have changed the second byte
of the message from 0x00 to 0xff in my test program.

If I replace the line:

output_pos = ntohs(*((u_int16_t*) byte_pos));

by:

u_int16_t intermediate = *(byte_pos + 1) << 8 | *(byte_pos + 0);
output_pos = ntohs(intermediate);

everything works as expected on both x86 and ARM.

Also found that something like the following works on both x86 and ARM:

u_int16_t intermediate;

u_int8_t* intermediate_bytes = (u_int8_t*) &intermediate;

intermediate_bytes[0] = byte_pos[0];

intermediate_bytes[1] = byte_pos[1];

output_pos = ntohs(intermediate);

Can anyone explain this and how to fix it easily ?

I'm hoping that someone will say that this is fixed by a command-line flag
on the ARM version of gcc ;-}

Version of ARM gcc in use is 4.1.1.

If this does mean a strongSwan code fix, will it just be to parse_uint16() ?

Or parse_uint32() too ?

Or is this idiom endemic throughout the strongSwan code ?

Thanks for any help,

Graham.

#include 
#include 

int main()
{
u_int8_t bytes[] =
{
0x27, 0xff, 0x03, 0xFA, 0x04, 0x30
};

u_int8_t bit_pos;

u_int8_t* byte_pos;

byte_pos = bytes;

printf("  parsing rule 0 U_INT_8\n");

{
u_int8_t output_pos;

output_pos = *(byte_pos);

printf("   => %d\n", output_pos);
}

byte_pos++;

printf("  skipping rules 1 FLAG ... 8 RESERVED_BIT\n");

byte_pos++;

printf("  parsing rule 9 PAYLOAD_LENGTH\n");

{
u_int16_t output_pos;

// u_int16_t intermediate = *(byte_pos + 1) << 8 | *(byte_pos + 0);

// output_pos = ntohs(intermediate);

output_pos = ntohs(*((u_int16_t*) byte_pos));

printf("   => %d\n", output_pos);

#ifdef MORE_TRACING
printf("bytes = 0x%x, byte_pos = 0x%x, bytes + 2 = 0x%x\n",
(unsigned int) bytes,
(unsigned int) byte_pos,
(unsigned int) (bytes + 2));

printf("*byte_pos = %d\n", *byte_pos);
printf("*((u_int16_t*) byte_pos) = %d = 0x%x\n",
*((u_int16_t*) byte_pos), *((u_int16_t*) byte_pos));
printf

Re: [strongSwan] Turn off peer certificate verification

[Graham Hudspith]

Martin,

Thanks very much for that swift reply.

You're right, mutual authentication using EAP and without first
using public-key authentication is exactly what we want to do.

Adding support for this draft RFC into the server-side (as well as
the client-side) of Strongswan sounds like a lot of work for what is
still an unapproved RFC proposal (with only five months until
expiry, too).

However, the authors have given some very handy
(standards-compliant) alternatives that are worth considering
instead (e.g. adding a left-hand-side ipsec.conf option that tells
the client to ignore the AUTH payload in message #4).

Thanks for the pointer, I'll get my thinking cap on.

Best regards,

Graham.

P. S. I suppose I should get around to reading the rest of the IPsec
RFCs at some point ;-)

Martin Willi wrote:
> Hi Graham,
>
>   
>> Is there any way to configure the client so that it will either not bother
>> verifying the server, or if it does try to verify and fails, will not care
>> ?
>> 
>
> No, there is currently no such option. 
>
>   
>> For our application, the server MUST be able to verify the identity of the
>> clients, but the verification of the server by the clients is not so
>> important.
>> 
>
> Not verifying the server credentials at all is not an option, as it
> allows an active attacker to act as your gateway, play the
> Man-In-The-Middle game.
>
>   
>> The server will verify the identity of the clients using EAP-SIM or
>> EAP-AKA.
>> 
>
> If you are running a mutual EAP method (SIM and AKA actually are), the
> client authenticates the server within EAP. There is a resurrected
> internet draft [1] which omits public key authentication in such cases.
> However, we currently do not implement this extension.
>
> Regards
> Martin
>
> [1]http://tools.ietf.org/html/draft-eronen-ipsec-ikev2-eap-auth-06
>
>
>
>   

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Turn off peer certificate verification

[Graham Hudspith]

We have a group of clients that each want to set up an IPsec tunnel with a
single server.

The server will verify the identity of the clients using EAP-SIM or EAP-AKA.

At the moment, the clients verify the identity of the server using a
locally-held cacert.der file.

This all works fine as is.

However, in one particular configuration, the server will not have any
certificate to send to the clients. In another configuration, the
cacert.der file will be wrong.

So, the client can not verify the identity of the server.

If the locally-held cacert.der (on the client) is wrong (out of date,
wrong ca), it is held in readonly memory and can't be changed or removed.
However, we CAN change configuration values in another area.

Is there any way to configure the client so that it will either not bother
verifying the server, or if it does try to verify and fails, will not care
?

For our application, the server MUST be able to verify the identity of the
clients, but the verification of the server by the clients is not so
important.

Sorry if this is a noob question. If anyone has the patience to point me
to the answer in a FAQ, I would be much obliged!

Thanks for any help,

Graham.

P. S. This will be with StrongSwan 4.2 using IKEv2 only.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Hacking strongswan into an embedded environment

[graham . hudspith]

> Hi,
>
>> One problem is that Strongswan is config-file driven whereas we are db
>> driven.
>
> The IKEv1 daemon pluto is limited to a file based configuration.
> However, the newer IKEv2 daemon charon is highly modular and allows you
> to attach any configuration backend. We currently have several
> configuration backends, including a proof-of-concept SQL database plugin
> [1].
>

Thanks for the swift reply, Martin. I shall go away and consult the handy
pointers you have provided.

We're only interested in IKEv2, so pluto will not even be installed, never
mind started.

I saw the SQL database plugin, but this still implies a vaguely static
sort of configuration. Our system starts up, receives it's configuration
over the wire and then wants to setup an IPsec tunnel based on the
received configuration. This received config could be dropped into an SQL
db, I suppose, but this seems redundant. Also, I would need to investigate
how config changes later communicated to our system would then be picked
up by charon from the newly-updated SQL db.

I suppose doing the same as an "ipsec restart" would be needed.

I'd originally thought about making our existing ipsec module communicate
config changes to charon via the stroke protocol, but I'll certainly take
a look at implementing our own config backend too.

>> Another problem is that Strongswan's EAP/SIM and EAP/AKA support relies
>> on linking in a library with direct access to the simcard hardware (or,
>> device-driver),
>
> The EAP-SIM plugin already has an abstraction layer for different SIM
> card implementations. The AKA plugin backend is currently hardcoded, but
> it should be possible to split up it similar to the SIM plugin.
>

Thanks, I'll look into that.

>> we use message-queue-based access to a "sim
>> query server" that has sole-access to the simcard hardware.
>
> If your message-queue-based system passes triplets, you could implement
> the sim_card_t interface [2] on top of it and register it at the SIM
> manager. It was designed exactly for that reason.
>

That sounds very encouraging. I'll let you know how I get on with this
approach.

>> (1) Reverse-engineer the protocol used in the socket between the
>> Strongsawn ipsec driver executable and the charon daemon.
>
> It is not clear to me what you mean by "ipsec driver executable". Charon
> communicates with the kernel directly to install IPsec SAs (either
> through PF_KEY or the Linux specific XFRM interface).
>

I meant your "ipsec" wrapper/command-line tool in combination with your
"starter" sending "stoke" commands down the socket to the charon daemon. I
won't be going anywhere near the charon <-> kernel interface, I'll leave
that to the experts !

>> (2) ... Rip out that socket-servicing thread and
>> make the rest of the charon code into a multi-threaded library which can
>> be linked into our existing ipsec module.
>
> charon was never designed to be used as a library. Instead, charon is
> expendable by plugins. But it expects to have it's own process.
>

Pity. In my fantasyland, I was hoping charon was a simple main() which
configured a multi-threaded library (e.g. libstrongswan) before starting a
set of IPsec threads. I can see that libstrongswan is a lot less ambitious
than that and that charon does a lot more work on top of it.

>> Am I along the right lines with these two possibilities ?
>> Which one sounds implementable ?
>> Have a missed a more obvious third way ?
>
> I would keep charon in its own process, but write plugins for your
> needs. Such a plugin could look up configurations in your database,
> query triplets from your SIM server or receive control commands from
> and return status information to your existing infrastructure.
>
> Our modular plugin architecture is very flexible and allows you to
> adopt the daemon to your needs. Our crypto and utility library
> libstrongswan can be extended by crypto- and other utility plugins [3],
> charon offers several higher level authentication, configuration, and
> control plugins [4].
>

I agree. It completely blows up our current architecture (sigh), but I too
would wish to keep the core of Strongswan untouched (thus allowing new
releases of Strongswan to be dropped on top of the existing source code)
and insert new plugins left, right and centre.

> Best regards
> Martin
>
> [1]http://trac.strongswan.org/browser/trunk/src/charon/plugins/sql
> [2]http://trac.strongswan.org/browser/trunk/src/charon/sa/authenticators/eap/sim_manager.h#L34
> [3]http://trac.strongswan.org/browser/trunk/src/libstrongswan/plugins
> [4]http://trac.strongswan.org/browser/trunk/src/charon/plugins
>
>
>

Cheers,

Graham.

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Hacking strongswan into an embedded environment

[Graham Hudspith]

I've been given the task of hacking support for Strongswan into our 
embedded product.

One problem is that Strongswan is config-file driven whereas we are db 
driven.

Another problem is that Strongswan's EAP/SIM and EAP/AKA support relies 
on linking in a library with direct access to the simcard hardware (or, 
device-driver), whereas we use message-queue-based access to a "sim 
query server" that has sole-access to the simcard hardware.

I can think of two possible ways forward and would be grateful for any 
views either way (or, a third way) from list members more knowledgeable 
than I (i.e everyone).

(1) Reverse-engineer the protocol used in the socket between the 
Strongsawn ipsec driver executable and the charon daemon. Do NOT have 
any config files, do not install the ipsec driver executable, only the 
charon daemon. Continue to have our own ipsec module read it's db and 
then open a socket to charon and send the dynamic config info extracted 
from the db down the socket to charon. Write a new charon plugin (or 
modify the existing ones) so that EAP/SIM and EAP/AKA challenges sent 
from the remote peer are routed back up the socket to our ipsec module 
and forward these to the sim query server. Route any replies from the 
sim query server back down the socket to the charon thread (presumably) 
pending on a mutex for the reply.

(2) Lop the top off the charon daemon. I'm hoping that charon is 
structured as a group of threads, one of which reads and writes to the 
socket attached to the ipsec driver executable and sends the commands 
read from the socket to one of the other threads and sends response from 
the threads back up the socket. Rip out that socket-servicing thread and 
make the rest of the charon code into a multi-threaded library which can 
be linked into our existing ipsec module. EAP/SIM and EAP/AKA challenges 
sent from the remote peer are channeled via callbacks into the existing 
ipsec module and forward these to the sim query server. Route any 
replies back to the requesting thread (presumably) pending on a mutex 
for the reply.

Am I along the right lines with these two possibilities ?

Which one sounds implementable ?

Have a missed a more obvious third way ?

Thanks for any advice offered!

Graham.

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users