Re: [strongSwan] best way to generate self-signed certs for strongswan-4, 5, x

[Daniel Mentz]

On 08/09/2011 11:38 AM, luxInteg wrote:
> I am atttempting to use strongswan-4.5.2 after  last playing with
> strongswan-2.x. some years ago.  I have this questions.
>
> Which is the best way to generate certificates for strongswan?

Since you already played around with strongSwan, I assume that you have 
a basic understanding of certificates and PKIs.
Take a look at the following wiki page:
http://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA
It might have the information you're looking for.
-Daniel


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

Re: [strongSwan] [strongSwan-dev] PASS and DROP shunt policies (was: ANNOUNCE: strongswan-4.5.3rc1 released)

[Daniel Mentz]

Dear strongSwan team,

thanks for the great work. I have some comments regarding the following 
change:

On 07/19/2011 01:00 AM, Andreas Steffen wrote:
> PASS and DROP shunt policies configurable by charon
> ---
>
>The IKEv2 charon daemon supports type=pass and type=drop shunt
>policies preventing specific traffic to go through IPsec connections.
>Installation of the shunt policies are possible either via the XFRM
>netfilter or PFKEYv2 IPsec kernel interfaces as the following two
>scenarios show:
>
>http://www.strongswan.org/uml/testresults45rc/ikev2/shunt-policies/
>
>http://www.strongswan.org/uml/testresults45rc/pfkey/shunt-policies/

I'm looking at the IKEv2 example. It talks about a host called venus, 
but I can't find it in the picture. I believe that adding it to the 
picture would help avoid confusion.

You say that "install_routes=no" has to be added to strongswan.conf. 
This raises some concerns. Doesn't this break other connections that 
depend on install_routes being set to "yes"? Why not change strongSwan 
in a way such that "install_routes=no" is applied to "type=pass" 
connections automatically? I believe that this would be an improvement 
in terms of user friendliness.

I'm curious what would happen if you do not set install_routes to no. 
What do the routes look like and why are they causing failure.

Again, from a user perspective, I see "authby=never" as part of the 
"local-net" connection which is of "type=pass". On the same note, "conn 
venus-icmp" has the parameters "leftauth=any" and "rightauth=any". 
Wouldn't it be nice to get rid of these parameters in this scenario? I'm 
thinking that authby, leftauth and rightauth are not applicable if the 
connection is of "type=drop" or "type=pass". If it's an internal thing, 
maybe starter or charon can add this automatically.

Thanks
-Daniel

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

Re: [strongSwan] cannot respond to IPsec SA request because no connection is known

[Daniel Mentz]

First of all, I had a look at the config you sent with your first 
e-mail: You can't have a "left=198.252.153.38" under the "config setup" 
section. You probably want to put that under "conn %default".

>>> For some reason that i do not understand, I'm getting:
>>>
>>> Jul  9 22:37:41 kestrel pluto[3901]: "l2tp-psk"[2] 208.54.45.249:58920 #1: 
>>> cannot respond to IPsec SA request because no connection is known for 
>>> 198.252.153.38:4500[198.252.153.38]:17/1701...208.54.45.249:58920[26.164.21.104]:17/%any==={26.164.21.104/32}

Ok. So that's the error message you're getting. Compare this connection 
description with the output of "ipsec statusall" you sent with your 
first e-mail:

000 "l2tp-psk": 
{0.0.0.0/0}===198.252.153.38[198.252.153.38]:17/1701...%any[%any]:17/%any==={0.0.0.0/0};
 
unrouted; eroute owner: #0

For some reason I don't really understand, pluto says that you 
configured a local and remote subnet of 0.0.0.0/0.

Second, your peer is sending the IP address 26.164.21.104 as its ID. 
However, strongSwan expects the ID to be the same as the IP address from 
which it receives the IKE packets. You could fix that with

rightid=26.164.21.104

or you could change the peer's config in such a way that it sends an ID 
that matches its IP address.

When I add your connection description to /etc/ipsec.conf on my machine, 
then this is the output I get from "ipsec statusall":
000 "l2tp-psk": 
172.21.147.3[172.21.147.3]:17/1701---172.21.147.1...%any[%any]:17/%any; 
unrouted; eroute owner: #0

This is different from your output in the sense that it doesn't specify 
the 0.0.0.0/0 subnets.

Please post your complete /etc/ipsec.conf file to make sure that we're 
on the same page.
-Daniel


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

Re: [strongSwan] cannot respond to IPsec SA request because no connection is known

[Daniel Mentz]

On 07/09/2011 10:44 PM, Micah Anderson wrote:
> For some reason that i do not understand, I'm getting:
>
> Jul  9 22:37:41 kestrel pluto[3901]: "l2tp-psk"[2] 208.54.45.249:58920 #1: 
> cannot respond to IPsec SA request because no connection is known for 
> 198.252.153.38:4500[198.252.153.38]:17/1701...208.54.45.249:58920[26.164.21.104]:17/%any==={26.164.21.104/32}

>
> conn l2tp-psk
>authby=secret
>pfs=no
>compress=no
>rekey=no
>keyexchange=ikev1
>keyingtries=3
>type=transport
>leftprotoport=17/1701
>right=%any
>rightprotoport=17/%any
>auto=add

You specified transport mode in your config, right? However, it looks 
like your peer wants to setup a connection using tunnel mode:
It says

"208.54.45.249:58920[26.164.21.104]:17/%any==={26.164.21.104/32}"

which means that your peer is 208.54.45.249, and this peer wants to 
secure traffic for the subnet 26.164.21.104/32. This won't work in 
transport mode because in this mode both peers only secure their own 
traffic.
-Daniel

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

Re: [strongSwan] Test framework not showing iptables rules in tables other than 'filter'

[Daniel Mentz]

On 06/14/2011 11:59 PM, Andreas Steffen wrote:
> usually the console.log shows the setup of the additional
> iptables rules:
>
> http://www.strongswan.org/uml/testresults45/ikev2/nat-two-rw-mark/console.log

Hi Andreas and Johannes,

thank you for your quick responses.

I took note of the fact that console.log provides the iptables rules I 
was looking for, but I still think that this situation can be improved:

console.log does not show the rules created automatically by 
/etc/mark_updown. It would be desirable to have all rules from the 
mangle table in one place.

I would prefer iptables-save over "iptables -L" because the former 
outputs the rules in the format that is used by the iptables CLI. People 
are usually more familiar with this format.

Either way, I think it would be helpful to the reader if these rules 
were visible no matter in which format.

A shortcoming that I noticed here is that iptables-save prints the mark 
value in hexadecimal format which is different from the output of "ip 
xfrm policy" which uses a decimal representation.

Thanks
-Daniel

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

[strongSwan] Test framework not showing iptables rules in tables other than 'filter'

[Daniel Mentz]

I'm looking at the config example at

http://www.strongswan.org/uml/testresults45/ikev2/nat-two-rw-mark/index.html

and I'm wondering where I can find a complete list of all iptables rules 
that are in effect.

"iptables -L" only displays the rules in the filter table. The rules 
from the nat and mangle tables are missing.

Wouldn't it make more sense to use "iptables-save" to dump the complete 
picture. AFAICT, it outputs the nat and mangle table as well as the 
filter table.

Thanks
-Daniel

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

Re: [strongSwan] IP reassembly bug with strongSwan?

[Daniel Mentz]

On 05/30/2011 05:21 AM, daniel.mer...@rohde-schwarz.com wrote:
> for certain cases
> the responding virtual machine froze completely.
>

> the error occurs for fragmented packets only (in my case, the IKE_AUTH

Hi Daniel,

IP reassembly is done in the Linux kernel, not by user space processes. 
Also, even if there was a bug in strongSwan, only strongSwan should 
crash and not the whole machine since strongSwan runs as a daemon in 
user space.

If the Linux kernel had problems w/ IP reassembly, then this would be a 
severe bug since it would enable DoS attacks i.e. anybody on the 
Internet could bring down your system by sending these malicious IP packets.

Answers to the following questions might help people debugging this issue:

- With what version of the Linux kernel are you experiencing this issue? 
Did you try different versions?
- What virtualization platform are you using? KVM, ESXi, etc.
- Do you think it's possible that the virtualization infrastructure or 
some firewall is doing some kind of processing on the packet and that 
it's the virtualization platform that crashes.
- What do you mean by "the machine froze"? Do you have console access to 
the machine? Is it not responding at all or do you only lose network access?

-Daniel

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

Re: [strongSwan] Wireshark: cannot see outgoing IPsec packets

[Daniel Mentz]

On 05/20/2011 08:45 AM, Richard Chan wrote:
> Using wireshark and trying to sniff the cleartext packet, I can only see
> incoming packets.

That's a peculiarity of the Linux kernel. Capture the (UDP encapsulated) 
ESP packets and use wireshark to decrypt them. See

http://wiki.wireshark.org/ESP_Preferences

Run the following command to determine the encryption algorithms and the 
symmetric keys used by the kernel. Depending on your configuration, 
strongSwan periodically changes encryption keys. Keep this in mind if 
you're capturing traffic over an extended period of time.

ip xfrm state

-Daniel

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

Re: [strongSwan] StrongSWAN and AVM Fritzbox - Help!

[Daniel Mentz]

> If there's a way to detect the setup it would be great if "leftfirewall"
> automatically detects all rules for INPUT or FORWARD chain.

I believe that this is not doable because the rules in your 
INPUT/FORWARD chain can be very complex, too complex for a general 
solution. Even with the current solution where strongSwan appends ACCEPT 
rules to your FORWARD chain, you might run into problems. Imagine you 
have DROP rules in your chain that get triggered by the decrypted 
packets. Adding ACCEPT rules at the very end won't make a difference 
because these rules will never be examined.

I guess you're better off with manually managing these chains.

> Not yet. ;-)
> After ISP-forced DSL-disconnection (Thank you Deutsche Telekom AG :-( ) I
> have to restart IPSec on the Ubuntu machine (/etc/init.d/ipsec restart).
> Otherwise no IPSec connections can be established. Is there any
> configuration trick to
> reestablish the IPSec connection after disconnection/IP-change?

Restarting IPsec is a bad idea because it brings down not only the IPsec 
tunnels which are affected by the disconnect of this single interface 
but all IPsec tunnels negotiated by strongSwan.

After the disconnect, I guess you have to do a

ipsec update

(if your IP address changed)
I use
/usr/lib/ipsec/whack  --initiate --name $conn --asynchronous

for every IPsec connection. I also re-insert all the necessary source 
routes with

ip route add 192.168.x.y/z dev $PPP_IFACE src $SRCIP

Not sure if this is the best solution, however.
If you continue to have problems, then post the output of the following 
commands before and after the reconnect:

ip route show table 0
ip -4 address
ip xfrm policy
ip xfrm state
ipsec statusall

-Daniel

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

Re: [strongSwan] StrongSWAN and AVM Fritzbox - Help!

[Daniel Mentz]

On 02/13/2011 12:42 PM, Rene Bartsch wrote:
> On Sun, 13 Feb 2011 10:55:07 -0800, Daniel Mentz
>   wrote:
>> On 02/13/2011 08:49 AM, Rene Bartsch wrote:
>>> After removing "leftfirewall=yes" from ipsec.conf and adding the
> incoming
>>> FORWARD rule created by "leftfirewall=yes" to the INPUT chain manually,
>>> it
>>> seems to work.

> xxx.xxx.xxx.20:  eth0primary   public IP of Ubuntu 10.04.2 LTS server
> xxx.xxx.xxx.102: eth0:0  secondary public IP of Ubuntu 10.04.2 LTS server
> (IPSec connection)
> 192.168.176.1:   dummy0  Test for virtual servers
>
> eth0: 1000Base-T internet-uplink
> eth1: unused

Hi Rene,
so I guess there's a misunderstanding here. I thought your servers were 
"behind" your VPN gateway (your Ubuntu box), but it looks like your 
server daemons run on the same machine. That's why you set up the dummy0 
interface, I guess.
That's actually the reason, why the packets never hit the FORWARD chain. 
The fact that the IP address 192.168.176.1 is assigned to an interface 
which is different from the interface on which the ESP packets come in 
is not considered as forwarding. So I guess the rules which are created 
by "leftfirewall=yes" won't help you since you need those rules in your 
INPUT chain.

You were asking whether your setup might send any plaintext packets, 
right? If you're worried about that then you might want to change the 
default policy of the OUTPUT chain from ACCEPT to DROP and insert 
appropriate rules.

Does that answer your questions?

If you finally have a working setup, you might want to share your 
experience on the strongSwan wiki so that other users can benefit from it.

-Daniel

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

Re: [strongSwan] StrongSWAN and AVM Fritzbox - Help!

[Daniel Mentz]

On 02/13/2011 08:49 AM, Rene Bartsch wrote:
> After removing "leftfirewall=yes" from ipsec.conf and adding the incoming
> FORWARD rule created by "leftfirewall=yes" to the INPUT chain manually, it
> seems to work.

That's strange. Can you save the output of "iptables-save" in both cases 
and run a diff against both files to see what's the difference?

To avoid unsecured packets leaking the VPN gateway, I use the following 
rules.

# IPsec
# Allow traffic from and to subnet 10.111.11.0/24 through the IPSec tunnel.
iptables -A FORWARD -s 10.111.11.0/24 -m policy --dir out --pol ipsec -j 
ACCEPT
iptables -A FORWARD -d 10.111.11.0/24 -m policy --dir in --pol ipsec -j 
ACCEPT

# Do not forward packets to private ip addresses to the internet
iptables -A FORWARD -d 192.168.0.0/255.255.0.0 -o ppp0 -j REJECT 
--reject-with icmp-net-unreachable
iptables -A FORWARD -d 172.16.0.0/255.240.0.0 -o ppp0 -j REJECT 
--reject-with icmp-net-unreachable
iptables -A FORWARD -d 10.0.0.0/255.0.0.0 -o ppp0 -j REJECT 
--reject-with icmp-net-unreachable

The first rule permits traffic which is secured by IPsec. Rules 3 
through 5 make sure that traffic that is not secured by IPsec and is 
destined for private IP addresses will be rejected. This is important if 
in case IPsec is down.

> -A INPUT   -d xxx.xxx.xxx.102 -m policy --dir in --pol ipsec
>   -m comment --comment "ACCEPT IPSec secured packets"-j ACCEPT

I believe that this rule does not make sense since the dest. addr (-d 
a.b.c.d) should be the dest addr of the plaintext packet. 
xxx.xxx.xxx.102 is probably your public IP address and the dest addr of 
the ESP packet.

-Daniel

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

Re: [strongSwan] StrongSWAN and AVM Fritzbox - Help!

[Daniel Mentz]

On 02/13/2011 07:34 AM, Rene Bartsch wrote:
> The "leftfirewall=yes" option adds rules to FORWARD chain automatically at
> IPSec handshake:

Alright. Sorry, I missed that.


> I added a LOG target as last rule in INPUT and FORWARD chains. Trying a
> HTTP request with wget dropped the following packets:
>
> Feb 13 16:15:30 www kernel: [155830.694973] DROP INPUT:   IN=eth0 OUT=
> MAC=  SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00 PREC=0x00
> TTL=63 ID=10640 DF PROTO=TCP SPT=39744 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0

What is the host with IP address 192.168.176.1? Is that your Ubuntu 
server? If yes, then it makes sense that these packets hit the INPUT 
chain. It would be helpful if you could post the output of the following 
commands preferably as an attachment to your mail to avoid line wrapping:

ip -4 a
iptables-save

-Daniel

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

Re: [strongSwan] charon: 11[IKE] no private key found for 'bla-bla-bla'

[Daniel Mentz]

sftf wrote:
> Connection stop with "charon: 11[IKE] no private key found for..." followed 
> by gateway's cert ID.
> Private gateway's key is in /etc/ipsec.d/private/gw.superprime.ru-key.pem and 
> not encrypted.
> Looks like strongswan didn't "see" private key gw.superprime.ru-key.pem.

Putting your private key in /etc/ipsec.d/private/ is not enough. You 
also need to tell strongSwan about this key in /etc/ipsec.secrets. Check out

http://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets

You have to include something like

: RSA moonKey.pem

Note that strongSwan is picky about the exact format of this file. Don't 
forget the space character between ":" and "RSA".

Run "ipsec listcerts". It should output something like

   subject:  "CN=Foobar"
   issuer:   "CN=Example CA, e...@example.com"
   serial:01
   validity:  not before Sep 26 22:45:53 2009, ok
  not after  Sep 25 22:45:53 2012, ok
   pubkey:RSA 1024 bits, has private key
   keyid: 85:fb:d9:93:1b:d7:31:00:02:b6:38:57:c8:53:cb:22:b7:cd:c8:16
   subjkey:   66:83:4b:fb:d4:48:7f:2c:07:7d:d7:32:2a:da:64:00:57:0a:ba:70
   authkey:   d2:c4:db:03:58:9d:0d:aa:4a:6c:89:ad:6d:83:b7:47:f7:ff:3e:33


Watch out for "has private key". This tells you whether strongSwan was 
able to read the corresponding private key.

Does that answer your question?
-Daniel

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

Re: [strongSwan] Visit strongSwan at LinuxTag 2010 in Berlin

[Daniel Mentz]

Andreas Steffen wrote:
> Visit us at our booth 115 in hall 7.2b and attend the strongSwan
> workshop which will be scheduled either on Friday June 11 or
> Thursday June 10. We will post the exact time as soon as the
> information becomes available.

Hi Andreas,

I'm excited about this workshop and I do understand that the exact date 
and time is not yet set. But have you decided on the agenda of this 
workshop yet? I would love to learn about it. Can we i.e. the community 
express wishes regarding what will be covered during the workshop? I 
would be interested in learning about the mechanics of charon i.e. 
understand the source code and software design.

Best wishes
-Daniel


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

Re: [strongSwan] Tunnel up, no packets routed through

[Daniel Mentz]

Russ Cox wrote:
> The tunnel has come up ok, but no traffic appears to be getting routed
> through the tunnel.

Hi Ross,

could you please post the output of the following commands:

ip -4 a s
ip -4 r s t 0
iptables-save

Did you use tcpdump on both interfaces of the gateway in order to find 
out whether the gateway sends out ESP packets?

-Daniel


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

Re: [strongSwan] Is there possible for strongswan to support IKEv1 and IKEv2 at the same time at the same ho st?

[Daniel Mentz]

Andreas Steffen wrote:
> in the default configuration the pluto daemon binds to the UDP ports 500
> and 4500 whereas the charon daemon uses a raw socket with Linux
> Socket Filter (LSF) rules filtering and forwarding IKE version 2
> messages to the IKEv2 daemon. Thus it is no problem to use racoon
> in place of charon for handling IKEv1 connections.

I'm wondering if it should say "it is no problem to use racoon in place 
of *pluto* for handling IKEv1 connections." charon implements IKEv2 
whereas pluto implements IKEv1.
-Daniel


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

Re: [strongSwan] routing all traffic through tunnel without local one

[Daniel Mentz]

Peter Winterer wrote:
> Hi Daniel,
> 
> Am 08.03.2010 10:02, schrieb Daniel Mentz:
>> Matthias Dahl wrote:
>>>> To tunnel all internet traffic, you'll need a 0.0.0.0/0 rightsubnet.
>>>> This however, includes your local network in the tunnel too.
>>>
>>> One could consider this a bug. Most people certainly never will want 
>>> their
>>> local traffic routed outside of their local network. The more I think 
>>> about
>>> it, this could even have security implications. The default should be 
>>> to have
>>> the local lan by-passed unless the user explicitely states otherwise.
>>
>> One might also argue that the current behavior is more secure: Imagine a
>> road warrior being in a hotel room, connecting her laptop to the hotel's
>> LAN in order to get Internet access. She probably does not care about
>> other hosts on the local subnet. She just wants to have access to the
>> corporate network via IPsec.
>>
>> Now, imagine that the hotel's LAN uses the same IP address space as some
>> resource on the corporate network. The traffic would then be sent to the
>> incorrect machine on the local subnet of the hotel that happens to have
>> the same IP address, instead of the machine on the corporate network.
> 
> I think you are right. However, what about dhcp traffic in the local
> network? A client could not renew his ip address, because the dhcp
> traffic on the local dhcp-server would also be blocked. I'm not sure, 
> but I think with a linux client this would break the connection and 
> therefore the ipsec-tunnel.

Hi Peter,

that is indeed an interesting question. I guess one of the following is 
true:

1. DHCP fails as you suspect.

2. The dhcp-client uses raw sockets to send/receive IP packets. Maybe 
ipsec policies do not apply to IP packets sent via raw sockets.

3. The dhcp-client sets a "per socket policy" of type 
IPSEC_POLICY_BYPASS. As a consequence, IP packets which are sent or 
received on that socket are not subject to IPsec processing. If you can 
read German, take a look at http://mirror.roe.ch/doc/hsr/sa-natt.pdf and 
search for "Per socket policy". This document has some good information 
about this socket option.

-Daniel



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

Re: [strongSwan] routing all traffic through tunnel without local one

[Daniel Mentz]

Matthias Dahl wrote:
>> To tunnel all internet traffic, you'll need a 0.0.0.0/0 rightsubnet.
>> This however, includes your local network in the tunnel too.
> 
> One could consider this a bug. Most people certainly never will want their 
> local traffic routed outside of their local network. The more I think about 
> it, this could even have security implications. The default should be to have 
> the local lan by-passed unless the user explicitely states otherwise.

One might also argue that the current behavior is more secure: Imagine a 
road warrior being in a hotel room, connecting her laptop to the hotel's 
LAN in order to get Internet access. She probably does not care about 
other hosts on the local subnet. She just wants to have access to the 
corporate network via IPsec.

Now, imagine that the hotel's LAN uses the same IP address space as some 
resource on the corporate network. The traffic would then be sent to the 
incorrect machine on the local subnet of the hotel that happens to have 
the same IP address, instead of the machine on the corporate network.

-Daniel

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

Re: [strongSwan] routing all traffic through tunnel without local one

[Daniel Mentz]

Matthias Dahl wrote:
> And those are the routes:
> 
> 192.168.2.0/24 dev br0  scope link  metric 5 
> 127.0.0.0/8 via 127.0.0.1 dev lo 
> default via 192.168.2.1 dev br0  proto static  src 172.31.25.1 
> default via 192.168.2.1 dev br0  metric 5 
> 
> Like I said, I have no idea whatsoever but it works now. Since I am new to 

Hi Matthias,

let me explain what I think is the reason:

The routing table is key to answering this question.
If you send a packet to a host which is on the local subnet, say 
192.168.2.1 for example, the kernel will query the routing table first. 
The route that the kernel is going to pick is

192.168.2.0/24 dev br0  scope link  metric 5

because it is the most specific one i.e. it has the longest prefix. This 
route does not specify a source address which is why the kernel picks an 
address that is assigned to br0. In your case it's 192.168.2.132, right?

Now, let's have a look at the IPsec policy:
src 172.31.25.1/32 dst 0.0.0.0/0 uid 0

It *only* applies to packets that have 172.31.25.1 as the source 
address. However, the src address of your packet is different: 
192.168.2.132. That's why this packet is not subject to IPsec processing.


Having said that, let us look at the default route which is

default via 192.168.2.1 dev br0  proto static  src 172.31.25.1

This route is taken into account for non-local traffic. The source 
address of packets that are bound for non-local destinations will be 
172.31.25.1. This is why the IPsec policy is effective for non-local 
traffic only.

So in your case, it's all about the source address.
Remember the two facts:

- IPsec policies apply only to packets with specific src and dst addresses.
- The routing table specifies (in some cases) the src address for 
traffic that originates from local applications.


Does that make sense to you?
I'll try to come up with this bypass policy later today.

-Daniel

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

Re: [strongSwan] Certificates in cacerts directory

[Daniel Mentz]

ABULIUS, MUGUR (MUGUR) wrote:
>> If rightca is specified then we only request certificates issued by rightca.
>> Otherwise we send certificate requests for all CAs contained in 
>> /etc/ipsec.d/cacerts/
> 
> If "rightca=" is specified, then it is required that a certificate matching 
> the specified
> DN to be present locally in "/etc/ipsec.d/cacerts/" ?

I guess yes. I mean strongSwan has to read the certificate from somewhere.
You could also create a ca section as described at

http://wiki.strongswan.org/projects/strongswan/wiki/CaSection

if you want to store the certificate in a non-default location.

-Daniel


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

Re: [strongSwan] Possibly a bug in charon when auto=start

[Daniel Mentz]

Hi Vladimir,

I recommend not to depend on IPsec policies if you want to enforce that 
no unencrypted traffic leaves the gateway and that no unprotected 
traffic is accepted.

Use the policy match provided by iptables. Here's an example:

iptables -A FORWARD -m policy --dir out --pol ipsec -j ACCEPT
iptables -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT
# Do not forward packets to or from xyz if ipsec is off
iptables -A FORWARD -d 1.2.3.4/26 -j REJECT --reject-with 
icmp-net-unreachable
iptables -A FORWARD -s 1.2.3.4/26 -j REJECT --reject-with 
icmp-net-unreachable

-Daniel

> Martin, thank you for clarification.
> I think it will be good if this 'auto=start' feature will be documented in 
> ipsec.conf(5) man page.
> Because a strongswan-newbie sysadmin may use this option without knowing that 
> unencrypted packets are not filtered if the tunnel is not up yet. This may be 
> a serious vulnerability of a system.
> 
> Thank you!
> Best regards, Vladimir
> 
> 
>> Yes, this is the intended behavior. auto=start does not install policies
>> until the tunnel has been negotiated. auto=route installs the policies
>> and triggers a tunnel when required.
> 
> 
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users


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

Re: [strongSwan] Please help - Using strongSwan to connect to CheckPoint VPN-1

[Daniel Mentz]

Hi Jana,

please go to

http://wiki.strongswan.org/projects/strongswan/wiki/IKEv1Examples

for IKEv1 Configuration Examples. "PSK with XAUTH authentication and 
virtual IP addresses" or "RSA with XAUTH authentication and virtual IP 
addresse" is probably the right one for you.

Please refer to

http://wiki.strongswan.org/projects/strongswan/wiki/IpsecConf

for definitions of the individual parameters.

-Daniel


Sucha Singh wrote:
> Hi Andreas,
> 
> Thank you for your prompt response, I appreciate it.  I can confirm that we 
> are indeed using IKEv1 Main Mode.
> 
> I have the pluto daemon installed, however I have no idea how to configure 
> the ipsec.conf file.  I have opened it in a text editor and I am struggling 
> to make sense of most of the parameters.  I can't appear to find anything in 
> the online documentation to define what the parameters mean.
> 
> Could you possibly construct the file for me based on the information I have 
> already supplied?  I will fill the blanks like site IP address etc.
> 
> Thanks again for your time and support.
> 
> Jana
> 
> --- On Sun, 28/2/10, Andreas Steffen  wrote:
> 
> From: Andreas Steffen 
> Subject: Re: [strongSwan] Please help - Using strongSwan to connect to 
> CheckPoint VPN-1
> To: "Sucha Singh" 
> Cc: users@lists.strongswan.org
> Date: Sunday, 28 February, 2010, 12:12
> 
> Hi,
> 
> as far as I know, the CheckPoint VPN gateway does not support the IKEv2
> protocol. Therefore you can't use the strongSwan NetworkManager plugin
> to set up a connection.
> 
> The CheckPoint VPN gateway most probably will use IKEv1 and XAUTH.
> The first thing to find out is whether IKEv1 Main Mode is used
> by the CheckPoint box since strongSwan does not support the
> potentially insecure IKEv1 Aggressive Mode. If Main Mode is
> possible then you can configure strongSwan's IKEv1 pluto daemon
> via /etc/ipsec.conf.
> 
> Best regards
> 
> Andreas
> 
> Sucha Singh wrote:
>> Hi,
>>
>> I'm looking to use strongSwan to connect to my company CheckPoint
>> VPN, as I am new to Linux and networking I am really struggling to
>> get anything working.  I have a Actividentity token that generates a
>> password that authenticates against a RADIUS server, below is a list
>> of facts I know from my CheckPoint config from Windows:
>>
>> I have an IP address for company site Authentication - Challenge
>> Response NAT-T protocol - enabled Office Mode - enabled Use NAT
>> traversal tunneling - enabled IKE over TCP - enabled Force UDP
>> encapsulation - enabled
>>
>> I have attempted to use the Network Manager GUI to connect but it
>> fails with "VPN service failed to start", the syslog file contains a
>> host of errors.  The settings I attempted were:
>>
>> Gateway: Address - IP address of my company site Certificate - None
>>
>> Client: Authentication - EAP Username - My id I use for my token to
>> generate password
>>
>> Options - Request an inner IP address - unchecked Enforce UDP
>> encapsulation - checked Use IP compression - unchecked
>>
>> My questions would be:
>>
>> 1) Does strongSwan support the protocols/authentication methods I
>> describe for CheckPoint VPN 2) If yes, then does my setup through
>> Network Manager look correct 3) If yes, then is it a case of posting
>> the sys.log errors for someone to kindly look at
>>
>> I appreciate anyone's help and time with this.
>>
>> Regards,
>>
>> Jana
> 
> ==
> Andreas Steffen andreas.stef...@strongswan.org
> strongSwan - the Linux VPN Solution!www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===[ITA-HSR]==
> 
> 
> 
>   
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users


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

Re: [strongSwan] Home network config

[Daniel Mentz]

Hi Raza,

I never used the L2TP/IPsec client so I can't tell how to set it up.

If you want to use plain IPsec you have - in my opinion - the following 
options:

IKEv1:
WindowsXP + NCP Secure Entry Client for Win32/64 (142 EUR)
WindowsXP + Shrew Soft VPN client (free of charge)
Windows 7 + NCP Secure Entry Client for Win32/64 (142 EUR)

IKEv2:
Windows 7 + built-in IKEv2 VPN client

If you decide to use IKEv1, you are going to setup the pluto daemon 
(plutostart=yes). If you want to use IKEv2 you are going to use the 
charon daemon on the strongSwan side.

You have to make sure that your NAT router forwards packets destined for 
192.168.1.0/24 to your strongSwan box.

Do you know how to create X.509 certificates?

If you want to use Windows 7 you could use a connection definition which 
is similar to

config setup
 charonstart=yes
 plutostart=no

conn win7
 keyexchange=ikev2
 ike=aes256-sha1-modp1024!
 esp=aes256-sha1!
 dpdaction=clear
 dpddelay=300s
 rekey=no
 left=%any
 leftsubnet=0.0.0.0/0
 leftauth=pubkey
 leftcert=razz_home_network.pem
 left...@vpn.razz.net
 right=%any
 rightsourceip=192.168.1.0/24
 rightauth=eap-mschapv2
 rightsendcert=never
 eap_identity=%any
 auto=add

There's one issue I have with Windows 7: The native IPsec client sends 
all IP traffic through the IPsec tunnel; even traffic that is not 
destined for your home network. As a consequence, if the road warrior 
accesses some site on the internet, the traffic will be sent through 
your strongSwan box at home.

-Daniel

Razza wrote:
> Hi Daniel,
> I was thinking of the bundled L2TP/IPsec client, I don't mind paying for 
> a VPN client if there are better/more flexible options. If the client is 
> over £30 ($40) I would rather just buy Win 7.
> I am happy with a different range, say 192.168.1.0/24 
> <http://192.168.1.0/24> for the VPN users.
> 
> Kind regards,
> 
> 
> On 19 February 2010 12:29, Daniel Mentz 
>  <mailto:danielml%2bmailinglists.strongs...@sent.com>> wrote:
> 
> Hi Razza,
> 
> you need to setup your DSL/NAT Router to forward UDP datagrams
> destined for ports 500 and 4500 to your strongSwan box.
> You said that you want to allocate IP addresses for road warriors
> inside the 192.168.10.0/24 <http://192.168.10.0/24> range. This
> could be difficult to achieve. Can you waive this requirement and
> come up with a separate IP prefix for road warriors? Like
> 10.x.y.0/24? This would make things much easier.
> 
> I'm using this kind of setup for Win7 clients. Which IPsec client
> software do you want to use on Windows XP?
> 
> -Daniel
> 
> 
> Razza wrote:
> 
> Hi all, I’m new to the list and am looking for a bit of advice.
> I’ve looked
> around but can’t find any examples close to what I want to
> achieve, probably
> because it’s flawed from a purists security view point. Anyway,
> I want to
> use strongSwan in a home network environment, mainly so I can
> access home
> network machines whilst I’m away. E.g. ssh to my asterisk
> server, RDP/VNC to
> my partners machine etc.
> 
> 
> 
> My network is as follows –
> 
> 
> 
> 192.168.10.0/24 <http://192.168.10.0/24> -- | 192.168.10.1 | |
> Dynamic RIPE IP | -- Internet
> 
>  Home Network |  Inside i/f  | |   Outside i/f   |
> 
>   | DSL/NAT Router   |
> 
> 
> 
> As I only have a single RIPE address on my DSL, I intend to port
> forward
> necessary ports to a single interface on my strongSwan box.
> 
> My strongSwan box will have an address in the range
> 192.168.10.0/24 <http://192.168.10.0/24>. I would
> prefer to have a singe physical interface if possible, but could
> have two.
> 
> When I connect from an internet connected machine (soon Win7,
> currently XP),
> I would like to be allocated a virtual IP in the range of my
> home network (
> 192.168.10.0/24 <http://192.168.10.0/24>).
> 
> 
> Is this possible?
> ___
> Users mailing list
> Users@lists.strongswan.org <mailto:Users@lists.strongswan.org>
> https://lists.strongswan.org/mailman/listinfo/users
> 
> 
> 


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

Re: [strongSwan] Home network config

[Daniel Mentz]

Hi Razza,

you need to setup your DSL/NAT Router to forward UDP datagrams destined 
for ports 500 and 4500 to your strongSwan box.
You said that you want to allocate IP addresses for road warriors inside 
the 192.168.10.0/24 range. This could be difficult to achieve. Can you 
waive this requirement and come up with a separate IP prefix for road 
warriors? Like 10.x.y.0/24? This would make things much easier.

I'm using this kind of setup for Win7 clients. Which IPsec client 
software do you want to use on Windows XP?

-Daniel


Razza wrote:
> Hi all, I’m new to the list and am looking for a bit of advice. I’ve looked
> around but can’t find any examples close to what I want to achieve, probably
> because it’s flawed from a purists security view point. Anyway, I want to
> use strongSwan in a home network environment, mainly so I can access home
> network machines whilst I’m away. E.g. ssh to my asterisk server, RDP/VNC to
> my partners machine etc.
> 
> 
> 
> My network is as follows –
> 
> 
> 
> 192.168.10.0/24 -- | 192.168.10.1 | | Dynamic RIPE IP | -- Internet
> 
>   Home Network |  Inside i/f  | |   Outside i/f   |
> 
>| DSL/NAT Router   |
> 
> 
> 
> As I only have a single RIPE address on my DSL, I intend to port forward
> necessary ports to a single interface on my strongSwan box.
> 
> My strongSwan box will have an address in the range 192.168.10.0/24. I would
> prefer to have a singe physical interface if possible, but could have two.
> 
> When I connect from an internet connected machine (soon Win7, currently XP),
> I would like to be allocated a virtual IP in the range of my home network (
> 192.168.10.0/24).
> 
> 
> Is this possible?
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users


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

Re: [strongSwan] Policies should be available in Kernel even though SA is not established!

[Daniel Mentz]

ashish mahalka wrote:
> establishes SA b/w the peers, it should over-write those discard
> policies and install ipsec policies in the kernel. Is this possible ?

Hi Ashish,

sorry, but I do not like this idea much. With your design, both, 
strongSwan and your shell scripts access the policy database. I'm afraid 
that this will end up in a complete mess. I suggest that you either have 
strongSwan *or* your shell scripts manipulate the SPD.

> How would I know the reqId of the strongswan's connection ?

I guess you could just temporarily set installpolicy=yes and find out by 
executing "ip xfrm policy" what reqids strongSwan allocates for each 
individual connection. However, from looking at the source code, I get 
this feeling that those IDs might change if you swap the order of the 
connections in ipsec.conf or if you add new connection definitions.

I'm not exactly sure what you are trying to achieve. I guess you want to 
make sure that none of those IP packets that should be protected, leaves 
the gateway unencrypted. From my experience, I suggest to use some 
iptables rules in combination with the policy match.

Here are the rules that I crafted for our gateway. Maybe you can take 
advantage of these:

iptables -A FORWARD -s 192.168.10.0/24 -m policy --dir out --pol ipsec 
-j ACCEPT
iptables -A FORWARD -d 192.168.10.0/24 -m policy --dir in --pol ipsec -j 
ACCEPT

# Do not forward packets to or from MUCDMZ (Muenchen DMZ) if ipsec is off
iptables -A FORWARD -d 80.14.76.128/26 -j REJECT --reject-with 
icmp-net-unreachable
iptables -A FORWARD -s 80.14.76.128/26 -j REJECT --reject-with 
icmp-net-unreachable

The idea is basically to accept traffic that is secured by IPsec. A 
subsequent rule makes sure that traffic that did not match the IPsec 
rule will be rejected.

Does this help?

-Daniel


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

Re: [strongSwan] Policies should be available in Kernel even though SA is not established!

[Daniel Mentz]

Hi Ashish,

I guess strongSwan does not touch the policies at all if you set 
installpolicy=no but I'm not sure about that. Another question is what 
the reqid of the manually installed policy should be. Maybe the 
strongSwan core team can answer this question.

-Daniel


ashish mahalka wrote:
> Hi Daniel,
> 
> I did try with auto=route option. But i guess it is same as "ipsec
> route " because it just added the outbound policy in the kernel.
> Moreover, I am not favouring this option, because the SA's get
> established only when the packets are sent.
> 
> I am currently using the default value of installpolicy which is "yes"
> . As you say when installpolicy=no, I can install the policies myself.
> Does that mean strongswan would not over-write these policies when SA
> is created ? Or it would be able to over-write in case it does ?
> 
> regards,
> Ashish
> 
> On 2/15/10, Daniel Mentz  wrote:
>> Hi Ashish,
>>
>> did you try
>>
>> auto=route
>>
>> in ipsec.conf? strongSwan should then install the policies and leave
>> them installed if the connection goes down. An outgoing packet triggers
>> a negotiation of an appropriate SA.
>>
>> It might also be worth having a look at the "installpolicy" parameter:
>>
>> ---QUOTE---
>> installpolicy = yes | no
>>
>> decides whether IPsec policies are installed in the kernel by the IKEv2
>> charon daemon for a given connection.
>> Allows peaceful cooperation e.g. with the Mobile IPv6 mip6d daemon who
>> wants to control the kernel policies.
>> ---END QUOTE---
>>
>> If you use installpolicy=no, you might be able to install the policies
>> by yourself.
>>
>> -Daniel
>>
>>
>>
>> ashish mahalka wrote:
>>> Hello Andreas,
>>>
>>> Hope you are having a good time! I have certain queries for which if
>>> you can provide me answers/solutions would be really great.
>>>
>>> #1 - Policies should be available in the kernel even though SA is not
>>> established.
>>> I have this particular requirement wherein the kernel should have all
>>> the policies in its database even though strongswan fails to establish
>>> the SA. Right now policies are put by strongswan only when the SA's
>>> have been established.
>>> I tried to overcome this limitation by manually adding the policies
>>> using "ip xfrm policy add" command. But when strongswan established
>>> the SA and tried to over-write already existing kernel policies, it
>>> failed. Is this expected or something is going wrong here ?
>>> Then I came across "ipsec route" command which adds the policies in
>>> the kernel. When I executed the command "ipsec route ", it
>>> added only the outbound policy. Whereas I need both inbound/outbound
>>> policy.Again is this behaviour correct ? Can some modification be done
>>> to include inbound policies also with this command ?
>>>
>>> #2 - When the connection goes down, the policies should be updated in
>>> the kernel.
>>> Again this requirement arises from the fact that when a particular
>>> connection goes down, the SA/SPD in the kernel also gets deleted. But
>>> I need to still have the policies in the kernel.
>>> To get this work done, I made use of "left|rightupdown" option
>>> available in the ipsec.conf. I wrote a small shell-script and made use
>>> of PLUTO_ macros available in strongswan to get the policy details. I
>>> was successful till here. But I have some conflicting observations:
>>> a) In case of pluto, when I execute the command "ipsec down ",
>>> my script is executed when "down-client" case arises. Here I tried to
>>> add the polices in the kernel using ip xfrm policy add command. It
>>> failed because the strongswan policies were still there in the kernel
>>> at this point.
>>> b) In case of charon, on saying "ipsec down ", my script was
>>> never executed. I remember you mentioning that in case of charon,
>>> ipsec update does not delete the old SAs/SPs. But I have observed that
>>> if you just say connection down on one peer only, the SAs/SPs are
>>> still there. You have to execute conn down in both the peers to remove
>>> the SAs/SPs. Can this be modified so that charon deletes the SAs/SPs
>>> when we say conn down on local peer.
>>>
>>> #3.  Deleting the strongswan configured policies through external
>>> application.
>>> Is it p

Re: [strongSwan] Policies should be available in Kernel even though SA is not established!

[Daniel Mentz]

Hi Ashish,

did you try

auto=route

in ipsec.conf? strongSwan should then install the policies and leave 
them installed if the connection goes down. An outgoing packet triggers 
a negotiation of an appropriate SA.

It might also be worth having a look at the "installpolicy" parameter:

---QUOTE---
installpolicy = yes | no

decides whether IPsec policies are installed in the kernel by the IKEv2 
charon daemon for a given connection.
Allows peaceful cooperation e.g. with the Mobile IPv6 mip6d daemon who 
wants to control the kernel policies.
---END QUOTE---

If you use installpolicy=no, you might be able to install the policies 
by yourself.

-Daniel



ashish mahalka wrote:
> Hello Andreas,
> 
> Hope you are having a good time! I have certain queries for which if
> you can provide me answers/solutions would be really great.
> 
> #1 - Policies should be available in the kernel even though SA is not
> established.
> I have this particular requirement wherein the kernel should have all
> the policies in its database even though strongswan fails to establish
> the SA. Right now policies are put by strongswan only when the SA's
> have been established.
> I tried to overcome this limitation by manually adding the policies
> using "ip xfrm policy add" command. But when strongswan established
> the SA and tried to over-write already existing kernel policies, it
> failed. Is this expected or something is going wrong here ?
> Then I came across "ipsec route" command which adds the policies in
> the kernel. When I executed the command "ipsec route ", it
> added only the outbound policy. Whereas I need both inbound/outbound
> policy.Again is this behaviour correct ? Can some modification be done
> to include inbound policies also with this command ?
> 
> #2 - When the connection goes down, the policies should be updated in
> the kernel.
> Again this requirement arises from the fact that when a particular
> connection goes down, the SA/SPD in the kernel also gets deleted. But
> I need to still have the policies in the kernel.
> To get this work done, I made use of "left|rightupdown" option
> available in the ipsec.conf. I wrote a small shell-script and made use
> of PLUTO_ macros available in strongswan to get the policy details. I
> was successful till here. But I have some conflicting observations:
> a) In case of pluto, when I execute the command "ipsec down ",
> my script is executed when "down-client" case arises. Here I tried to
> add the polices in the kernel using ip xfrm policy add command. It
> failed because the strongswan policies were still there in the kernel
> at this point.
> b) In case of charon, on saying "ipsec down ", my script was
> never executed. I remember you mentioning that in case of charon,
> ipsec update does not delete the old SAs/SPs. But I have observed that
> if you just say connection down on one peer only, the SAs/SPs are
> still there. You have to execute conn down in both the peers to remove
> the SAs/SPs. Can this be modified so that charon deletes the SAs/SPs
> when we say conn down on local peer.
> 
> #3.  Deleting the strongswan configured policies through external application.
> Is it possible to delete the strongswan policies manually ?
> I tried deleting policies configure in the kernel through strongswan
> but got some NETLINK error.
> I executed the following command.
> /sbin/ip xfrm policy delete 10.10.10.0/24 10.10.10.0/24 proto 6 sport
> 200 dport 200 dir out action allow/block.
> Basically I tried both allow/block options in the "action" field. But
> it failed. Is there any other way to remove the strongswan policies ?
> Do we need to make use of reqId.
> 
> It would be really nice if you could give me some pointers on how to
> go about meeting this requirments.
> 
> Thanks for all the help in advance!
> 
> regards,
> Ashish.
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

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

[strongSwan] Documentation: IKEv2CipherSuites, Integrity Algorithms

[Daniel Mentz]

I'm wondering if we should change the wiki page

http://wiki.strongswan.org/wiki/strongswan/IKEv2CipherSuites

so that it maps to

http://www.iana.org/assignments/ikev2-parameters

I'm focusing on "Integrity Algorithms" at this moment: I suggest to add 
additional columns that refer to the information given in the IANA 
document. An example should help clarify this:

Keyword: sha2_256 or sha256
Description: SHA2_256_128 HMAC
IKE: 128 bit
ESP: 128 bit
Name (according to IANA) (new column): AUTH_HMAC_SHA2_256_128
Registry Number (new column): 12

I also suggest to make it very clear that sha2_256_96 is not a standard 
transformation but Linux/strongSwan proprietary. Also, please mention 
the registry number you allocated in the "private use" block.

I do believe that interoperability does benefit from this documentation 
change.

I can help out and take care of the changes if you let me.

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

Re: [strongSwan] Problems with network-manager-strongswan on Ubuntu Karmic

[Daniel Mentz]

Patrick Ben Koetter wrote:
> * Andreas Steffen :
>> the Debian/Ubuntu package is based on strongSwan 4.2.9 without any
>> augmentations. The ipsec.secrets include feature has always been in
>> the man pages because the IKEv1 pluto daemon supported it. We have just
>> recently extended this feature to the IKEv2 charon daemon triggered by
>> a user request.
> 
> let me rephrase: The current Debian/Ubuntu package does not support an include
> statement in ipsec.secrets. It's an implementation fault. Don't use it. ;)

Servus Patrick,

that's, in my opinion, a bit confusing for new users:

strongSwan ships two daemons

- charon which implements the new IKEv2 protocol and
- pluto which implements the old IKEv1 protocol.

You are using charon for your setup.

The thing that is IMHO confusing is that *both* daemons read the *same* 
config files (ipsec.conf and ipsec.secrets) but interpret them 
*differently* in some cases.

As regards the old strongSwan version you are using, pluto does support 
include statements whereas charon does not. As a result, it depends on 
which daemon is reading the config file. Newer versions of charon do 
support the include statement. So the behavior is more consistent with 
newer versions of strongSwan.

Does that make sense?

-Daniel

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

Re: [strongSwan] Problems with network-manager-strongswan on Ubuntu Karmic

[Daniel Mentz]

Patrick Ben Koetter wrote:
> Jan 31 23:05:50 gw charon: 07[IKE] no private key found for 'C=DE, ST=Bayern, 
> L=Muenchen, O=State of Mind, OU=VPN, CN=gw.state-of-mind.de, 
> e...@state-of-mind.de' 
> 
> This should be at least the current problem, right?

Correct. Please post the output of

ipsec listcerts

It should say something like

000   pubkey:RSA 1024 bits, has private key

for the certificate of the subject 'C=DE, ST=Bayern, L=Muenchen, O=State 
of Mind, OU=VPN, CN=gw.state-of-mind.de, e...@state-of-mind.de'

Check your /etc/ipsec.secrets file. Make sure it's in the correct 
format. Also, try "ipsec rereadsecrets" and check the log file for error 
messages.

-Daniel

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

Re: [strongSwan] Problems with network-manager-strongswan on Ubuntu Karmic

[Daniel Mentz]

Patrick Ben Koetter wrote:
> Jan 31 19:29:55 x300 charon: 10[ENC] parsed IKE_AUTH response 1 [ 
> N(AUTH_FAILED) ]
> Jan 31 19:29:55 x300 charon: 10[IKE] received AUTHENTICATION_FAILED notify 
> error

Please send the log file of the remote endpoint. This will help in 
investigating *why* the remote endpoint sent a AUTHENTICATION_FAILED.
-Daniel
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] rightid=%any or wild characters - ikev1 not working

[Daniel Mentz]

Hi Ashish,

when I carried out the test, I was thinking about an instance of 
strongSwan that only *responds* to connection setup requests. I did not 
have strongSwan *initiate* connections.

What you are basically saying to strongSwan is:

"Initiate a connection to 10.10.10.2. Ignore the identity of the peer 
because I do not know it. But make sure that the peer has a valid 
certificate that is signed by a CA I trust."

This kind of configuration is unusual in my opinion because you are 
trying to initiate a connection but you do not even know what the 
identity of the peer is.

However, it makes sense to *respond* to requests from unknown peers 
because those requests might come from road warriors.

I'm afraid that pluto simply does not support the kind of configuration 
you are thinking about. Charon apparently does support it.

I do not know whether this is a limitation of the protocol (IKEv1) or 
the implementation (pluto).

I suggest addressing the strongSwan core developers and ask if there is 
a way to overcome this limitations.

-Daniel

ashish mahalka wrote:
> Hi Daniel,
> 
> Yes, you are correct. I know the remote IP address but dont know the
> DN of the remote peer. If I remember correctly, when using DN
> wildcards, I was getting error which said
> "cannot initiate connection with wildcards". I am using strongswan 4.3.4.
> 
> Can you tell me what version of strongswan u r using ? Also, would it
> be possible to establish the connection if we specify
> rightid="/CN=*/", though the DN of the peer contains all the values( I
> mean C, ST, O,...)
> 
> If possible, can you please test on your setup, if specifying
> rightid="C=*, ST=*, O=*, OU=*, CN=*, E=*" like this establishes the 
> connection.
> 
> Thanks in advance!
> 
> regards,
> Ashish.
> 
> On 1/19/10, Daniel Mentz  wrote:
>> Hi Ashish,
>>
>> here are my test results:
>>
>> You can't use right=1.2.3.4 and right=%any at the same time i.e. you
>> can't specify an IP address for the remote end and use %any for the ID.
>>
>> However, DN wildcards appear to work ok. I just spotted a typo in your
>> original mail:
>>
>> rightid="C*, ST=*, O=*, OU=*, CN=*, E=*"
>>
>> You're missing a character there. It's should be:
>>
>> rightid="C=*, ST=*, O=*, OU=*, CN=*, E=*"
>>
>>
>> I successfully tested it with a simpler pattern:
>>
>> rightid="/CN=*/"
>>
>> I should mention, though, that the certificate I'm using only has a
>> Common Name (CN), no other RDNs.
>>
>> What I can read from your config files is that you do know the remote IP
>> address but you do not know the DN of the peer. Is that correct?
>>
>> -Daniel
>>

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

Re: [strongSwan] rightid=%any or wild characters - ikev1 not working

[Daniel Mentz]

Hi Ashish,

here are my test results:

You can't use right=1.2.3.4 and right=%any at the same time i.e. you 
can't specify an IP address for the remote end and use %any for the ID.

However, DN wildcards appear to work ok. I just spotted a typo in your 
original mail:

rightid="C*, ST=*, O=*, OU=*, CN=*, E=*"

You're missing a character there. It's should be:

rightid="C=*, ST=*, O=*, OU=*, CN=*, E=*"


I successfully tested it with a simpler pattern:

rightid="/CN=*/"

I should mention, though, that the certificate I'm using only has a 
Common Name (CN), no other RDNs.

What I can read from your config files is that you do know the remote IP 
address but you do not know the DN of the peer. Is that correct?

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

Re: [strongSwan] rightid=%any or wild characters - ikev1 not working

[Daniel Mentz]

Hi Ashish,

thank you for the log files. The following lines which I copied from 
pluto-host2.log are the most interesting:

"conn1" #1: no suitable connection for peer 'C=IN, ST=KAR, O=WIPRO, 
OU=NSN, CN=wipro.com, e=...@wipro.com'
"conn1" #1: sending encrypted notification INVALID_ID_INFORMATION to 
10.10.10.2:500

Please get rid of "rightid=%any" on host2. Execute the command

ipsec update
and
ipsec statusall

Please send the output of the last command. Try to setup the connection 
again with "rightid=%any" removed and send the log file of host2.

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

Re: [strongSwan] ping: sendmsg: Operation not permitted

[Daniel Mentz]

Could you please send the output of the following two commands:

ip -4 route show table 0

iptables-save

and of the following two:

ip xfrm policy
ip xfrm state

Plus the output of the ping command as you sent it in your last e-mail.
Please make sure to execute these commands at a point in time when one 
of the connections is in a failing state.

-Daniel

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

Re: [strongSwan] rightid=%any or wild characters - ikev1 not working

[Daniel Mentz]

ashish mahalka wrote:
> rightid=%any or rightid="C*, ST=*, O=*, OU=*, CN=*, E=*"
> 
> I get an INVALID_ID_INFORMATION error.

Please provide more information than that. Please send the ipsec.conf 
files of both peers. Plus the syslog output.
If one end-point receives an INVALID_ID_INFORMATION error, the log file 
of the other peer usually contains provides information about the reason 
why it sent INVALID_ID_INFORMATION.

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

Re: [strongSwan] [strongswan]ikev2 with plutostart=yes

[Daniel Mentz]

ashish mahalka wrote:
> I checked the config.log in my host-2 machine.
> 
> I did observe the following lines:
> USE_PLUTO_FALSE='#'
> USE_PLUTO_TRUE='' "

You said, you built strongSwan by yourself. Please check if you have the 
file

strongswan-4.3.5/src/charon/socket-raw.o

You could also try deleting the file

strongswan-4.3.5/src/charon/network/socket.c

in order to make sure that the raw socket and not the regular UDP socket 
abstraction is compiled.

If you disable pluto, the build system compiles socket.c instead of 
socket-raw.c which is compiled if pluto is enabled.

Inside the source tree please execute

strings ./src/charon/.libs/charon | grep "data on raw socket"

and send the output.

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

Re: [strongSwan] [strongswan]ikev2 with plutostart=yes

[Daniel Mentz]

ashish mahalka wrote:
> _Host-2_
> 
> netstat --raw -a -p
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address   Foreign 
> Address State   PID/Program name
>  

Hi Ashish,

to me it looks like something is wrong with the charon binary an host 2. 
Everything suggests that it does not have support for the raw socket 
built in.

You said that you compiled it yourself and did not specify --disable-pluto.

That is really strange. Could you please have a look at your config.log 
inside the build directory. Search for USE_PLUTO_FALSE and 
USE_PLUTO_TRUE. Does it read as follows?

USE_PLUTO_FALSE='#'
USE_PLUTO_TRUE=''

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

Re: [strongSwan] [strongswan]ikev2 with plutostart=yes

[Daniel Mentz]

ashish mahalka wrote:
> I might further add here that host1 has only ipv4 support whereas host2 
> has both ipv4 and ipv6 support. I am not sure whether this information 
> does matter in the creation of the sockets for charon.

I remember that there was some kind of problem related to ipv4 and ipv6 
support. Have a look at

https://lists.strongswan.org/pipermail/users/2008-November/002925.html

and check if this is related to your problem.

Also please run

netstat --raw -a -p

and

netstat --ip -a -p -n | grep -E ":4?500"

and post the output. The first command should list charon in the 
"Program name" column.

Thanks
-Daniel

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

Re: [strongSwan] [strongswan]ikev2 with plutostart=yes

[Daniel Mentz]

Hi Ashish,

I examined the log files. Here's what I think happens:

host2 (10.10.10.5) initiates a connection to host1 (10.10.10.2).
host1 sends a packet back to host2 in response.
For some reason, this response packet does not reach charon on host2.

What you are saying is that the problem does not occur if pluto is 
disabled on host2.

The following line in host2-charon.log caught my attention

waiting for data on sockets

Because you are using pluto and charon at the same time, charon should 
use a raw socket instead of UDP socket. So it should say

waiting for data on raw sockets

If charon uses a UDP socket, and it appears to do so, it competes with 
pluto for UDP packets. That's why it works ok if pluto is not running.

Did you compile strongSwan by yourself or did you use some pre-compiled 
package? Did you specify

--disable-pluto

on the command line when running ./configure ?

Use the following command to find out whether you compiled charon for 
raw sockets.

strings /usr/lib/ipsec/charon  | grep "waiting for data on raw socket"

Does it give you some output?

-Daniel



ashish mahalka wrote:
> Hi Daniel and Andreas,
>  
> Here are the fresh logs for both the peers. tcpdump log is also there.
>  
> r...@ipsec01-axc ~]# tcpdump -npi eth1 udp port 500
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> 12:19:15.238009 IP 10.10.10.5.isakmp > 10.10.10.2.isakmp: isakmp: phase 
> 1 I #34[]
> 12:19:15.371786 IP 10.10.10.2.isakmp > 10.10.10.5.isakmp: isakmp: phase 
> 1 R #34[]
> 12:19:19.239717 IP 10.10.10.5.isakmp > 10.10.10.2.isakmp: isakmp: phase 
> 1 I #34[]
> 12:19:19.246910 IP 10.10.10.2.isakmp > 10.10.10.5.isakmp: isakmp: phase 
> 1 R #34[]
> 12:19:26.442665 IP 10.10.10.5.isakmp > 10.10.10.2.isakmp: isakmp: phase 
> 1 I #34[]
> 12:19:26.449747 IP 10.10.10.2.isakmp > 10.10.10.5.isakmp: isakmp: phase 
> 1 R #34[]
>  
> 6 packets captured
> 6 packets received by filter
> 0 packets dropped by kernel
> 
>  
> config setup
>   strictcrlpolicy=no
>   nat_traversal=no
>   plutostart=yes
>   plutodebug=none
>   charonstart=yes
>   charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, 
> lib 2"
>  
> conn conn1
>type=tunnel
>leftsubnet=10.10.10.0/24 <http://10.10.10.0/24>
>rightsubnet=10.10.10.0/24 <http://10.10.10.0/24>
>auto=start
>left=10.10.10.5
>right=10.10.10.2
>leftsendcert=never
>rightsendcert=never
>leftcert=BTS_CERT_FILE.pem
>rightcert=BTS_CERT_FILE.pem
>rightid=%any
>keyexchange=ikev2
>ike=aes128-sha1-modp1024!
>pfs=no
>ikelifetime=86400s
>esp=aes128-sha1!
>authby=pubkey
>keylife=300s
>keyingtries=%forever
>dpdaction=restart
>mobike=no
>dpddelay=10
>    dpdtimeout=125
>rekeyfuzz=50%
>rekeymargin=180s
> 
> When i set plutostart=no, i am able to establish ikev2.
>  
> Please let me know your comments.
>  
> Thanks in advance!
>  
> regards,
> Ashish.
> On 1/7/10, *Daniel Mentz*  <mailto:danielml%2bmailinglists.strongs...@sent.com>> wrote:
> 
> ashish mahalka wrote:
> 
> Strongswan runs at the other end. i m not sure whether the
> packets where reaching the other end or not. But one thing is
> sure, there was no response from strongswan on the other end.
> 
> 
> I'm afraid you have to find out whether the packets make it to the
> other end. Are you familiar with tcpdump?
> 
> tcpdump -npi ppp0 udp port 500 or 4500
> 
> should do the job. Replace ppp0 with the name of the interface you
> want to sniff on. Also, keep an eye on the syslog output of
> strongSwan at the remote end.
> -Daniel
> 
> 

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

Re: [strongSwan] strongswan gateway behind NAT

[Daniel Mentz]

Eldar Yusupov wrote:
> How should I alter the strongSwan config? It seems to me that I've 
> specified that my subnet is 192.168.1.0/24  there.

Try
leftsubnet=0.0.0.0/0

> I'm using Cisco VPN client at the moment, however I plan to change it later.
> In any case I'd like to keep the most of the configuration details 
> defined on the gateway, not the client.

That sounds reasonable.
The concept of Cisco's VPN client is to tunnel all traffic through your 
IPsec gateway not only the traffic that is destined for your subnet i.e. 
192.168.1.0/24. In a default configuration the Cisco VPN client does not 
allow you to access any host on the Internet without passing through the 
VPN gateway.

I'm not an export on Cisco's VPN client, though. Maybe you find a 
solution that fits your needs.

You can also try the VPN client of Shrew Soft.
"NCP Secure Entry Client for Win32/64" is even better but costs 142 EUR 
per license.

> Am I correct that in theory strongSwan should notify the peer about the 
> local subnet, however for some reason this does not happen or the peer 
> discards that information?

That is true for IKEv2. Maybe Cisco has some proprietary extension for 
IKEv1 which supports that as well but I guess not.

-Daniel

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

Re: [strongSwan] strongswan gateway behind NAT

[Daniel Mentz]

Eldar Yusupov wrote:
> In case it is relevant, the VPN client was behind another NAT as well when I
> was testing this scenario.
> "homenet"[1] 192.168.1.1:23495 #1: cannot respond to IPsec SA request
> because no connection is known for 0.0.0.0/0===192.168.1.38:4500[C=RU,
> O=dmachine, CN=dmachine]...192.168.1.1:23495[C=RU, CN=eyusupov]===
> 192.168.2.165/32
> 
> Below is my ipsec.conf:

>   leftsubnet=192.168.1.0/24

It looks like your traffic selectors do not match up.

The peer states that your local subnet is 0.0.0.0/0 (see log file) 
whereas you configured the local subnet to be 192.168.1.0/24 (see 
leftsubnet= in ipsec.conf).

Alter the config of strongSwan or the configuration of the peer, 
whatever is appropriate for your setup.

That is a shortcoming of IKEv1. IKEv2 is able to negotiate the traffic 
selectors.

What VPN client are you using?

Hope that helps
-Daniel

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

Re: [strongSwan] Dead Peer Detection

[Daniel Mentz]

vivek bairathi wrote:
> 1. When does ikev2 stack start sending dpd's?
> 2. When does it know that its time to close the IPSEC SA or IKE SA?

Hi Vivek,

did you read the definitions of the dpdaction and the dpddelay parameters on

http://wiki.strongswan.org/wiki/strongswan/ConnSection

? It gives some pretty good information. Please get back to us if this 
page does not answer your questions.

> 3. Can you tell me where is the handling for closing the IPSEC SA or
> IKE SA in case of no response to the dpd's?

Are talking about source code?

-Daniel

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

Re: [strongSwan] Establish connection with DynDNS peer

[Daniel Mentz]

Peter Daum wrote:
> B is a Bintec VPN25 router with a dynamic address published via DynDNS.

> A tries to bring the tunnel up. However, A fails since it tries to connect to 
> the OLD IP address. A ping from A to B shows that name resolution works 
> perfectly. So A seems to cache the old IP address within strongSwan and does 
> not update it.

> Why does strongSwan not recognize the new address? The only thing which helps 
> is a ipsec update. This is not feasible as I would have to have a script in 
> place monitoring the connections, recognizing the tunnel went down and 
> issuing a ipsec update (albeit not too early). 

Hi Peter,

there's this tool called starter. It reads the config file, resolves the 
DNS name into an IP address and provides the connection definition 
including the IP address to pluto.
pluto is the IKEv1 daemon. IMHO, it only deals with IP addresses. It 
does neither store nor resolve the DNS name of the peer. Only if you run 
"ipsec update", the tool starter kicks in again, performs a fresh DNS 
lookup and provides the altered connection definition to pluto.

I can think of three different solutions:

1. Tweak pluto so that it saves FQDNs instead of IP addresses and 
performs a new DNS lookup after it declared its peer dead. This would 
result in a rather large modification of pluto.

2. Configure strongSwan to respond to setup requests but not to initiate 
connections. Can you configure the Bintec router in a way that it 
re-initiates the IPsec connection everytime it reboots? Does it support 
DPD? The Bintec router should basically keep the connection permanently 
open.

3. Follow Gerd's recommendation and make use of "ipsec starter 
--auto-update ". But I personally don't like this solution 
because it hammers the DNS server. Plus the update of the IP address 
might be delayed for up to .

Btw, can you recommend Bintec's VPN25 router? Does it support NAT-T (NAT 
traversal), DPD and certificate based authentication? I recently 
evaluated a Netgear FVS318 v3 and I got disappointed. It does not 
support NAT-T. The support for X.509 certificates is bad (you cannot 
import private keys) plus the whole firmware crashes when I try to 
connect to strongSwan.

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

Re: [strongSwan] Multiple CA Cert support in ipsec.conf

[Daniel Mentz]

vivek bairathi wrote:
> Actually my problem is I can't specify the directory. I don't want the 
> files for cacert to be picked from /etc/ipsec.d/cacerts/. I can only 
> specify filename as many other files are going to be there in that 
> directory, so for that I need the entry in ipsec.conf in the way I have 
> written.

Try defining a ca section for each CA certificate:

http://wiki.strongswan.org/wiki/strongswan/CaSection

This does not require you to store the certificates in 
/etc/ipsec.d/cacerts/. You can store them in other locations.
Is that an option for you?

> ca Plane
>cacert=/home/vivek/RootCert1.pem,/home/vivek/RootCert2.pem
>crluri=/home/vivek/crl.pem
>auto=add
> Is this not possible?

I guess you can specify only a single file as cacert.

> Is there no way to mention file names for all ca certs in ipsec.conf ?

I guess not.

> Is it possible to change the code to made this thing possible?

Sure. You can always change the code. Using --sysconfdir= when running 
./configure might be an option. But then strongSwan also looks for 
ipsec.conf in a different directory.

-Daniel

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

Re: [strongSwan] Multiple CA Cert support in ipsec.conf

[Daniel Mentz]

vivek bairathi wrote:
> If I have two ca certicficates then should I write the name of the file
> of cacertificates like the following way:
> 
> ca Plane
> cacert=/home/vivek/RootCert1.pem,/home/vivek/RootCert2.pem
> crluri=/home/vivek/crl.pem
> auto=add

You can store both ca certificates in

/etc/ipsec.d/cacerts/

and remove cacert= from the connection definition.
As a result, the two CAs will be accepted for other connections as well 
plus all other CAs in this directory are eligible for the connection in 
question.

You can use a ca section inside ipsec.conf to specify the CRL URI:

http://wiki.strongswan.org/wiki/strongswan/CaSection

Is that an option for you?

-Daniel

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

Re: [strongSwan] [strongswan]ikev2 with plutostart=yes

[Daniel Mentz]

ashish mahalka wrote:
> Strongswan runs at the other end. i m not sure whether the packets where 
> reaching the other end or not. But one thing is sure, there was no 
> response from strongswan on the other end.

I'm afraid you have to find out whether the packets make it to the other 
end. Are you familiar with tcpdump?

tcpdump -npi ppp0 udp port 500 or 4500

should do the job. Replace ppp0 with the name of the interface you want 
to sniff on. Also, keep an eye on the syslog output of strongSwan at the 
remote end.
-Daniel

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

Re: [strongSwan] Try to use Cisco VPN client

[Daniel Mentz]

The following log messages is most relevant:

"cisco"[5] 218.240.6.69:56413 #5: next payload type of ISAKMP Hash 
Payload has an unknown value: 197

I can't tell why the Cisco VPN client sends this type of payload. 197 is 
vendor specific. Only the strongSwan developers can help in that 
situation. What version of Ciscos VPN client are you using?
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] [strongswan]ikev2 with plutostart=yes

[Daniel Mentz]

ashish mahalka wrote:
> One more thing I wanted to ask : if I don't know the DN of the peer 
> certificate, can i mention my rightid as %any (as I have done here)

I guess the trick is not to include rightid= at all.

In the log file you provided I can see charon retransmitting the initial 
message again and again. What software runs the remote end? Also 
strongSwan? Did you use tcpdump to do some troubleshooting? Are the 
packets reaching the peer?
-Daniel

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

Re: [strongSwan] Try to use Cisco VPN client

[Daniel Mentz]

Kalaj wrote:
> "cisco"[2] 218.240.6.69:49983 #2: peer requested 2147483 seconds which
> exceeds our limit 86400 seconds
> "cisco"[2] 218.240.6.69:49983 #2: lifetime reduced to 86400 seconds
> (todo: IPSEC_RESPONDER_LIFETIME notification)

Please provide more debug output. I guess further syslog messages follow 
the ones you sent. Did you set up user/password pairs in /etc/ipsec.secrets?
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Try to use Cisco VPN client

[Daniel Mentz]

> "cisco"[3] 218.240.6.69:56131 #3: policy does not allow XAUTHInitRSA
> authentication.  Attribute OAKLEY_AUTHENTICATION_METHOD

Not sure if that helps, but have a look at:

http://www.strongswan.org/docs/readme4.htm#section_14.6

Try adding

authby=xauthrsasig
xauth=server

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

Re: [strongSwan] Try to use Cisco VPN client

[Daniel Mentz]

Kalaj wrote:
> conn %default
> ikelifetime=60m
> keylife=20m
> keyexchange=ikev2
> rekeymargin=3m
> keyingtries=1
> left=167.22.15.11
> leftnexthop=167.22.15.1
> leftcert=no2.crt
> left...@test
> leftsourceip=10.3.0.1
> leftsubnet=0.0.0.0/0
> right=%any
> rightsourceip=10.3.0.2
> rightsubnet=10.3.0.0/24
> auto=start

You set up a some default parameters for connection definitions. But you 
still have to define at least a single connection.

The "conn %default" clause specifies defaults parameters that will be 
used if an individual connection definition does not specify other 
values. But you failed to provide a single connection definition.

Please post your new ipsec.conf plus the output of "ipsec statusall".

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

Re: [strongSwan] Try to use Cisco VPN client

[Daniel Mentz]

Kalaj wrote:
> just want to use Cisco VPN client to connect Strongswan but failed.
> Used x509 authentication and enable --cisco-quirks , maybe I made a
> wrong certs or wrong conf,
> can you guys give me some advices? Thanks.

Please provide more details that enable troubleshooting: log files and 
the exact error message you get from Ciscos VPN client.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] NAT problem

[Daniel Mentz]

Hi Jessie,

I think you have to distinguish between transport mode and tunnel mode.

In tunnel mode, the UDP-encapsulated ESP packet contains a complete IP 
packet. The outer IP header as well as the UDP header are simply 
discarded in that case. The IP packet which is carried by ESP has its 
own IP header.

Not sure about transport mode, though. I remember Andreas saying that 
transport mode is insecure if used together with NAT traversal. I guess 
the receiving end can reconstruct the original IP header by querying the 
Security Policy Database.

Did you check

http://unixwiz.net/techtips/iguide-ipsec.html

? It has some good information on ESP and AH.

-Daniel

Jessie Liu wrote:
> Hi  Andreas ,
>   When the UDP-encapsulated ESP traffic goes through NAT device and 
> reaches the destination end, what will the destination endpoint do to the 
> received packets?
> Following is my understanding, please correct me if there is anything wrong, 
> thanks.
>  
> The destination end will first check the outer IP header and then take off 
> the UDP header, (of course the destination end has to support NAT-Traversal) 
> and modify the outer IP header to the original IPsec outer IP header? After 
> this, the ESP packet could be processed as usual.
> Is my understanding correct?
> If this is true, how the destination end reconstructs the outer IP header? 
> Could you provide an example?
>  
> Thanks ! ^__^

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

Re: [strongSwan] Regarding CN as left/rightid

[Daniel Mentz]

vivek bairathi wrote:
> Some doubts regarding CERT mode:-
> 1. Is it necessary to know the CN of peer before establishing an IKE SA?

Generally speaking, no. It depends on your individual configuration. You 
can setup strongSwan in a way that it accepts an arbitrary DN. Wildcard 
matching is also provided.

This is probably true if strongSwan is responding to a request to set up 
an IKE SA. I'm not sure what the rules are when strongSwan initiates a 
connection.

> 2. Is the left/rightid is always equal to the CN from the certificate?

If leftid/rightid is a DN it must be equal to the DN in the certificate. 
If it is a FQDN, then this FQDN must be contained in the certificate as 
a subjectAlternativeName. Not sure about e-mail addresses and IP 
addresses, though.

-Daniel

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

Re: [strongSwan] [strongswan]ikev2 with plutostart=yes

[Daniel Mentz]

ashish mahalka wrote:
> Basically the requirement is like there are two conn sections in ipsec.conf.
> One conn uses IKEv1 and the other uses IKEv2.
> Is it possible for the host strongswan to have IKEv1 and IKEv2 SA
> simultaneously with other strongswan peers ?

Yes, that is indeed possible.
Please provide more information like the output of charon. You're just 
saying "I cannot establish IKEv2.". That is not enough information to 
help you.
-Daniel

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

Re: [strongSwan] DNS resolution - revisisted

[Daniel Mentz]

Martin Willi wrote:
>> Could you please comment on this. How can I pass FQDNs to charon?
> 
> This is indeed currently not possible via starter. It works fine with
> other plugins (such as the network-manager plugin). But it would require
> some tweaks to explicitly not resolve hosts for connections passed to
> charon.

Hi Martin,

thanks for pointing this out. Are there any plans to change that? Having 
a configuration interface that leverages the full potential of charon 
would be nice. The network-manager plugin, I guess,  has some 
constraints, too. Plus, it does not serve every purpose.

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

Re: [strongSwan] feature request: Give a hint if --enable-eap-mschapv2 is not set

[Daniel Mentz]

Hello Andreas,

thanks for taking the time to explain your analysis in that detail.

Andreas Steffen wrote:
> - What I can offer towards increased user friendliness is to
>   differentiate between the server error messages:
> - On the EAP client the error message remains
> 
>   carol charon: 14[IKE] server requested EAP_MSCHAPV2 authentication
>   carol charon: 14[IKE] EAP method not supported, sending EAP_NAK

That sounds good to me. You might think I'm fussy but I suggest a small 
change: I would like the message to be

"server requested EAP method %N"

instead of

"server requested %N authentication"

This makes it easier for the not-so-well-informed user to associate this 
message with the next one ("EAP method not supported, sending EAP_NAK"). 
The common term would be "EAP method". The administrator might not know 
that "EAP_MSCHAPV2 authentication" is a an EAP method.

I would  be perfectly happy if the last message was:

DBG1(DBG_IKE, "EAP method %N not supported, sending EAP_NAK", 
eap_type_names, type);

I imagine an administrator searching the web for "EAP method 
EAP_MSCHAPV2 not supported, sending EAP_NAK". The result of this search 
quickly takes him to a posting on the mailing list, telling him to 
--enable-eap-mschapv2 and --enable-md4.

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

Re: [strongSwan] DNS resolution - revisisted

[Daniel Mentz]

Andreas Steffen wrote:
>> |   right=home.example.com
>> # bad addr: right=home.example.com [does not look numeric and name 
>> lookup failed]
> 
> Well, if no default route exists then the host most probably is also
> not able to resolve hostnames via DNS. Did you try if nslookup works
> before starting the IKE negotiation?

Hello Andreas,

the laptop was indeed offline at that time. That's why there's no 
default route.
My plan is to start charon at the time the laptop boots. By the time the 
PPP connection comes up, I call "ipsec up home" from /etc/ppp/ip-up.

I also tried to call "ipsec update" from /etc/ppp/ip-up but that did not 
work out either. There appears to be a race condition. Starter still 
can't resolve the FQDN at that time. If I "sleep 1" first and then call 
"ipsec update", it works ok. But I don't like using "sleep" for that 
purpose.

Getting back to the original problem: I had a look at confread.c: If 
ttoaddr() returns "does not look numeric and name lookup failed", 
confread.c sets the address of the remote end to "%any". To me, it looks 
like that starter never passes FQDNs to charon but only IP addresses.

If I use right=%home.example.com, starter adds the connection but with 
in improper remote address (%any).

Could you please comment on this. How can I pass FQDNs to charon?

>> I'm also confused by the syntax of the stroke command.
>>
>>Add a connection:
>>  stroke add NAME MY_ID OTHER_ID MY_ADDR OTHER_ADDR\
>> MY_NET OTHER_NET MY_NETBITS OTHER_NETBITS
>>  where: ID is any IKEv2 ID
>> ADDR is a IPv4 address
>> NET is a IPv4 subnet in CIDR notation
>>
> We haven't updated the stroke command line connection configuration
> option for years. Thus don't be surprised if nothing more than
> some very basic configurations actually work!

Ok. Thanks for pointing this out.

Best regards
  Daniel

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

Re: [strongSwan] Several TS on a same connection

[Daniel Mentz]

Andreas Schuldei wrote:
> On Mon, Dec 28, 2009 at 11:16 PM, Andreas Schuldei
>  wrote:
>> Daniel, thank you VERY much!
>>
>> when would be a good time to run those commands? are there hooks in
>> strongswan to call a script containing those commands? or are there
>> scripts on the system already where i can add these commands?
> 
> i was able to solve this with a new script in /etc/network/if-up.d

You can also use a script like in /etc/init.d/myfirewall

Please refer to

5.14.3.2 Manual init.d configuration

in

http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-firewall-setup
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] feature request: Give a hint if --enable-eap-mschapv2 is not set

[Daniel Mentz]

I tried to setup a strongSwan as a gateway for Windows 7 (MSCHAPv2). But 
it did not work. After some time of troubleshooting, it turned out that 
I failed to include the following parameters when running ./configure

--enable-eap-mschapv2
--enable-md4

The log file of strongSwan wasn't very helpful while troubleshooting. My 
request is to improve on that. Example: If I include the following line 
in ipsec.conf

leftauth=eap-mschapv2

and eap-mschapv2 is not compiled in, it should tell me something like 
"Hey dude, you're trying to use MSCHAPv2 but it's not compiled in. Check 
the installation instructions and recompile"

Also, I think the autoconf script should complain if I enable 
eap-mschapv2 but not md4 at the same time.

Should we add this hint also to the wiki page? I think we should.

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

[strongSwan] DNS resolution - revisisted

[Daniel Mentz]

Andreas Steffen wrote in his e-mail on dec 24:

".the IKEv2 charon daemon receives the FQDN as a
string via the stroke interface and does name resolution on the fly
shortly before actually negotiating the IPsec tunnel."

This appears not to work for me. The output of starter is as follows:

Starting strongSwan 4.3.5 IPsec [starter]...
no default route - cannot cope with %defaultroute!!!
| Loading config setup
|   charonstart=yes
|   plutostart=no
| Loading conn 'home'
|   keyexchange=ikev2
|   left=%any
|   leftsourceip=%modeconfig
|   leftcert=danielCA_daniel-notebook.pem
|   leftfirewall=yes
|   right=home.example.com
# bad addr: right=home.example.com [does not look numeric and name 
lookup failed]
|   rightid=/CN=Vaterstetten/
|   rightsubnet=192.168.10.0/24
|   dpdaction=restart
|   auto=add

Please note that home.example.com is not the real DNS name. I replaced 
the real one for security reasons.

I'm also confused by the syntax of the stroke command.

   Add a connection:
 stroke add NAME MY_ID OTHER_ID MY_ADDR OTHER_ADDR\
MY_NET OTHER_NET MY_NETBITS OTHER_NETBITS
 where: ID is any IKEv2 ID
ADDR is a IPv4 address
NET is a IPv4 subnet in CIDR notation

It clearly states that it requires an IPv4 address no FQDN.

Could you please help me with that.

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

Re: [strongSwan] StrongSwan 4.2.4 with Windows 7

[Daniel Mentz]

Generally speaking, I would try to use the most up-to-date version of 
strongSwan just to rule out that a bug that is already fixed causes the 
problem.
You could configure the source code with s.th. like

./configure --prefix=/home/michael/strongswan_playground/

If you run "make install" afterwards, it copies the files into this 
dedicated directory instead of overwriting the existing version of 
strongSwan.

What's the CA of the certificate you installed on the Windows 7 box? Did 
you store that in /etc/ipsec.d/cacerts. Please run

ipsec listcacerts

and provide the output to us. Also, a more comprehensive log file would 
be helpful.

-Daniel

Wihsböck Michael wrote:
> Hi,
> 
> I'm using StrongSwan 4.2.4 (default in Debian 5.0) and tried to enable it to 
> accept Windows 7 IPSec-VPN connections as desribed on 
> http://wiki.strongswan.org/wiki/1/Windows7. I got it working that the 
> certificates are accepted correctly on windows 7 side but now the connection 
> establishment times out.
> The only message I receive on the StrongSwan system is "Dec 28 18:06:39 
> debian charon: 09[AUD] 188.23.82.145 is initiating an IKE_SA". In the Windows 
> 7 Connection Status and Log Information Page 
> (http://wiki.strongswan.org/wiki/strongswan/Win7Status) this message is 
> immediately followed by something like "sending cert request for "C=AT, ..." 
> but this message doesn't appear :(
> 
> My ipsec.conf:
> 
> config setup
> plutostart=no
> 
> conn windows7
> left=%defaultroute
> leftcert=server3Cert.pem
> leftsubnet=192.168.21.0/24
> right=%any
> rightsourceip=192.168.1.0/24
> rightid="C=AT, ST=Wien, O=Company, OU=Department, CN=support, 
> e=em...@test.tld"
> keyexchange=ikev2
> auto=add
> 
> Is the used strongSwan version too old?

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

Re: [strongSwan] Several TS on a same connection

[Daniel Mentz]

Hi Andreas Schuldei,

Andreas Schuldei wrote:
> On Sat, Dec 26, 2009 at 5:11 PM, Daniel Mentz
>  wrote:
>> Hi Andreas Schuldei,
>>
>> I guess that IKE traffic on port 500 is never protected by ESP because it
>> has its own protection which is the IKE SA. So don't worry about IKE
>> traffic.
> 
> i didnt talk about protection but rather distortion that you get when
> the ipsec connection is somehow confused and traffic cant pass through
> it properly. is the port 500  exempted from going through the ipsec
> connection? then i am happy and wont worry about traffic interruptions
> that become longer then necessary. it would certainly make sense to
> special-case port 500.

IKE traffic which runs on port 500 and 4500 is excluded from IPsec 
processing. Therefore, this kind of traffic will not be wrapped inside 
ESP packets. I do not know how this works, though. Either the kernel is 
clever enough to exclude it or strongSwan uses some special socket.

> 
>> Regarding ssh I do understand the problem. What you might want to try out is
>> a passthrough setup like the one described on
>>
>> http://www.strongswan.org/uml/testresults43/ikev1/passthrough/
>>
>> Try setting up a passthrough connection with a proto/port specification.
>> Maybe the kernel selects the most specific policy for ssh traffic which is
>> the passthrough policy.
> 
> then i would need one additional connection definition for each
> host-host pair? that would double the size of my configuration files
> from very large to very very large (in case of my full mash of hosts).
> cant that be done more elegantly?

Very interesting topic. A spent a few hours doing research on that. I 
kind of solved your problem by using the following commands to add 
entries to the Security Policy Database (SPD):


ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir in 
priority 100
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir 
fwd priority 100
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir 
out priority 100

ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir in 
priority 100
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir 
fwd priority 100
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir 
out priority 100


Please note, that the priority value is actually a bit confusing. 
Policies with lower priority values have higher priority. So "priority 
100" wins over "priority 200".

I also tried to use strongSwan's passthrough policy but this did not 
work out because strongswan assigned the corresponding policies a higher 
priority value which in effect means that they have lower priority.

@strongSwan team: How can I control the priority values of the policies?

If you run the commands above, all SSH traffic should be excluded from 
IPsec processing as long as there are no other policies with lower 
priority values.

-Daniel

> 
>> Personally, I usually depend on a third host that I can use for
>> troubleshooting. If the IPsec connection between A and B fails, then I can
>> ssh to C and from there login into B.
> 
> i have third hosts, too.
> 
>> Does that help?
>>
>> -Daniel
>>
>> Andreas Schuldei wrote:
>>> hi Andreas!
>>>
>>> (thanks to this thread i just discovered traffic selectors, reading
>>> this mailing list DOES help! :-)
>>>
>>> what i would like to do is to NOT send ssh (port 22) and ike2 traffic
>>> (port 500) via ipsec. that is because back in 2000 when i worked with
>>> ipsec i discovered that if the encrypted connection hang for some
>>> reason i would be unable to reach the other side via ssh (and fix the
>>> remote problem) and the connection could not be renegotiated quickly
>>> becaus even the key exchange could not be done because the connection
>>> which was responsible for renegotiation was unavailable.
>>>
>>> for that reason i would like to exclude those two ports from
>>> ipsec-transportation. but the syntax for transport selectors does not
>>> provide for a "dont add THIS port to ipsec", does it?
>>>
>>> apart from this: do you people observe the described failiour modes in
>>> real life? perhaps these issues went away in the mean time.
>>>
>>> /andreas
>>>
>>>
>>> On Sat, Dec 26, 2009 at 2:48 PM, Andreas Steffen
>>>  wrote:
>>>> Hello Mugur,
>>>>
>>>> it does not matter if you define each tunnel between two
>>>> peers independently or if you use conn %default or an also=
>>>> construct to save typing work. All tunnels,

Re: [strongSwan] Several TS on a same connection

[Daniel Mentz]

Hi Andreas Schuldei,

I guess that IKE traffic on port 500 is never protected by ESP because 
it has its own protection which is the IKE SA. So don't worry about IKE 
traffic.

Regarding ssh I do understand the problem. What you might want to try 
out is a passthrough setup like the one described on

http://www.strongswan.org/uml/testresults43/ikev1/passthrough/

Try setting up a passthrough connection with a proto/port specification. 
Maybe the kernel selects the most specific policy for ssh traffic which 
is the passthrough policy.

Personally, I usually depend on a third host that I can use for 
troubleshooting. If the IPsec connection between A and B fails, then I 
can ssh to C and from there login into B.

Does that help?

-Daniel

Andreas Schuldei wrote:
> hi Andreas!
> 
> (thanks to this thread i just discovered traffic selectors, reading
> this mailing list DOES help! :-)
> 
> what i would like to do is to NOT send ssh (port 22) and ike2 traffic
> (port 500) via ipsec. that is because back in 2000 when i worked with
> ipsec i discovered that if the encrypted connection hang for some
> reason i would be unable to reach the other side via ssh (and fix the
> remote problem) and the connection could not be renegotiated quickly
> becaus even the key exchange could not be done because the connection
> which was responsible for renegotiation was unavailable.
> 
> for that reason i would like to exclude those two ports from
> ipsec-transportation. but the syntax for transport selectors does not
> provide for a "dont add THIS port to ipsec", does it?
> 
> apart from this: do you people observe the described failiour modes in
> real life? perhaps these issues went away in the mean time.
> 
> /andreas
> 
> 
> On Sat, Dec 26, 2009 at 2:48 PM, Andreas Steffen
>  wrote:
>> Hello Mugur,
>>
>> it does not matter if you define each tunnel between two
>> peers independently or if you use conn %default or an also=
>> construct to save typing work. All tunnels, i.e. a definition
>> of traffic selectors are grouped under the same IKE_SA
>> which is going to be established between the two peers.
>>
>> The IKEv2 charon daemon allows the enumeration of several
>> traffic selectors for the same CHILD_SA using left|rightsubnet:
>>
>>  leftsubnet=10.1.0.0/16,10.3.0.0/16
>>  rightsubnet=10.2.0.0/16,10.4.0.0/16
>>
>> will establish the following four IPsec SAs with a single CHILD_SA:
>>
>>  10.1.0.0/16 - 10.2.0.0/16
>>  10.1.0.0/16 - 10.4.0.0/16
>>  10.3.0.0/16 - 10.2.0.0/16
>>  10.3.0.0/16 - 10.4.0.0/16
>>
>> Currently traffic selectors with protocol/port restrictions
>> using the left|rightprotoport parameters cannot be
>> grouped together in a single CHILD_SA. You will have to define
>> a separate conn description for each protocol/port combination
>> resulting in a separate CHILD_SA exchange. Thus the example
>>
>> conn net-net
>> also=host-host
>> leftsubnet=10.1.0.0/16,10.3.0.0/16
>> rightsubnet=10.2.0.0/16,10.4.0.0/16
>> auto=start
>>
>> conn proto1
>> also=host-host
>> leftsubnet=10.5.0.0/16
>> rightsubnet=10.5.0.0/16
>> leftprotoport=tcp
>> rightprotoport=tcp/http
>> auto=start
>>
>> conn proto2
>> also=host-host
>> leftsubnet=10.5.0.0/16
>> rightsubnet=10.5.0.0/16
>> leftprotoport=tcp
>> rightprotoport=tcp/smtp
>> auto=start
>>
>> conn host-host
>> left=
>> right=
>>
>> would create six IPsec SAs between left and right, using a primary
>> IKE_AUTH and two additional CHILD_SA exchanges.
>>
>> Best regards
>>
>> Andreas
>>
>> ABULIUS, MUGUR (MUGUR) wrote:
>>> Hello,
>>>
>>> I looked to strongSwan connection parameters
>>> (http://wiki.strongswan.org/wiki/1/ConnSection) and I am not sure how
>>> to define several tunnels between the same endpoints, each tunnel
>>> with several traffic selectors.
>>>
>>> In my understanding an independent tunnel is defined by a "conn
>>> " directive with the condition that its body does not contain
>>> an "also = " directive.
>>>
>>> Now, I want, for each tunnel to include several traffic selectors;
>>> i.e. several "left|rightprotoport = /" and several
>>> "left|rightsubnet = ".
>>>
>>> Moreover I want to combine traffic selectors in a specific way for a
>>> same connection. For example to specify somehow
>>>
>>> leftprotoport=icmp ONLY for leftsubnet= 192.168.10.0/24 and
>>> leftprotoport=UDP ONLY for leftsubnet= 172.16.10.0/24
>>>
>>> Can you please specify which are all possibilities of using the IKEv2
>>> extended traffic selector concept with strongSwan.
>>>
>>> Thank you Mugur
>> ==
>> Andreas Steffen andreas.stef...@strongswan.org
>> strongSwan - the Linux VPN Solution!www.strongswan.org
>>
>> Institute for Internet Technologies and Applications
>> University of Applied Sciences Rapperswil
>> CH-8640 Rapperswil (Switzerland)
>> ===[ITA-HSR]==
>>
>>

Re: [strongSwan] with ipsec in place, how to replace ssh?

[Daniel Mentz]

Andreas Schuldei wrote:
> hi!
> 
> now that i have ipsec in place, how do i replace ssh? i would like to
> avoid double encryption, in order to not create extra work.

Hi Andreas,

I recommend not to replace ssh even in the presence of IPsec. Accept the 
fact that traffic is encrypted and authenticated twice. I think the 
impact on performance is negligible.

The advantage is that you only have to maintain a single daemon on the 
server side. You don't need to take care of another server daemon for rsh.

It's also more comfortable from a user perspective. The rule of thumb 
is: "Remote access == ssh". The user does not need to decide between ssh 
and rsh which would require him to be aware of the underlying network 
infrastructure.

> 
> how well do rsh, rcp and friend perform? i see there is a package
> rsh-redone-server (and client) in debian, working over inetd. does
> anyone use those? did someone come up with a useful set of iptable
> rules in order to allow the use of the respective ports only when
> coming from esp (or whatever good criteria there might be)?

Can you read German? If yes, check out

http://www.linux-magazin.de/heft_abo/ausgaben/2006/08/doppelnase

If not, then search for "ipsec policy match". The man page of iptables 
also provides some pieces of information. Type in "man iptables" and 
search for "This modules matches the policy used by IPsec for handling a 
packet."

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

Re: [strongSwan] just-in-time initiation of SAs?

[Daniel Mentz]

Hello Andreas Steffen,

this is an interesting topic. I'm wondering whether people should be 
advised to add

dpdaction=hold

to their ipsec.conf.
I tried to setup a configuration that is similar to Andreas Schuldei's. 
The thing that was special about my setup is that it uses an ADSL dialup 
connection that disconnects every 24 hours. As a result, the ppp0 
interface disappears and reappears shortly after.

The problem I experienced was that the tunnel did not survive this short 
outage and strongSwan failed the connection. What made me worry is that 
strongSwan deleted the IPsec policy completely. The consequence was that 
traffic was sent unprotected i.e. unencrypted!

If I set auto=route, I expect strongSwan to setup the IPsec policy and 
refrain from deleting it *in any event*.

Please correct me when I'm wrong.

-Daniel


Andreas Steffen wrote:
> Hello Andreas,
> 
> set up all the connections with
> 
>   auto=route
> 
> which will install only the corresponding IPsec policies in the
> Linux kernel. As soon as the first packet wants to leave a host
> in direction to another host for which a secure connection is
> defined, the matching IPsec policy will trigger the IKE daemon
> and cause it to negotiate the IPsec tunnel just in time.
> 
> Best regards
> 
> Andreas
> 
> Andreas Schuldei wrote:
>> hi!
>>
>> i would like to inititate my SAa "just in time", meaning that they
>> should only set up the secure connection when there is real traffic,
>> not ahead of time.
>>
>> background to that is that i want to do a full mash of host-to-host
>> transports, both within one site in order to get rid of firewalls per
>> site,  and between sites, to avoid setting up tunnels between sites.
>>
>> not every host will talk to every other host all the time, but they
>> might need to talk to any given host within the whole setup sooner or
>> later. in order to not having to initiate a connection to every other
>> host at ipsec startup i would like to configure strongswan in a way
>> that it would only set up the secure host-to-host transport when its
>> needed. otherwise i might be DoSing myself when a whole site gets cut
>> off from the net and then later comes back again and a few hundret
>> servers initiate connections to the rest of the network all at once.
>>
>> how can i solve that?
>>
>> /andreas
> 

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

Re: [strongSwan] Help writing a Debian howto : adding to NetworkManager examples to IKEv2Examples

[Daniel Mentz]

Dear Jean-Michel,

I'm glad that you take on the challenge and write a guide for beginners. 
I guess that a lot of users will be grateful for your documentation. 
Maybe you can continue the work of Ralf Spenneberg and update his IPsec 
Howto at

http://www.ipsec-howto.org/

What about the note at the bottom of

http://wiki.strongswan.org/wiki/strongswan/NetworkManager

"Depending on the used authentication methods, you can use gateway 
configurations very similar to Windows 7 (Certificate/MSCHAPv2), or use 
EAP-GTC to authenticate against PAM."

Doesn't this help you to setup the server side.

-Daniel

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

Re: [strongSwan] strongswan ipsec pki

[Daniel Mentz]

Jean-Michel Pouré wrote:
> There is no pki after a successful compilation.
> My compilation line was:
> 
>  1 cd strongswan-4.3.5
>   2 make clean
>   3 ./configure --disable-pluto --disable-tools --sysconfdir=/etc
> --prefix=/usr --libexecdir=/usr/lib \

--disable-tools disable additional utilities (openac, scepclient and 
pki). Please retry without this switch.

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

Re: [strongSwan] Help writing a Debian howto : adding to NetworkManager examples to IKEv2Examples

[Daniel Mentz]

Jean-Michel Pouré wrote:
> Would it be possible for you to publish this page:
> http://wiki.strongswan.org/wiki/strongswan/NetworkManager
> 
> In the IKEv2 examples:
> http://wiki.strongswan.org/wiki/strongswan/IKEv2Examples

Hi Jean-Michel,

I'm not quite sure if I got your question right. Could you please 
rephrase it?
The URLs you mentioned are publicly available already. Are you asking 
for permission to redistribute this material? You have to ask the 
respective authors then.
-Daniel

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

Re: [strongSwan] strongswan ipsec pki

[Daniel Mentz]

Jean-Michel Pouré wrote:
> After compiling and installing strongswan 4.3.5, 
> ipsec pki does not work:
> 
> ipsec pki
> /usr/sbin/ipsec: unknown IPsec command `pki' (`ipsec --help' for list)

Hi Jean-Michel,

after compiling strongswan, do you have an executable called "pki" in

strongswan-4.3.5/src/pki

?
This binary should be installed to /usr/lib/ipsec. The exact path may be 
different on your system, though.

-Daniel

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

Re: [strongSwan] Nokia VPN Client & IKEv2

[Daniel Mentz]

Robert Markula wrote:
> If the subjectAltName = DNS:cray.home.ro, this would be "cray.home.ro",
> right?

Yes

> And, one final question: if using the subjectAltName or the Subject DN,
> what kind of "Remote ID type" would that be on the client side?
> "RCF_822_NAME" or "FQDN"?

I guess it's ID_DER_ASN1_DN or just DN if you use the subject DN.
It's ID_FQDN if the type of the subjectAltName is DNS and ID_USER_FQDN 
if the type of the subjectAltName is e-mail address.

Speaking about DNs. I'm not an expert on that topic but it might be 
worth the effort to find out how nokia encodes DNs. There are different 
formats out there. Examples:

/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting 
cc/OU=Certification Services Division/CN=Thawte Premium Server 
CA/emailaddress=premium-ser...@thawte.com

emailaddress=premium-ser...@thawte.com,CN=Thawte Premium Server 
CA,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape 
Town,ST=Western Cape,C=ZA

Those two lines represent the exact same DN. The encoding is just 
different. Also, note that the order of the RDNs i.e. the individual 
components like CN etc. is significant.

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

Re: [strongSwan] unable to route traffic from local to remote subnet after VPN connection establishes

[Daniel Mentz]

Hi Mohit,

that is a very interesting discussion. Thanks for bringing it up. I've 
done some testing. Here's what I'm *guessing* after those tests:

The routing table *does* matter even for packets that are subject to an 
IPsec policy.
The output interface can be any arbitrary interface. But if you enable 
reverse path filtering, you might get into trouble because it drops the 
returning packets. Taking this into account the egress interface should 
be the correct one.
If you add a route of type prohibit with the prefix specified by 
rightsubnet i.e.

ip r a prohibit 192.168.1.0/24

then the gateway indeed blocks the traffic. I regard this as evidence 
that the routing table is consulted even though the packets are subject 
to an IPsec policy.

The reason why the problem you described rarely occurs is probably that 
most systems have default routes that point to the correct interface. I 
guess the same is true for the net2net-psk setup you mentioned. 
Unfortunately, the website

http://www.strongswan.org/uml/testresults43/ikev1/net2net-psk/

does not show all routing tables but only table 220.

I hope that some experts shed some light on this issue.

-Daniel

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

Re: [strongSwan] unable to route traffic from local to remote subnet after VPN connection establishes

[Daniel Mentz]

Btw, does adding

leftsourceip=172.16.117.128

on Box A and

leftsourceip=192.168.74.160

on Box B insert the routes automatically and therefore fix the problem?
-Daniel


Mohit Mehta wrote:
> Hi All,
> 
> I have the following setup -
> 
>   Box ABox B
>   --- ---
>  subnet  |  strongswan   |172.16.139.0/24|   strongswan  |subnet
> (172.16.117.0/24)|4.3.2  |---| 4.3.2 
> |(192.168.74.0/24)
>  .128| Linux 2.6.31  |.128   .160| Linux 2.6.31  |.160
>  eth1 ---  eth0  eth0 eth1
> 
> 
> I can establish ipsec connection between Box A and Box B fine. My problem is 
> that after tunnel establishment, if I ping from a host in 172.16.117.0/24 to 
> a host in 192.168.74.0/24, I get a Destination Unreachable message from Box 
> A. If, however, I add an interface route on Box A to route traffic destined 
> to 192.168.74.0/24 via eth0 then I am able to ping a host in 192.168.74.0/24 
> from a host in 172.16.117.0/24. My question is - Do we need to add this route 
> on Box A to route traffic from leftsubnet to reach rightsubnet? Shouldn't the 
> encapsulation happen by itself when using NETKEY given the policies are 
> defined? The same was explained by Andreas previously on the mailing list - 
> https://lists.strongswan.org/pipermail/users/2008-March/002320.html
> 
> However, if I follow the packet path going through iptables here - 
> http://jengelh.medozas.de/images/nf-packet-flow.svg then I think that if 
> there isn't a routing entry for the remote subnet on Box A then the kernel 
> doesn't know where to route the packet and thus, returns the destination 
> unreachable message to the host in it's local subnet. If that's the case then 
> how are the Strongswan Test Cases passing without any routes being inserted - 
> http://www.strongswan.org/uml/testresults43/ikev1/net2net-psk/
> 
> 
> Can anybody shed some light on this issue?
> 
> 
> Debugging information follows -
> 
> `ip xfrm policy` output on Box A after tunnel establishment -
> 
> r...@vdut-1# ip xfrm policy
> src 172.16.117.0/24 dst 192.168.74.0/24
> dir out priority 2344
> tmpl src 172.16.139.128 dst 172.16.139.160
> proto esp reqid 16385 mode tunnel
> src 192.168.74.0/24 dst 172.16.117.0/24
> dir fwd priority 2344
> tmpl src 172.16.139.160 dst 172.16.139.128
> proto esp reqid 16385 mode tunnel
> src 192.168.74.0/24 dst 172.16.117.0/24
> dir in priority 2344
> tmpl src 172.16.139.160 dst 172.16.139.128
> proto esp reqid 16385 mode tunnel 
> 
> 
> `ip xfrm state` output on Box A after tunnel establishment -
> 
> src 172.16.139.128 dst 172.16.139.160
> proto esp spi 0xaa64261d reqid 16385 mode tunnel
> replay-window 32
> auth hmac(sha1) 0xbae6dddb67fae3436bbc28b72181c213c36b4052
> enc cbc(aes) 0x77b2318226075f7bfd102adefbb1cd0e
> sel src 0.0.0.0/0 dst 0.0.0.0/0
> src 172.16.139.160 dst 172.16.139.128
> proto esp spi 0xbacd4934 reqid 16385 mode tunnel
> replay-window 32
> auth hmac(sha1) 0x4775c1fe7b8253283fc0f7748d46fc639d8d2742
> enc cbc(aes) 0x7152e25878895d59840edf4a695ece76
> sel src 0.0.0.0/0 dst 0.0.0.0/0
> 
> 
> `ipsec status` output -
> 
> 000 "peer-172.16.139.160-tunnel-1": 
> 172.16.117.0/24===172.16.139.128...172.16.139.160===192.168.74.0/24; erouted; 
> eroute owner: #5
> 000 "peer-172.16.139.160-tunnel-1":   newest ISAKMP SA: #1; newest IPsec SA: 
> #5;
> 000
> 000 #5: "peer-172.16.139.160-tunnel-1" STATE_QUICK_I2 (sent QI2, IPsec SA 
> established); EVENT_SA_REPLACE in 1859s; newest IPSEC; eroute owner
> 000 #5: "peer-172.16.139.160-tunnel-1" esp.aa642...@172.16.139.160 (0 bytes) 
> esp.bacd4...@172.16.139.128 (0 bytes); tunnel
> 000 #2: "peer-172.16.139.160-tunnel-1" STATE_MAIN_R3 (sent MR3, ISAKMP SA 
> established); EVENT_SA_REPLACE in 24900s
> 000 #1: "peer-172.16.139.160-tunnel-1" STATE_MAIN_I4 (ISAKMP SA established); 
> EVENT_SA_REPLACE in 24180s; newest ISAKMP
> 
> Connection definition in ipsec.conf on Box A -
> 
> conn peer-172.16.139.160-tunnel-1
> left=172.16.139.128
> right=172.16.139.160
> leftsubnet=172.16.117.0/24
> rightsubnet=192.168.74.0/24
> ike=aes128-sha1!
> ikelifetime=28800s
> esp=aes128-sha1!
> keylife=3600s
> rekeymargin=540s
> type=tunnel
> pfs=yes
> compress=no
> authby=secret
> auto=start
> #conn peer-172.16.139.160-tunnel-1
> 
> 
> Any help on this would be greatly appreciated. Let me know if more 
> information is needed for debugging.
> 
> Thanks,
> Mohit
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] trouble installing the source route

[Daniel Mentz]

jr wrote:
> Dec  1 15:40:20 gate charon: 13[KNL] received netlink error: Network is
> unreachable (101)

> ip route add 192.168.5.0/24 via nexthop dev eth4 table 220 src
> 192.168.99.1

Just a guess:

Maybe strongswan has trouble figuring out the correct value for nexthop 
and network interface.

Please ramp up the debugging level with

charondebug="knl 2"


and have a look at the syslog files. You should see something like

Dec  1 14:47:45 server2 charon: 05[KNL] getting a local address in 
traffic selector 87.230.2.1/32
Dec  1 14:47:45 server2 charon: 05[KNL] using host 87.230.2.1
Dec  1 14:47:45 server2 charon: 05[KNL] getting address to reach 87.139.2.6
Dec  1 14:47:45 server2 charon: 05[KNL] getting interface name for 
87.230.2.1
Dec  1 14:47:45 server2 charon: 05[KNL] 87.230.2.1 is on interface eth0
Dec  1 14:47:45 server2 charon: 05[KNL] getting iface index for eth0

Could you please post the output as well as ipsec.conf.

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

Re: [strongSwan] [solved] IKEv2

[Daniel Mentz]

Hector Akamine wrote:
> to summarize:
> 
>(WAN)(LAN)
> PC2(CF-W8) -  NAT router  PC1(CF-W7)
> 192.168.0.14 192.168.0.21  192.168.1.1192.168.1.11 
> 
> - "ipsec up host-host" must be done from the LAN side (CF-W7), in order to
> create the NAT mapping used for UDP encapsulated IPsec packets. 

Hi Hector,

why not set up a port forwarding rule on the NAT router so that packets 
arriving on the WAN port destined for 192.168.0.21 UDP port 500 or 4500 
are mapped to 192.168.1.11.

> - As an (obvious?) effect, I am able to access CF-W7 from 
> CF-W8 (that is, from WAN to LAN), since NAT keepalives are periodically sent
> from CF-W7 to CF-W8 to "keep alive" the port mapping used by IPsec packets. 
> If I not were using the VPN, I would normally require to set the router for
> accessing a host in the LAN from the WAN.  

That is the reason why you set up a VPN, isn't it? You have a virtual 
private network that connects CF-W8 and CF-W7. So it goes without saying 
that you can access CF-W7 from CF-W8.

> 
>>> VPN passthrough is not needed, IKEv2 will use UDP encapsulation if a NAT
>>> device is detected between your hosts.
>> If I remember correctly I once had trouble with a router that explicitly 
>>  blocked traffic on UDP ports 500 and 4500 if VPN passthrough was disabled.
> 
> I do need to enable VPN passthrough at least in this particular router, 
> if VPN passthrough is disabled, the router blocks UDP traffic and the 
> VPN can't be set up.

Thank you for this information. I put the following on record:

VPN passthrough is counterproductive and does more harm than good.

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

Re: [strongSwan] IKEv2 "TS_UNACCEPTABLE" error when behind a NAT

[Daniel Mentz]

Martin Willi wrote:
>> with "VPN passthrough" option enabled.
> 
> VPN passthrough is not needed, IKEv2 will use UDP encapsulation if a NAT
> device is detected between your hosts.

If I remember correctly I once had trouble with a router that explicitly 
  blocked traffic on UDP ports 500 and 4500 if VPN passthrough was disabled.
I recommend to try both settings: on and off.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] IKEv2 "TS_UNACCEPTABLE" error when behind a NAT

[Daniel Mentz]

Hector Akamine wrote:
>(WAN)(LAN)
> PC2(CF-W8) -  NAT router  PC1(CF-W7)
> 192.168.0.14 192.168.0.21  192.168.1.1192.168.1.11 
> 
> I configured PC1 and PC2 to set up a host-to-host IPsec tunnel using IKEv2,
> CF-W8 log (in /var/log/messages) shows:
> traffic selectors 192.168.0.14/32 === 192.168.1.11/32  inacceptable

Could you please try adding

rightsubnet=192.168.1.11/32

to ipsec.conf on CF-W8.

The problem is IMHO that CF-W7 thinks that it has IP address 
192.168.1.11 whereas in the perception of CF-W8  CF-W7 has the IP 
address 192.168.0.21.

Please get back to use with the result.
-Daniel

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

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

[Daniel Mentz]

Hi Graham,

could you please post the output of

ip xfrm policy


Hi Andreas,

I guess that the problem is a different one.
Graham uses two different source IP addresses depending on whether the 
traffic is destined for the local subnet or any other host on the Internet.

He uses 192.168.50.154 as the source address for local traffic and
1.1.35.49 as the source address for traffic to all other destinations.

So I guess he has to massage the routing table properly so that the 
kernel picks the correct source address for traffic originated from the 
local host. The ipsec policy only affects traffic with this pattern

1.1.35.49/32 <=> 0.0.0.0/0

So if the kernel picks 192.168.50.154 as the source address for local 
traffic then the policy does not match and there's also no need for a 
passthrough policy.

So I guess it's all about setting up the routing table correctly.

Please correct me if I'm wrong.

-Daniel

Andreas Steffen wrote:
> Hello Graham,
> 
> this is a well known problem when all Internet traffic is going to
> be tunnelled via IPsec (rigthsubnet=0.0.0.0/, i.e. no split-tunneling)
> but local traffic should not go through the tunnel.
> 
> The correct way to handle this is to define a passthrough IPsec policy
> for the local network 192.168.50.0/24 thus exempting it from
> IPsec. Since the IKEv2 charon daemon cannot set up passthrough policies
> [yet] I recommend to use the ip xrfrm policy command.
> 
> Best regards
> 
> Andreas
> 
> Graham Hudspith wrote:
>> 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.
> 
> ==
> Andreas Steffen andreas.stef...@strongswan.org
> strongSwan - the Linux VPN Solution!www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===[ITA-HSR]==
> 
> 
> 
> 
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

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

Re: [strongSwan] SA Established, but not working

[Daniel Mentz]

Please send

- the config file ipsec.conf
- the syslog output of charon
- the output of "ip xfrm policy" and "ip xfrm state" as well as "ip 
route show table 0"

This helps troubleshooting your problem.

-Daniel

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

Re: [strongSwan] Issue about the tunnel

[Daniel Mentz]

weiping deng wrote:
> I initiate ping form HNB (192.168.253.88 --- virtual ip) to GW
> (192.168.253.98- additional ip), but from tcpdump, I see:
> 
> Only the packages go through normal tunnel (172.19.2.118 - 172.19.2.247)
> is ESP.
> 
> And 
> 
> The packages go through virtual tunnel (192.168.253.88  192.168.253.98)
> is icmp

Could you please rephrase the problem. Explain what you observed and how 
it differs from what you expect.

Please do not send RAR files but rather .tar.gz files. The two files

ipsec(client).conf
ipsec(gw).conf

were empty when I unpacked the RAR file.

Please execute the following commands on *both* machines and send the 
resulting output.

ip xfrm policy
ip xfrm state
ip route list table 0

Make sure to include the name of the host in the file name so that it is 
easy for us to distinguish those two hosts.

The output of tcpdump might be helpful as well.

-Daniel

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

Re: [strongSwan] When will UNKNOWN -INTEGRITY-ALG occur in IKE_SA_INIT message?

[Daniel Mentz]

I guess that wireshark is not up to date.
Integrity Algorithm no 12 is defined in RFC4868 as

AUTH_HMAC_SHA2_256_128

The RFC was published in May 2007. I guess this Integrity Algorithm is 
unknown to wireshark. That's why it displays "UNKOWN-INTEGRITY-ALG".

What kind of security gateway are you using? Do you have any log files?

Jessie Liu wrote:
> Hi all,
>  I got the problem that client sends IKE_SA_INIT message to security 
> gateway, but security gateway did not respond.
> so i capture the message using ethereal and found that in IKE_SA_INIT 
> message UNKNOWN -INTEGRITY-ALG occured. even if i specify the encryption and 
> integirty algorithm in ipsec.conf by using ike=aes_cbc-hmac_sha1_96, 
> UNKNOWN -INTEGRITY-ALG  still appeared in the IKE_SA_INIT message. And this 
> is the root cause that security gateway did not responed?? 
> and how to remove this? 
>  
> attached please find the ethereal file.

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

Re: [strongSwan] How can I shutdown the NAT-T feture of IKEv2

[Daniel Mentz]

Hi David,

would you mind sharing the name of the other IKEv2 implementation you 
are using. Other users might be able to take advantage of this 
information. It's good to know with which implementations strongSwan 
inter-operates with and what the reasons are if inter operation fails.
-Daniel

weiping deng wrote:
> Because If two peer was placed into a no NAT environment, and one peer used
> strongswan, another peer used another IPsec tool. 
> 
> If strongswan default enable this NAT-T feature, and then the following
> message parsing will be encountered issues due to the "4 bytes of non-ESP"
> and port floating RFC3948.

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

Re: [strongSwan] How can I shutdown the NAT-T feture of IKEv2

[Daniel Mentz]

weiping deng wrote:
> How can I shutdown the NAT-T feature of IKEv2? 

http://wiki.strongswan.org/wiki/strongswan/ConfigSetupSection

says

"NAT traversal is always being active in IKEv2."

So I guess the answer is that you can't turn it off.

Please explain your motivation for turning it off. Do you expect a more 
secure system?

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

Re: [strongSwan] Problem on Virtual IP and SCTP packets

[Daniel Mentz]

Jessie Liu wrote:
> But If I add leftsourceip=%config in ipsec.conf, the SCTP packets will not go 
> through the tunnel, but ping packets will. ...If I remove 
> leftsrouceip=%config from ipsec.conf, the SCTP packets will flow through the 
> tunnel. Could you give me some hints what is happened and what should I 
> check?  I am using kernel version 2.6.28.

Hi Jessie,

what about TCP and UDP traffic? Do those packets stick to the tunnel?
Your problem might be related to SCTP's multi-homing feature where each 
endpoint announces all of its IP addresses to the other peer. This is 
important for fail-over scenarios.
In your case this feature might be counter productive. Both peers try to 
use all available paths that can be used to exchange data. But only one 
path is protected by IPsec. So I guess you need to setup firewall 
policies to block all alternative paths. This way you can force the SCTP 
implementation to use only one (secure) path.

Let's say host A has IP address 1.1.1.10 and 2.2.2.10. Host B has 
1.1.1.20 and 2.2.2.20. If host A initiates a connection to host B it 
sooner or later tries all four different combinations of IP addresses in 
the hope that the traffic flows on different paths if they switch the IP 
addresses.
TCP always sticks to the same pair of IP addresses.

-Daniel

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

Re: [strongSwan] multiple traffic selector of which no local address is known

[Daniel Mentz]

Joep Gommers wrote:
> 10.2.0.0/24 however is not a subnet in which the StrongS/WAN box
> resides. It resides behind yet another VPN appliance. So the routing
> table on the "left" side would include something like:
> 
> to 10.2.0.0/24 via 10.1.0.254 metric 1
> 
> However, StrongS/WAN refuses to create the traffic selector giving me
> the error:
> "no local address found in traffic selector 10.2.0.0/24"

Hi Joep,

I browsed the source code. If I understand it correctly the message you 
quoted is NOT an error message. The reason why strongSwan looks for a 
local address in the traffic selector is that it wants to install a 
route of this kind (if your router had a local IP address of 10.2.0.33):

10.2.0.0/24 dev ppp0  scope link  src 10.2.0.33

But in your case there's no need to install such a route because your 
router is not in that subnet.

What's the output of

ipsec statusall

?
Also, log files of charon would be helpful

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

Re: [strongSwan] Sending eth1 traffic down eth0 tunnel

[Daniel Mentz]

Hi Graham,

I believe Andreas is correct. I just tried this here with my own setup. 
You can't depend on the MASQUERADE target if you want to source nat to 
the gateway's virtual IP address. This is what the man page says about 
MASQUERADE:

"Masquerading is equivalent to specifying a mapping to the IP address of 
the interface the packet is going out"

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



Andreas Steffen wrote:
> Hello Graham,
> 
> 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?
> 
> Regards
> 
> Andreas
> 
> Graham Hudspith wrote:
>> 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 pref

Re: [strongSwan] DHCP/Any Traffic over an established VPN tunnel

[Daniel Mentz]

Hi Carlos,

sorry for the delay.
Here's my suggestion:

Assign a static internal IP address to the VPN router: 172.17.1.2
You can try to set up a DHCP relay agent on the VPN router but I doubt 
that either Linksys or Dlink supports that. Can you use a dedicated 
linux box instead of a hardware appliance?
You could also set up a complete separate DHCP server in the branch 
office but then you have two different DHCP server you have to 
administrate although I don't think that this is too much of an issue.

As I said, I'm not an expert when it comes to DHCP but I doubt that DHCP 
works across a VPN like you imagined it to work. DHCP uses ethernet 
broadcasts which don't go through the IPsec tunnel.
But try setting up a DHCP relay agent. This agent might communicate with 
the main DHCP server over IP.

-Daniel


Carlos Lopez wrote:
> Thanks for your reply Daniel,
> 
> Then as I follow your suggestion I'll try to implement this:
> 
> 1- Build up the Linux Router (Corporate):
> 
> ISP IP= 1.2.3.4
> LAN IP= 172.16.0.1/24
> 
> 2- Buildup DHCP and DNS server with Bind9:
> 
> LAN IP= 172.16.0.2
> IP POOLS corporate LAN= 172.16.0.10 - 172.16.0.254
> IP POOLS ExternalUsers= 172.17.1.3 - 172.17.1.254 (Via VPN)
> 
> 
> 3- Buildup Email server with Qmail or anyother software:
> 
> LAN IP= 172.16.0.3
> 
> 4- Buildup Web server with apache:
> 
> LAN IP = 172.16.0.4
> 
> 5- Buildup the VPN server:
> 
> IP POOL = 172.17.0.2-254 (These are the IPs that Linksys or Dlink device will 
> get after a successful authentication occurs)
> 
> -Install and configure a DHCP relay from ISC.org.
> 
> Then:
> 
> 1- Configure device (Linksy or Dlink or anyother) with:
> 
> ISP IP= 1.2.3.5
> VPN SERVER IP = 1.2.3.4:VPNPORT
> VPN ASSIGNED IP FROM POOL= 172.17.0.2 (If it successful authenticate)
> VPN SERVER KEY/PASS = "abcd"
> NAT-T = ENABLED?
> 
> The question reside on this, how can I do to let users get theirs IPs from 
> the corporate LAN's DHCP server (range 172.17.1.x/24)?. I'd like to do this 
> because It would be ease for me to handle avery IP from branch office, let's 
> say I can assign a group of address to Counter and another group of address 
> to sales and each will have a diffent access and configuration, let's say 
> Counter cannot browse Internet but Sales do. 
> 
> 2- Plugin a 24 port switch to device (linksys or Dlink) and from there the PC 
> stations.
> 
> 3- Try to ping from corporate LAN pc (172.16.0.11) to ExternalUsers 
> (172.17.1.11) and viceversa.
> 
> 4- Do some more traffic, let's say VNC.
> 
> 
> Carlos.
> 
> 
> --- El sáb 10-oct-09, Daniel Mentz 
>  escribió:
> 
>> De: Daniel Mentz 
>> Asunto: Re: [strongSwan] DHCP/Any Traffic over an established VPN tunnel
>> A: "Carlos Lopez" 
>> Cc: users@lists.strongswan.org
>> Fecha: sábado, 10 octubre, 2009, 4:14 pm
>> Hi Carlos,
>>
>> I learned from your e-mail that the subnet your branch
>> office uses is
>>
>> 172.17.0.0/24
>>
>> Why don't you assign the static (internal) IP address
>> 172.17.0.3 to the Linksys / Dlink router and set up a
>> separate DHCP server in that subnet? You could also set up a
>> DHCP Relay agent and use the DHCP server in the head
>> office.
>>
>> I doubt that DHCP works across IPsec tunnels because it
>> uses broadcasts on the ethernet layer.
>>
>> -Daniel
>>
>>
> 
> 
>   
> 
> ¡Obtén la mejor experiencia en la web!
> Descarga gratis el nuevo Internet Explorer 8. 
> http://downloads.yahoo.com/ieak8/?l=e1

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

Re: [strongSwan] Strongswan - Linux Route Interaction Part 2

[Daniel Mentz]

Hi Barry,

I can confirm the behavior of the linux kernel. You need to set up a 
route to 192.168.2.0/24. It's not going to work otherwise. I understand 
that this is confusing. The nexthop determined by the routing table is 
irrelevant because an ESP and another IP header will be put in front of 
the existing IP header. The destination address from this new header 
will be the one that is relevant.

But that's a feature of the Linux kernel and not specific to strongSwan.

I can still think of situations where it makes sense to do a routing 
table lookup first: A route can be of type unreachable, prohibit or 
blackhole. In those cases the kernel should indeed check whether traffic 
may be routed to a given address. Also, you can specify a number of 
options per routing table entry like src address or cwnd (type in "ip 
route help" to get a list). If traffic originates from the local host 
then those options have to be accounted for before a packet is processed 
by IPsec i.e. the security policy database.

-Daniel

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

Re: [strongSwan] DHCP/Any Traffic over an established VPN tunnel

[Daniel Mentz]

Hi Carlos,

I learned from your e-mail that the subnet your branch office uses is

172.17.0.0/24

Why don't you assign the static (internal) IP address 172.17.0.3 to the 
Linksys / Dlink router and set up a separate DHCP server in that subnet? 
You could also set up a DHCP Relay agent and use the DHCP server in the 
head office.

I doubt that DHCP works across IPsec tunnels because it uses broadcasts 
on the ethernet layer.

-Daniel

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

Re: [strongSwan] Internet traffic through VPN

[Daniel Mentz]

Hi Tica,
Hi strongSwan core developers,

I just tried this kind of set up and it worked for me (although the 
setup was a bit tricky).

Could you please provide us with more information regarding your setup. 
Please post the following files:

ipsec.conf

Post the output of the following commands as well:

ip xfrm policy

ip route show table 0

A network diagram would be useful as well.

There's one question I would like to ask people on this list including 
the strongSwan core developers: I'm trying to setup a road warrior to 
pass all traffic (0.0.0.0/0) through the VPN tunnel. Only local traffic 
should be excluded. I'm using

http://www.strongswan.org/uml/testresults43/ikev1/passthrough/

as a basis.
In my setup the virtual IP address of the rw used inside the tunnel is 
different from the physical IP address in the local subnet.

strongSwan inserts routing entries in the table 220.

0.0.0.0/1 via 192.168.10.2 dev eth0  src 10.33.44.1
128.0.0.0/1 via 192.168.10.2 dev eth0  src 10.33.44.1

10.33.44.1 is the virtual IP address inside the tunnel. Linux chooses 
this IP address as the source address for *local* traffic, too. But it 
shouldn't do that in my setup. I need linux to choose 192.168.10.78 as 
the source address for *local* traffic because that's the IP address of 
the interface.

Routing table 220 has higher priority than the routing table "main". 
Because of that the routing table entry

128.0.0.0/1 via 192.168.10.2 dev eth0  src 10.33.44.1

takes precedence over the correct routing table entry in table "main" 
for local traffic.

What I ended up doing is to duplicate the routing table entry for local 
traffic and to insert it into table 220.

192.168.10.0/24 dev eth0  scope link
0.0.0.0/1 via 192.168.10.2 dev eth0  src 10.33.44.1
128.0.0.0/1 via 192.168.10.2 dev eth0  src 10.33.44.1

Does anybody know of a more elegant way to do that.

For the sake of completeness here's the data of the local NIC.

2: eth0:  mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
 inet 192.168.10.78/24 brd 192.168.10.255 scope global eth0
 inet 10.33.44.1/32 scope global eth0


Thanks & Regards
  Daniel

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

Re: [strongSwan] Internet traffic through VPN

[Daniel Mentz]

Tica wrote:
> Now I need to route all internet traffic through the VPN... the remote
> office can only access internet through the main office structure.

Yes. strongSwan provides this functionality. Are you using IKEv1 or IKEv2?

Here's an example for IKEv1 you can take advantage of

http://www.strongswan.org/uml/testresults43/ikev1/passthrough/

The key is to set

rightsubnet=0.0.0.0/0

and to set up a pass through connection so that local traffic is not 
being processed by IPsec.

-Daniel

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

Re: [strongSwan] strongSwan implementation on Ubuntu

[Daniel Mentz]

Hi Stevie,

I guess you're fine. strongSwan meets your requirements. Although 
finding a solution for Windows XP is usually a tough challenge.

Stevie K wrote:
> You might even use the native L2TP/IPsec client of Windows XP although the
>> setup is a bit nasty in my opinion. It also has some (security) problems.
>>
> 
> What kind of security problems?

I haven't found a really good explanation on the web. You might want to 
check

http://support.microsoft.com/default.aspx?scid=kb;en-us;885348

-Daniel

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

[strongSwan] left=%any, leftid=, negotiation of own ID failed

[Daniel Mentz]

I'm using the following simple connection definition in ipsec.conf.

conn vaterstetten
 keyexchange=ikev2
 left=%any
 leftcert=danielCA_server2.pem
 right=86.122.57.21
 rightid="/CN=Vaterstetten/"
 type=transport
 auto=route

I left out leftid= b/c I relied on strongSwan using the DN from the 
X.509 certificate in danielCA_server2.pem.

The connection setup failed with this error message:

"negotiation of own ID failed"

If works if I set

left=%defaultroute

If I understand the documentation correctly then strongSwan figures out 
the interface address of the default route and checks if this IP address 
is included in the certificate as an subjectAltName. Since it's not 
strongSwan uses the DN from the certificate. So far so good.

I can fix the setup also by using

leftid="/CN=server2/"

straight from the start.

My question is why is the initial setup not working.

My goal is to make strongSwan more user friendly i.e. troubleshooting 
should be as easy as possible. The error message "negotiation of own ID 
failed" might not be that helpful.
Can't strongSwan detect this kind of problem when it's reading in the 
config file and complain like "You have to explicitly set leftid if you 
set left=%any".

Also: The wiki should be a bit more verbose regarding this topic:

-- Quote --
left|rightid = 

how the left|right participant should be identified for authentication; 
defaults to left|right.
Can be an IP address (in any ttoaddr(3) syntax) or a fully-qualified 
domain name preceded by @
(which is used as a literal string and not resolved).
-- End of Quote --

It misses out on mentioning that this ID has to match with the 
certificate. It should also mention what's going to happen if it's not 
matching.

The old documentation has some good info about that: "Important:  When 
an FQDN identifier is used it must be explicitly included as a so called 
subjectAltName of type dnsName (DNS:) in the certificate indicated by 
leftcert."

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

Re: [strongSwan] strongSwan implementation on Ubuntu

[Daniel Mentz]

Hi Stevie,

strongSwan meets most if not all of your requirements.

Stevie K wrote:
> ° Key exchanges using Internet PKIs

Please explain what you mean by that. Here's a quote from strongSwan's 
feature list that might be related to this requirement.

- Authentication based on X.509 certificates or preshared keys
- Retrieval and local caching of Certificate Revocation Lists via HTTP 
or LDAP
- Full support of the Online Certificate Status Protocol (OCSP, RCF 2560).
- CA management (OCSP and CRL URIs, default LDAP server)
- Powerful IPsec policies based on wildcards or intermediate CAs
- Group policies based on X.509 attribute certificates (RFC 3281)

> Is this possible with strongSwan and are there any HOWTOs?

Please check
http://wiki.strongswan.org/projects/show/strongswan

and

http://www.strongswan.org/docs.htm

The latter might be a little bit out-dated but still contains a very 
good tutorial.

> What VPN client software is available for Windows XP that can be used with
> strongSwan?

I successfully used
NCP Secure Entry Client  (Win32/64)
which is unfortunately pretty expensive (142.80 EUR per license).
There might be other clients for WinXP as well.

You might even use the native L2TP/IPsec client of Windows XP although 
the setup is a bit nasty in my opinion. It also has some (security) 
problems.

You might also be able to use Ciscos VPN client although there are 
license/legal issues. Check
http://wiki.strongswan.org/wiki/strongswan/Autoconf
for
--enable-cisco-quirks

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

Re: [strongSwan] Trouble on establishing ESP channel

[Daniel Mentz]

Salut Jean-Paul!

> A tcpdump on LAN interface Debian box shows the icmp request packets.
> A tcpdump on Public interface Debian box shows no icmp request packet.

I have a similar setup here at our site. Regarding tcpdump you should see:

- An outgoing ESP packet. (icmp request encrypted)
- An incoming ESP packet. (icmp reply encrypted)
- An incoming ICMP echo reply unencrypted.

I admit that there's an asymmetry. One might expect to see a plaintext 
outgoing ICMP echo request. But that's a feature of the Linux kernel.

The fact that your traffic doesn't go through appears like a firewall 
problem to me. Here are some examples from my setup:

# Make sure not to block traffic handled by IPsec
iptables -A FORWARD -s 192.168.99.0/24 -m policy --dir out --pol ipsec 
-j ACCEPT
iptables -A FORWARD -d 192.168.99.0/24 -m policy --dir in --pol ipsec -j 
ACCEPT

iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT
iptables -A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT

# Do not mess with packets comming over IPSec
# Put those rules at the very top
iptables -t nat -A PREROUTING -m policy --dir in --pol ipsec -j ACCEPT
iptables -t nat -A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT

# Accept ESP traffic from ppp0
iptables -A INPUT -i ppp0 -p esp -j ACCEPT

# Allow outgoing ESP traffic on ppp0
iptables -A OUTPUT -o ppp0 -p esp -j ACCEPT

Let me know it works for you.

Bonne chance!
-Daniel
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] An issue about the ipsec starter

[Daniel Mentz]

weiping deng wrote:
> When I set the "left=%defaultroute" in ipsec.conf and start the ipsec, the
> following item was always indicated: 

Would you mind sending the output of

ip route show table 0

to shed some light on your routing table.
-Daniel
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] needing help

[Daniel Mentz]

Yong Choo wrote:
> - Can I control whether to use IPV4 or IPV6? Is it automatic? If not so, 
> how? How can I find the IPVx usage on the log?

I guess it depends on whether you use IPv4 or IPv6 addresses in the 
config files. Take a look at

http://www.strongswan.org/uml/testresults4/ipv6/

Maybe these examples can help you.

> - Any info on 'charon' from the 'user' perspective? (at least it is NOT 
> quite readily visible on 
> http://wiki.strongswan.org/wiki/strongswan/UserDocumentation), e.g. does 
> it get started automatically or must be done manually, parameters, etc.

The default is to start it automatically, to explicitly turn it off use.

config setup
charonstart=no


You can also prevent the IKEv1 daemon from getting started by using

config setup
plutostart=no

Check out
http://wiki.strongswan.org/wiki/strongswan/ConfigSetupSection

Also, you have to use

keyexchange=ikev2

For an individual connection to use IKEv2. Check out

http://wiki.strongswan.org/wiki/strongswan/IKEv2Examples

for more examples.


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

Re: [strongSwan] Antw: Re: strongSwan + iPhone

[Daniel Mentz]

Hi Uwe,

great! You made it work! Why not give something back to the community 
and share your knowledge on the strongSwan wiki.

If you've got free time then log on to

http://wiki.strongswan.org/

and write an article about how to configure strongSwan to interoperate 
with the popular iPhone. I did a search on "iphone" and got no results. 
So I guess you would be the first.

I've also got some further questions:

You set
rightid=vpngate...@test.de

Is that e-mail address part of the certificate in vpngateway.pem? I 
guess it must be a subject alternative name. If not, strongswan ignores it.

What are the constraints for the DNS names in subjectAltName? Do they 
have to resolve to the IP addresses that are also subjectAltNames?

-Daniel


Uwe Knop wrote:
> Hallo Wolfram, hallo Andreas,
> 
> the most important thing is an expanded x509v3 certificate with the following 
> attribute.
> 
> create Certificate with modified openssl.cnf for this vpn-gateway.
> 
> -subjectAltName=email:copy
> +subjectAltName=email:copy, DNS:dns1.vpngatewaydomain.de, 
> DNS.dns2.vpngatewaydomain.de, IP:xx.xx.xx.xx, IP:xx.xx.xx.yy
> 
> 
> here is my running config for iPhone 3GS.
> 
> conn   xauth-iphone
> right=
> rightcert=vpngateway.pem
> rightsubnet=0.0.0.0/0
> rightid=vpngate...@test.de
> leftsubnetwithin=0.0.0.0/0
> leftca=%same
> leftsourceip=10.10.10.1
> authby=xauthrsasig
> xauth=server
> pfs=no
> dpdaction=restart
> auto=add
> 
> /etc/ipsec.secrets
> 
> # iPhone Cisco VPN Client
> : XAUTH test "test"
> 
> sorry for my poor english.
> 
> bye Uwe

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

Re: [strongSwan] Ipsec routing / policy when leftside is part of rideside network

[Daniel Mentz]

Andreas Ascheneller wrote:
> So now it works ;-)
Great!

> I have done the following steps;
> 
> 1.) I have add your "conn" to my ipsec.conf.
> conn pass
>   leftsubnet=172.16.0.16/29
>   rightsubnet=172.16.0.16/29
>   left=%defaultroute
>   right=a.b.c.d
>   type=passthrough
>   authby=never
>   auto=route

I meant that you replace "right=a.b.c.d" by some valid IP address. 
Although "right=" should not be required for this kind of passthrough 
connection. Strongswan still requires it though. The error message is 
"cannot route Road Warrior template" if you leave out "right=".

@strongSwan core team: Do we really need "right=" for this type of 
connection. It shouldn't be required because there's no remote peer.

Thanks
  Daniel

> 
> 2.) I have add routing entries, see the console output under 
> http://www.strongswan.org/uml/testresults42/ikev1/passthrough/console.log
> ip rule add pref 50 table 50
> ip route add 172.16.0.16/29 via 172.16.0.17 table 50
> 
> Now when I start ipsec, the ping on the local network works!

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