[strongSwan] conditional expressions in swanctl.conf?

[Harald Dunkel]

Hi folks,

is there some way to express

if peercert->OU == develop
pool = pool1
else
pool = pool2

in swanctl.conf? Some conditional expressions?

Hopefully I was not too blind to find it in the Wiki.


Regards
Harri

[strongSwan] ESP over 4500/UDP for IPv6 on Windows 10?

[Harald Dunkel]

Hi folks,

To work around some sites having problems with ESP over IPv6 I had
disabled ESP by setting

forceencaps = yes

in ipsec.conf on my gateway. It worked fine for MacOS, iphones and
Linux, but many Windows users (if not all) were offline. Is this as
expected? Is there a hidden checkbox somewhere in Windows 10 to
optionally enable ESP over 4500/UDP?

https://docs.strongswan.org/docs/5.9/features/natTraversal.html
mentions that the whole NAT-T thing is optional, without giving
more specific details.


Every insightful comment is highly appreciated

Harri

[strongSwan] strongswan vs Fritzbox

[Harald Dunkel]

Hi folks,

environment:
VPN gateway running Debian 11 and strongswan 5.9.6
appr 140 road-warrior devices (Linux, Windows, MacOS/ios)

According to

https://en.avm.de/service/knowledge-base/dok/FRITZ-Box-7590/169_Using-VPN-software-from-another-manufacturer-in-the-home-network/

the Fritzbox (a very popular DSL/cable consumer modem in Germany) supports
just a single ESP connection per remote VPN gateway to pass through. If you
have (lets say) a phone and a laptop to connect to the same VPN gateway in
the office, you are out of luck.

I am not sure if this restriction is reasonable, but actually it seems to be
implemented this way. The VPN connection is established successfully, but ESP
from the VPN gateway to the road-warrior seems to be blocked. After a few
minutes the road-warrior deletes the connection and tries again.

Of course I enabled the encap = yes on the VPN gateway to enforce ESP-in-UDP
encapsulation as a workaround, but I wouldn't like to keep it, affecting all
road warriors, even if they do not own a Fritzbox. It might create new problems.

Do you think charon running on the VPN gateway would be able to detect the
lost ESP traffic and switch over to ESP encapsulation automatically?


Regards

Harri

Re: [strongSwan] how to tell charon-nm to use 500/udp and 4500/udp

[Harald Dunkel]

Hi Tobias,

On 2022-07-14 16:15:29, Tobias Brunner wrote:

Hi Harald,


is there some way to tell charon-nm to use 4500/udp for the outgoing
connection, instead of an arbitrary port, if available? Same for
500/udp.


You can explicitly configure the ports via strongswan.conf
(charon-nm.port and charon-nm.port_nat_t).  Just make sure you don't use
charon or charon-systemd on the same host to avoid conflicts.



Of course I will look into this, but how comes using 500/udp and 4500/udp
isn't the default? Thats how I read https://wiki.strongswan.org/projects/\
strongswan/wiki/ConnSection, left|rightikeport.


I assume a problem on the AVM Fritzbox in this context. 500/udp and
4500/udp at both ends appears to be more reliable.


That doesn't really make sense as there could always be a NAT in between
that changes the source ports.



I am aware of that. It is not working, i.e. we cannot assume a reasonable
implementation. Fact is, the traffic returned by my VPN gateway (4500/udp
to lets say 32480/udp) at the end of phase 2 (IKE2) doesn't reach the home
office laptop of my colleague (both strongswan). I just cannot say if this
is sabotaged by his IP provider or if this is a broken stateful package
filter or some other bug in the Fritzbox. What would be your guess here?


Also, has AVM finally released a version of their system that supports
IKEv2?  Took them long enough.  But considering their track record
regarding IKEv1, I guess we have to expect interoperability issues for
the next 20 years.


This is a misunderstanding. Both peers are running a recent Debian and
strongswan 5.9.6. The Fritzbox is just the modem/gateway/firewall in
my colleagues home network. I understand that the Fritzbox runs its own
IPsec connections. Yet another reason to assume a bug in the Fritzbox
in this context.


Regards

Harri

[strongSwan] how to tell charon-nm to use 500/udp and 4500/udp

[Harald Dunkel]

Hi folks,

is there some way to tell charon-nm to use 4500/udp for the outgoing
connection, instead of an arbitrary port, if available? Same for
500/udp.

I assume a problem on the AVM Fritzbox in this context. 500/udp and
4500/udp at both ends appears to be more reliable. However, I am not
sure at all where the temporary port comes from. I have just very
restricted access to the peer, since VPN is not working yet.


Regards

Harri

Re: [strongSwan] How does strongswan handle renewed or expired CRLs?

[Harald Dunkel]

Hi Tobias,

On 2022-04-01 12:05:38, Tobias Brunner wrote:



Even on
"ipsec rereadcrls" the new CRL was ignored.


This reads CRLs from /etc/ipsec.d/crls, nothing else.  To flush the
in-memory cache use `ipsec purgecrls` (CRLs cached on disk have to be
deleted manually from the directory above, note that that requires a
restart).



this is hard to anticipate. Running rereadcrls, why should I want to
prefer the cached CRLs over the CRLs to be found in the net? To avoid
a DNS lookup and a single web access?

Typically the PKIs create a CRL for lets say 30 days. In case of emergency
a new CRL might be issued on the next day. How is strongswan supposed
to be notified about this emergency? There is no flow of information here.

I would suggest to invest into the web access at least once per day,
regardless when the CRL is supposed to expire. If the remote site is not
reachable, then we can fall back to the cached version.


Just a suggestion, of course. Should I file an enhancement request?


Regards
Harri

[strongSwan] How does strongswan handle renewed or expired CRLs?

[Harald Dunkel]

TL,DR:
How does strongswan handle renewed or expired CRLs?
Platform: 5.9.4 on Debian 11. Private CA. CRL distributed
via http.


Hi folks,

Apparently certificate revocation lists have an expiration date. AFAIU
this is the maximum time a CRL should be cached.

I had revoked a few road-warrior certificates and put a new CRL on
my web server within this grace period, but strongswan refused to
check the URL for an update, as Apache's access.log shows. Even on
"ipsec rereadcrls" the new CRL was ignored. I had to restart
strongswan to make it use the new CRL. Is this as expected?

And a related question: Do I have to assume that all road-warrior
certificates become unusable, if the CRL mentioned in the certificates
expires?


Regards

Harri

Re: [strongSwan] question about DPD

[Harald Dunkel]

Hi Tobias,

On 6/8/21 10:19 AM, Tobias Brunner wrote:

Hi Harri,


question about DPD in a road-warrior configuration: Is it
sufficient for either side to answer DPD packets, or should
both sides run their own DPD in parallel, independent from
the DPD sent by their peer?


DPDs are INFORMATIONAL exchanges, so both peers will send a message in a
single DPD exchange, doesn't really matter which peer initiates it.


Looking at the Fritzbox web page I see

The FRITZ!Box checks all incoming and outgoing data packets and
automatically rejects unwanted data from the internet (Stateful
Packet Inspection). This way only data packets that are direct
replies to previous requests reach the home network.

I have read this as "If the DPD exchange wasn't initiated locally
by the laptop, stateful packet information cache is not renewed."


However, in road warrior setups with mobile clients it's usually better
if the server doesn't send DPDs for a relatively long time as it might
otherwise remove state when a client is asleep or roaming about for a
while.  Keeping the state allows such clients to quickly restore
connectivity via MOBIKE.


Maybe thats the point. Looking at the IPsec gateway's log file I
don't have the impression that Windows 10 on the peer sends DPD
packets at all. I will increase the dpddelay (90sec --> 600secs),
hoping that either Windows sends a DPD request first or that it is
reconnected on the fly via Mobike, as you suggested.

[snip]



But DPDs are not really intended to keep firewall or NAT mappings alive,
as they are usually sent only if no packet (IKE or ESP) has been
_received_ from the peer for the configured DPD delay (which might also
be longer that the lifetime of firewall/NAT mappings).

If a client is behind a NAT, there is a second mechanism that prevents
NAT mappings from disappearing, NAT keepalives, which use the opposite
trigger, i.e. they are sent if no other traffic (IKE or ESP) has been
_sent_ to the peer.  However, for strongSwan, there is currently no
option to force sending such keepalives if there is no NAT (e.g. to keep
firewall states alive).  If there is a NAT, you might have to adjust the
keepalive interval if the NAT mappings/firewall states disappear often
(depends on the client if you can actually adjust that).



I have several road warrior laptops with occasional DPD problems. They
don't answer DPD anymore, but create a new connection instead. Most of
them (if not all) use IPv6 and ESP, AFAICT. No NAT.


Regards
Harri

[strongSwan] question about DPD

[Harald Dunkel]

Hi folks,

question about DPD in a road-warrior configuration: Is it
sufficient for either side to answer DPD packets, or should
both sides run their own DPD in parallel, independent from
the DPD sent by their peer?

Reason for asking is, I have the impression that some home
office gateways keep track only of the outgoing traffic
(laptop to VPN gateway) to keep their stateful firewall
alive, ignoring incoming DPD traffic sent by the VPN gateway.


Every helpful comment is highly appreciated

Harri

[strongSwan] firewall configuration on Linux for IKE and dpd?

[Harald Dunkel]

Hi folks,

I wonder if it is reasonable to use connection tracking for
500/udp and 4500/udp in the iptables configuration, esp.
wrt dead peer detection?


Your thoughts on this?

Regards
Harri

Re: [strongSwan] how to increase timeout for "deleting half open IKE_SA with after timeout" ?

[Harald Dunkel]

On 5/14/21 9:21 PM, Thomas Egerer wrote:


What you're looking for is not a part of the swanctl.conf or ipsec.conf. It's 
part
of the strongswan.conf (/etc/strongswan.conf) and documented at [1]. Use
the keyword 'half_open_timeout' in the 'charon' section:


charon {
half_open_timeout = 42
}




Found it, thanx very much

Harri

[strongSwan] how to increase timeout for "deleting half open IKE_SA with after timeout" ?

[Harald Dunkel]

Hi folks,

I have a few road warriors (3 out of ~140) having severe problems to
connect via IKEv2. Within the last 4 weeks they had >1000 problems
during IKE SA init each, e.g.:

May 12 09:55:28 18[NET1] <92244> received packet: from 192.168.1.177[61416] to 
10.0.0.17[500] (432 bytes)
May 12 09:55:28 18[ENC1] <92244> parsed IKE_SA_INIT request 0 [ SA KE No 
N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
May 12 09:55:28 18[IKE0] <92244> 192.168.1.177 is initiating an IKE_SA
May 12 09:55:28 18[IKE2] <92244> IKE_SA (unnamed)[92244] state change: CREATED 
=> CONNECTING
May 12 09:55:28 18[CFG1] <92244> selected proposal: 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
May 12 09:55:28 18[IKE1] <92244> remote host is behind NAT
May 12 09:55:28 18[IKE2] <92244> sending strongSwan vendor ID
May 12 09:55:28 18[IKE1] <92244> sending cert request for "C=DE, O=example AG, 
CN=ws-CA"
May 12 09:55:28 18[IKE1] <92244> sending cert request for "C=DE, O=example AG, 
OU=example Certificate Authority, CN=root-CA"
May 12 09:55:28 18[IKE1] <92244> sending cert request for "C=DE, ST=NRW, O=example 
AG, OU=TI, CN=ipsec-ca"
May 12 09:55:28 18[ENC1] <92244> generating IKE_SA_INIT response 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) V ]
May 12 09:55:28 18[NET1] <92244> sending packet: from 10.0.0.17[500] to 
192.168.1.177[61416] (541 bytes)
May 12 09:55:58 31[JOB1] <92244> deleting half open IKE_SA with 192.168.1.177 
after timeout
May 12 09:55:58 31[IKE2] <92244> IKE_SA (unnamed)[92244] state change: CONNECTING 
=> DESTROYING

Obviously there is a 30sec timeout on the IPsec gateway. Is there
a chance to increase this timeout (using stroke, ie. ipsec.conf)?
https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
mentions only the DPD timeout (150 sec per default) and the inac-
tivity timeout (child sa only, as it seems).

Would it be wise to resend the IKE_SA_INIT response (lets say) 3
times?


Every helpful comment is highly appreciated

Harri

[strongSwan] how to compute charon's MAC address?

[Harald Dunkel]

Hi folks,

how can I compute the MAC address used for farp/dhcp (7a:a7:xx:xx:xx:xx),
*before* trying to connect? Need this for configuring dhcp.


Regards
Harri

Re: [strongSwan] does aa3d5bf7916ce8fed0051feadae0b0139d5fbe24 (tun device for charon-nm) affect iptables?

[Harald Dunkel]

Hi Tobias,

On 1/25/21 9:46 AM, Tobias Brunner wrote:

Hi Harri,


is it possible that aa3d5bf7916ce8fed0051feadae0b0139d5fbe24 (Revert "nm: Remove 
dummy TUN device") affects iptables?


In what way?

Regards,
Tobias



ip link shows me a new network interface "tun0" that wasn't there before
the strongswan upgrade, AFAIR. Do I have to define additional rules in
iptables for tun0?

Regards
Harri

[strongSwan] does aa3d5bf7916ce8fed0051feadae0b0139d5fbe24 (tun device for charon-nm) affect iptables?

[Harald Dunkel]

Hi folks,

is it possible that aa3d5bf7916ce8fed0051feadae0b0139d5fbe24 (Revert "nm: 
Remove dummy TUN device") affects iptables?

Regards
Harri

Re: [strongSwan] Docker on road warrior laptop

[Harald Dunkel]

Hi Noel,

On 2020-01-30 13:45, Noel Kuntze wrote:

Hello Harri,

The NAT rules on the host need to change the source IP address to match the 
negotiated IPsec policies' local TS.



The road warrior's IP address in the TS appears to be chosen by the IPsec
gateway. How is the Docker container's network driver (responsible for the
NAT, AFAICT) supposed to know? Not to mention that the Docker container
might already be running when the IPsec connection is set up. I am not sure
if this is the right path to follow.

Would you suggest to use route-based VPN or maybe a TUN device via the
kernel-libipsec plugin? Actually the road warrior is supposed to use the
network manager applet to manage the IPsec connection.

I tried a similar scenario on a Macbook: The docker container can make use
of the IPsec connection setup on MacOS. Of course I understand that there
is some hypervisor involved, so its difficult to compare.


Regards
Harri

https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec

[strongSwan] Docker on road warrior laptop

[Harald Dunkel]

Hi folks,

are there any recommendations how to give a Docker container running on
a road warrior laptop access to the host's IPsec connection?

Easy testcase (using Docker's default bridge network):

% docker run -it --rm debian
# ping some.internal.ip.address
From 10.100.0.2 icmp_seq=1 Destination Port Unreachable
From 10.100.0.2 icmp_seq=2 Destination Port Unreachable
From 10.100.0.2 icmp_seq=3 Destination Port Unreachable
From 10.100.0.2 icmp_seq=4 Destination Port Unreachable
^C
--- some.internal.ip.address ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6ms

As you might have guessed, 10.100.0.2 is the local gateway,

Problem is, the Docker container seems to ignore the IPsec connection and
the subnets accessible via the peer. It tries to use the default gateway.
Thats unfortunate, cause Docker copied /etc/resolv.conf from the host.

I checked the Wiki, of course, but maybe I was too blind to see.
Running Docker *inside* a container is not the use case here; not to
mention that I found 
https://wiki.strongswan.org/projects/strongswan/wiki/Cloudplatforms


Every helpful hint is highly appreciated

Harri

[strongSwan] network manager app: dead peer detection?

[Harald Dunkel]

Hi folks,

I've seen it several times that the dead peer detection on my
IPsec gateway recognized a lost connection to a road warrior
laptop, but the laptop itself didn't know.

Would it be possible to enable dead peer detection and dpdaction
restart in the network manager app?


Regards
Harri

Re: [strongSwan] road warrior MTU issues (IPv4)

[Harald Dunkel]

On 12/11/19 10:39 PM, Harald Dunkel wrote:

Hi folks,

apparently the MacOS road warriors have to manually adjust the MTU on
ipsec0 to 1280 in some networks, e.g. if the IP provider is Unitymedia,
or if they travel in an ICE of Deutsche Bahn and use the free Wifi.
Without *sudo ifconfig ipsec0 mtu 1280* their IPsec connection appears
to be broken.

Problem is, setting the MTU on MacOS is not persistent. On the next
IPsec connection MacOS has lost the adjusted MTU and goes with the
default 1400 again.

Since the peer runs Strongswan on Linux, I wonder if there is something
that can be done on this side? Is this purely MacOS' fault for not
fragmenting payload accordingly?



PS: I found

https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues

after sending this, but AFAIU reducing the mss affects outgoing TCP traffic
only.


Regards
Harri

[strongSwan] road warrior MTU issues (IPv4)

[Harald Dunkel]

Hi folks,

apparently the MacOS road warriors have to manually adjust the MTU on
ipsec0 to 1280 in some networks, e.g. if the IP provider is Unitymedia,
or if they travel in an ICE of Deutsche Bahn and use the free Wifi.
Without *sudo ifconfig ipsec0 mtu 1280* their IPsec connection appears
to be broken.

Problem is, setting the MTU on MacOS is not persistent. On the next
IPsec connection MacOS has lost the adjusted MTU and goes with the
default 1400 again.

Since the peer runs Strongswan on Linux, I wonder if there is something
that can be done on this side? Is this purely MacOS' fault for not
fragmenting payload accordingly?


Every helpful comment is highly appreciated.

Harri

Re: [strongSwan] broken arp support in Strongswan 5.7.2 ?

[Harald Dunkel]

Hi Noel,

On 8/26/19 6:40 PM, Noel Kuntze wrote:

Hello Harald,

That by itself is quite useless. Please provide the outputs of `ipsec statusall`
(or `swanctl -l`, depending on what frontend you're using), `ip route show 
table all`, `ip rule` and `ip address`.

Kind regards

Noel



See attachments. It is the requested information of both
roadwarrior laptop and ipsec gateway.

10.19.96.0/19 is the internal network.
10.100.0.0/16 is the wlan network.
192.168.0.0/27 is the external network.

The network.txt shows the network topology. The roadwarrior
laptop was connected via cable to the 10.19.96.0/19 network.
Its IP address was 10.19.97.9, obtained via dhcp.
"ping -c 3 10.19.96.156" worked as expeceted.

Then the cable was pulled, a wlan connection was established
and the IPsec connection to the gateway (192.168.0.17) was
created. The IPsec gateway used strongswan's dhcp and farp
plugins to obtain and announce an IP address. The 10.19.97.9
got reused here(!).

The laptop should be able to ping 10.19.96.156 again, but
10.19.96.156 sends the echo reply to the "old" mac address
known from the wired connection to the roadwarrior. The
laptop can access other hosts in the 10.19.96.0/19 network,
if they hadn't been accessed via the cable network connection
before.

How comes? The first ping from the "new" 10.19.97.9 should
have changed the arp table on 10.19.96.156, but obviously
it didn't. 10.19.96.156 sent the echo reply back to the
old MAC address of the roadwarriors wired network connection,
as it seems.

Hope this helps to make things clear. Every insightful
comment is highly appreciated.



Regards
Harri
# ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.9.0-9-amd64, x86_64):
  uptime: 27 days, since Aug 02 06:12:33 2019
  malloc: sbrk 9699328, mmap 0, used 2981440, free 6717888
  worker threads: 27 of 32 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 1354
  loaded plugins: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 
md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 
pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp 
curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink 
resolve socket-default connmark farp stroke vici updown eap-identity eap-aka 
eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic 
xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock 
unity counters
Listening IP addresses:
  192.168.0.17
Connections:
 IPSec-IKEv2:  stargate.example.com...%any  IKEv2, dpddelay=90s
 IPSec-IKEv2:   local:  [stargate.example.com] uses public key authentication
 IPSec-IKEv2:cert:  "C=DE, ST=NRW, L=Aachen, O=example AG, OU=TI, 
CN=stargate.example.com, E=secur...@example.com"
 IPSec-IKEv2:   remote: uses public key authentication
 IPSec-IKEv2:ca:"C=DE, O=example AG, OU=example Certificate Authority, 
CN=root-CA"
 IPSec-IKEv2:   child:  10.19.96.0/19 === dynamic TUNNEL, dpdaction=clear
Security Associations (32 up, 0 connecting):
 :
 :
 IPSec-IKEv2[18785]: ESTABLISHED 17 minutes ago, 
192.168.0.17[stargate.example.com]...192.168.0.13[C=DE, O=example AG, OU=TI, 
CN=ppcl001.ws.example.de]
 IPSec-IKEv2[18785]: IKEv2 SPIs: 5d196fb131ed8f7d_i ad6663180880a37d_r*, public 
key reauthentication in 23 hours
 IPSec-IKEv2[18785]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 IPSec-IKEv2{23582}:  INSTALLED, TUNNEL, reqid 7068, ESP in UDP SPIs: 
cfba0287_i cb8e5e9a_o
 IPSec-IKEv2{23582}:  AES_CBC_256/HMAC_SHA2_256_128, 638892 bytes_i (971 pkts, 
153s ago), 1185197 bytes_o (1493 pkts, 153s ago), rekeying in 7 hours
 IPSec-IKEv2{23582}:   10.19.96.0/19 === 10.19.97.9/32
 :
 :

# ip route show table all
10.19.97.9 via 192.168.0.13 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.50 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.54 via 192.168.0.1 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.55 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.60 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.64 via 192.168.0.13 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.66 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.67 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.69 via 192.168.0.13 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.82 via 192.168.0.1 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.83 via 192.168.0.13 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.84 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.87 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.88 via 192.168.0.13 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.96 via 192.168.0.13 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.107 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.108 via 192.168.0.1 dev eth0 table 220 proto static src 10.19.96.153 
10.19.97.109 via 192.168.0.13 dev 

[strongSwan] broken arp support in Strongswan 5.7.2 ?

[Harald Dunkel]

Hi folks,

road warrior setup:

If I disconnect the cable, wait for Network Manager to
recognize, and enable IPsec over WLAN to connect to the
same network, then some hosts become inaccessible.

tcpdump on such an inaccessible host (CentOS 7.4) shows:

# tcpdump -envi eno1 icmp
tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 
bytes
13:25:00.000842 80:ee:73:a2:e6:16 > a4:bf:01:37:0b:26, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 63, id 51353, offset 0, flags [DF], proto ICMP (1), 
length 84)
10.19.97.9 > 10.19.96.156: ICMP echo request, id 13502, seq 1, length 64
13:25:00.000874 a4:bf:01:37:0b:26 > 28:d2:44:3d:86:74, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 47437, offset 0, flags [none], proto ICMP (1), 
length 84)
10.19.96.156 > 10.19.97.9: ICMP echo reply, id 13502, seq 1, length 64
13:25:01.021662 80:ee:73:a2:e6:16 > a4:bf:01:37:0b:26, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 63, id 51561, offset 0, flags [DF], proto ICMP (1), 
length 84)
10.19.97.9 > 10.19.96.156: ICMP echo request, id 13502, seq 2, length 64
13:25:01.021686 a4:bf:01:37:0b:26 > 28:d2:44:3d:86:74, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 48192, offset 0, flags [none], proto ICMP (1), 
length 84)
10.19.96.156 > 10.19.97.9: ICMP echo reply, id 13502, seq 2, length 64
13:25:02.045154 80:ee:73:a2:e6:16 > a4:bf:01:37:0b:26, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 63, id 51567, offset 0, flags [DF], proto ICMP (1), 
length 84)
10.19.97.9 > 10.19.96.156: ICMP echo request, id 13502, seq 3, length 64
13:25:02.045187 a4:bf:01:37:0b:26 > 28:d2:44:3d:86:74, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 48515, offset 0, flags [none], proto ICMP (1), 
length 84)
10.19.96.156 > 10.19.97.9: ICMP echo reply, id 13502, seq 3, length 64

Please note the bad destination mac used for the echo reply.
It is still the mac for the cable connection. How comes? Ain't
the arp table entries supposed to be overwritten on the first
incoming package using the new mac address?

All IPsec peers run Debian 9.9 and Strongswan 5.7.2. The IPsec
gateway uses the dhcp and farp plugins to obtain the same IP
address as for the cable connection.

The dhcp server runs Debian 9.9 and isc-dhcp-server 4.3.5-3+deb9u1.


Every insightful comment is highly appreciated.

Harri

[strongSwan] farp question about arp TTL

[Harald Dunkel]

Hi folks,

imagine a road warrior scenario (all peers running Strongswan 5.7.2).

A warrior's laptop is usually connected via ethernet cable to the
company network, but he might prefer an IPsec connection over Wlan
instead, e.g. for the conference room or for home office. Using dhcp
and farp plugins each laptop gets the same address as for the ethernet
connection. Its the same dhcp server.

Problem is: If a warrior pulls the cable, waits for NetworkManager
to recognize and connects via Wlan plus IPsec, then some servers in
the network become unreachable.

Looking closely on such a remote host it seems that there are incoming
packages from the new mac address, but the reply goes to the old
mac address. Of course the old mac address is still in the arp cache.

The weird part is that there is no such problem on moving in the
opposite direction (from Wlan + IPsec to the ethernet connection). All
servers are available immediately after the change. The arp cache
is fixed with the very first incoming package. Obviously there is
some way to clean up the arp cache in place. ???

Is this something that could be improved in Strongswan?


Regards
Harri

Re: [strongSwan] IKEv2: how to set the DNS search attribute on the peer?

[Harald Dunkel]

On 7/1/19 3:06 PM, Tobias Brunner wrote:


Nobody forces you to use IPsec :-)



:-(

[strongSwan] IKEv2: how to set the DNS search attribute on the peer?

[Harald Dunkel]

Hi folks,

using IKEv2 and NetworkManager I wonder how the DNS domain search
attribute is supposed to be added to /etc/resolv.conf?

My attr.conf on the IPsec gateway says

attr {
dns = 10.0.122.9, 10.0.96.123, 10.0.96.124
nbns = 10.0.98.253
28674 = ipsec.example.com ac.example.com vs.example.com ws.example.com 
example.com
28675 = ipsec.example.com ac.example.com vs.example.com ws.example.com 
example.com
load = yes

}

AFAICT NetworkManager would like to call resolvconf itself, but apparently
it is missing the DNS domain. syslog on my laptop tells me

Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.5404] audit: op="connection-activate" 
uuid="e3e13c44-f079-42d9-9d40-5156082f2914" name="ipsecgate IKEv2" pid=5931 uid=6502 
result="success"
Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.5435] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Saw the service appear; activating connection
Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.5633] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN connection: (ConnectInteractive) reply received
Jul  1 08:25:19 ppcl001 charon-nm: 05[CFG] received initiate for NetworkManager 
connection ipsecgate IKEv2
Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.6125] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN plugin: state changed: starting (3)
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7119] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN connection: (IP4 Config Get) reply received from old-style plugin
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: VPN Gateway: 5.145.142.209
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: Tunnel Device: (null)
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: IPv4 configuration:
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal Address: 10.0.122.66
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal Prefix: 32
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal Point-to-Point Address: 10.0.122.66
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Maximum Segment Size (MSS): 0
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Forbid Default Route: yes
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 10.0.122.9
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 10.0.96.123
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 10.0.96.124
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 127.0.0.1
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   DNS Domain: '(none)'
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: No IPv6 configuration
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7134] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN connection: (IP Config Get) complete
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7134] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN plugin: state changed: started (4)
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7225] dns-mgr: 
Writing DNS information to /sbin/resolvconf

Of course the documentation states: "Cisco Unity extensions for IKEv1"
but I don't see any reason why this 

[strongSwan] IKEv2: how to set the DNS search attribute on the peer?

[Harald Dunkel]

Hi folks,

using IKEv2 and NetworkManager I wonder how the DNS domain search
attribute is supposed to be added to /etc/resolv.conf?

My attr.conf on the IPsec gateway says

attr {
dns = 10.0.122.9, 10.0.96.123, 10.0.96.124
nbns = 10.0.98.253
28674 = ipsec.example.com ac.example.com vs.example.com ws.example.com 
example.com
28675 = ipsec.example.com ac.example.com vs.example.com ws.example.com 
example.com
load = yes

}

AFAICT NetworkManager would like to call resolvconf itself, but apparently
it is missing the DNS domain. syslog on my laptop tells me

Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.5404] audit: op="connection-activate" 
uuid="e3e13c44-f079-42d9-9d40-5156082f2914" name="ipsecgate IKEv2" pid=5931 uid=6502 
result="success"
Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.5435] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Saw the service appear; activating connection
Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.5633] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN connection: (ConnectInteractive) reply received
Jul  1 08:25:19 ppcl001 charon-nm: 05[CFG] received initiate for NetworkManager 
connection ipsecgate IKEv2
Jul  1 08:25:19 ppcl001 NetworkManager[992]:   [1561962319.6125] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN plugin: state changed: starting (3)
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7119] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN connection: (IP4 Config Get) reply received from old-style plugin
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: VPN Gateway: 5.145.142.209
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: Tunnel Device: (null)
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: IPv4 configuration:
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal Address: 10.0.122.66
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal Prefix: 32
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal Point-to-Point Address: 10.0.122.66
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7126] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Maximum Segment Size (MSS): 0
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Forbid Default Route: yes
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 10.0.122.9
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 10.0.96.123
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 10.0.96.124
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   Internal DNS: 127.0.0.1
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data:   DNS Domain: '(none)'
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7127] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: Data: No IPv6 configuration
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7134] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN connection: (IP Config Get) complete
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7134] 
vpn-connection[0x55858e7ca870,e3e13c44-f079-42d9-9d40-5156082f2914,"ipsecgate 
IKEv2",0]: VPN plugin: state changed: started (4)
Jul  1 08:25:26 ppcl001 NetworkManager[992]:   [1561962326.7225] dns-mgr: 
Writing DNS information to /sbin/resolvconf

Of course the documentation states: "Cisco Unity extensions for IKEv1"
but I don't see any reason why this 

Re: [strongSwan] dhcp plugin, isc-dhcp vs dnsmasq

[Harald Dunkel]

On 1/16/19 9:38 AM, Harald Dunkel wrote:

Hi folks,

attached you can find charon's and dnsmasq's log files (running on the
same hardware).



Strongswan's dhcp plugin sends out the DHCPDISCOVER at 10:48:07. dnsmasq
seems to wake up somehow (there is a log file entry), but at 10:48:10
it finally recognizes the DHCPDISCOVER messages and answers with a
DHCPOFFER.

Regards
Harri

Re: [strongSwan] dhcp plugin, isc-dhcp vs dnsmasq

[Harald Dunkel]

Hi folks,

attached you can find charon's and dnsmasq's log files (running on the
same hardware).

Hope this helps
Harri
Jan 14 10:48:07 12[NET] <43> received packet: from 192.168.1.13[61985] to 
192.168.1.209[500] (1256 bytes)
Jan 14 10:48:07 12[ENC] <43> parsed IKE_SA_INIT request 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jan 14 10:48:07 12[IKE] <43> 192.168.1.13 is initiating an IKE_SA
Jan 14 10:48:07 12[CFG] <43> selected proposal: 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Jan 14 10:48:07 12[IKE] <43> remote host is behind NAT
Jan 14 10:48:07 12[IKE] <43> sending cert request for "C=DE, ST=NRW, O=example 
AG, OU=TI, CN=ipsec-ca"
Jan 14 10:48:07 12[IKE] <43> sending cert request for "C=DE, O=example AG, 
CN=ws-CA"
Jan 14 10:48:07 12[IKE] <43> sending cert request for "C=DE, O=example AG, 
OU=example Certificate Authority, CN=root-CA"
Jan 14 10:48:07 12[ENC] <43> generating IKE_SA_INIT response 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) V ]
Jan 14 10:48:07 12[NET] <43> sending packet: from 192.168.1.209[500] to 
192.168.1.13[61985] (549 bytes)
Jan 14 10:48:07 31[NET] <43> received packet: from 192.168.1.13[63486] to 
192.168.1.209[4500] (1236 bytes)
Jan 14 10:48:07 31[ENC] <43> parsed IKE_AUTH request 1 [ EF(1/3) ]
Jan 14 10:48:07 31[ENC] <43> received fragment #1 of 3, waiting for complete 
IKE message
Jan 14 10:48:07 10[NET] <43> received packet: from 192.168.1.13[63486] to 
192.168.1.209[4500] (1236 bytes)
Jan 14 10:48:07 10[ENC] <43> parsed IKE_AUTH request 1 [ EF(2/3) ]
Jan 14 10:48:07 10[ENC] <43> received fragment #2 of 3, waiting for complete 
IKE message
Jan 14 10:48:07 18[NET] <43> received packet: from 192.168.1.13[63486] to 
192.168.1.209[4500] (900 bytes)
Jan 14 10:48:07 18[ENC] <43> parsed IKE_AUTH request 1 [ EF(3/3) ]
Jan 14 10:48:07 18[ENC] <43> received fragment #3 of 3, reassembled fragmented 
IKE message (3232 bytes)
Jan 14 10:48:07 18[ENC] <43> parsed IKE_AUTH request 1 [ IDi CERT CERT 
N(INIT_CONTACT) CERTREQ AUTH CPRQ(ADDR DNS NBNS) SA TSi TSr N(MOBIKE_SUP) 
N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Jan 14 10:48:07 18[IKE] <43> received cert request for "C=DE, O=example AG, 
OU=example Certificate Authority, CN=root-CA"
Jan 14 10:48:07 18[IKE] <43> received end entity cert "C=DE, ST=NRW, 
L=Metropolis, O=example AG, CN=roadwarrior.ac.example.de, E=secur...@example.de"
Jan 14 10:48:07 18[IKE] <43> received issuer cert "C=DE, ST=NRW, O=example AG, 
OU=TI, CN=ipsec-ca"
Jan 14 10:48:07 18[CFG] <43> looking for peer configs matching 
192.168.1.209[%any]...192.168.1.13[C=DE, ST=NRW, L=Metropolis, O=example AG, 
CN=roadwarrior.ac.example.de, E=secur...@example.de]
Jan 14 10:48:07 18[CFG]  selected peer config 'IPSec-IKEv2'
Jan 14 10:48:07 18[CFG]using certificate "C=DE, ST=NRW, 
L=Metropolis, O=example AG, CN=roadwarrior.ac.example.de, E=secur...@example.de"
Jan 14 10:48:07 18[CFG]using trusted intermediate ca 
certificate "C=DE, ST=NRW, O=example AG, OU=TI, CN=ipsec-ca"
Jan 14 10:48:07 18[CFG]  checking certificate status of "C=DE, 
ST=NRW, L=Metropolis, O=example AG, CN=roadwarrior.ac.example.de, 
E=secur...@example.de"
Jan 14 10:48:07 18[CFG]fetching crl from 
'http://pki.example.de/pki/ipsec-ca.crl' ...
Jan 14 10:48:07 18[CFG]using trusted ca certificate "C=DE, 
O=example AG, OU=example Certificate Authority, CN=root-CA"
Jan 14 10:48:07 18[CFG]reached self-signed root ca with a 
path length of 0
Jan 14 10:48:07 18[CFG]using trusted certificate "C=DE, 
ST=NRW, O=example AG, OU=TI, CN=ipsec-ca"
Jan 14 10:48:07 18[CFG]crl correctly signed by "C=DE, 
ST=NRW, O=example AG, OU=TI, CN=ipsec-ca"
Jan 14 10:48:07 18[CFG]crl is stale: since Mar 31 09:52:00 
2018
Jan 14 10:48:07 18[CFG]  certificate status is unknown, crl is 
stale
Jan 14 10:48:07 18[CFG]using trusted ca certificate "C=DE, 
O=example AG, OU=example Certificate Authority, CN=root-CA"
Jan 14 10:48:07 18[CFG]  checking certificate status of "C=DE, 
ST=NRW, O=example AG, OU=TI, CN=ipsec-ca"
Jan 14 10:48:07 18[CFG]using trusted certificate "C=DE, 
O=example AG, OU=example Certificate Authority, CN=root-CA"
Jan 14 10:48:07 18[CFG]crl correctly signed by "C=DE, 
O=example AG, OU=example Certificate Authority, CN=root-CA"
Jan 14 10:48:07 18[CFG]crl is valid: until Oct 08 12:58:37 
2038
Jan 14 10:48:07 18[CFG]using cached crl
Jan 14 10:48:07 18[CFG]  certificate status is good
Jan 14 10:48:07 18[CFG]reached self-signed root ca with a 
path length of 1
Jan 14 10:48:07 18[IKE]  authentication of 'C=DE, ST=NRW, 
L=Metropolis, O=example AG, CN=roadwarrior.ac.example.de, 
E=secur...@example.de' with RSA_EMSA_PKCS1_SHA2_256 successful
Jan 14 10:48:07 18[IKE]  peer supports MOBIKE
Jan 14 10:48:07 18[IKE]  authentication of 
'ipsecgate.example.com' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful
Jan 14 10:48:07 18[IKE]  IKE_SA IPSec-IKEv2[43] established 
between 

[strongSwan] dhcp plugin, isc-dhcp vs dnsmasq

[Harald Dunkel]

Hi folks,

using isc-dhcp-server 4.3.5 on the peer network my laptop takes just
a second to establish an IPsec connection (dhcp plugin involved, of
course). Using dnsmasq 2.80 it takes at least 3 seconds, maybe 4.

Can anybody reproduce this disadvantage of dnsmasq over isc-dhcp? Do
you think it would help to support rapid commit (rfc4039) in the dhcp
plugin?

(strongswan is version 5.7.2 on the laptop and on the peers. Debian 9)


Regards
Harri

[strongSwan] left|rightikeport obsolete?

[Harald Dunkel]

Hi folks,

the documentation say for left|rightikeport

"If unspecified, port 500 is used with the port floating to 4500 if a
NAT is detected ..."

This sounds pretty vague. I would like to tell strongswan to use 443/udp
for NAT traversal and dead peer detection, and to use port 500/udp for
isakmp as usual. AFAICT this can be done with charon.port and charon.\
port_nat_t, so I wonder what is left|rightikeport good for?


Every insightful comment is highly appreciated
Harri

[strongSwan] problem connecting to Kyocera printer

[Harald Dunkel]

Hi folks,

I have to connect a Kyocera ECOSYS M8130 printer (running in a
foreign environment behind a NAT) to my local network via our road
warrior IPsec gateway. Strongswan 5.6.2. rightsourceip is %dhcp,
as for the road warriors.

The printer has built-in IKEv2 and IPsec support.

Problem: Authentication via PSK or certificate (not shown here)
succeeds, but then the printer and strongswan seem to disagree
about the further steps.

Logfile:

Jul 13 13:35:57 10[NET] <2100> received packet: from 192.168.142.13[52583] to 
192.168.142.17[500] (432 bytes)
Jul 13 13:35:57 10[ENC] <2100> parsed IKE_SA_INIT request 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) ]
Jul 13 13:35:57 10[IKE] <2100> 192.168.142.13 is initiating an IKE_SA
Jul 13 13:35:57 10[IKE] <2100> remote host is behind NAT
Jul 13 13:35:57 10[IKE] <2100> sending cert request for "..."
Jul 13 13:35:57 10[IKE] <2100> sending cert request for "..."
Jul 13 13:35:57 10[IKE] <2100> sending cert request for "..."
Jul 13 13:35:57 10[IKE] <2100> sending cert request for "..."
Jul 13 13:35:57 10[IKE] <2100> sending cert request for "..."
Jul 13 13:35:57 10[IKE] <2100> sending cert request for "..."
Jul 13 13:35:57 10[ENC] <2100> generating IKE_SA_INIT response 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) V ]
Jul 13 13:35:57 10[NET] <2100> sending packet: from 192.168.142.17[500] to 
192.168.142.13[52583] (585 bytes)
Jul 13 13:35:57 16[NET] <2100> received packet: from 192.168.142.13[60908] to 
192.168.142.17[4500] (288 bytes)
Jul 13 13:35:57 16[ENC] <2100> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) 
IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
Jul 13 13:35:57 16[CFG] <2100> looking for peer configs matching 
192.168.142.17[gate.example.com]...192.168.142.13[prn17.red.example.de]
Jul 13 13:35:57 16[CFG]  selected peer config 'prn17-ikev2'
Jul 13 13:35:57 16[IKE]  authentication of 
'prn17.red.example.de' with pre-shared key successful
Jul 13 13:35:57 16[IKE]  authentication of 'gate.example.com' 
(myself) with pre-shared key
Jul 13 13:35:57 16[IKE]  IKE_SA prn17-ikev2[2100] established 
between 192.168.142.17[gate.example.com]...192.168.142.13[prn17.red.example.de]
Jul 13 13:35:57 16[IKE]  scheduling reauthentication in 86135s
Jul 13 13:35:57 16[IKE]  maximum IKE_SA lifetime 86315s
Jul 13 13:35:57 16[IKE]  expected a virtual IP request, 
sending FAILED_CP_REQUIRED
Jul 13 13:35:57 16[IKE]  traffic selectors 0.0.0.0/0 === 
10.100.0.17/32 inacceptable
Jul 13 13:35:57 16[IKE]  failed to establish CHILD_SA, 
keeping IKE_SA
Jul 13 13:35:57 16[ENC]  generating IKE_AUTH response 1 [ IDr 
AUTH N(AUTH_LFT) N(FAIL_CP_REQ) N(TS_UNACCEPT) ]
Jul 13 13:35:57 16[NET]  sending packet: from 
192.168.142.17[4500] to 192.168.142.13[60908] (160 bytes)
:
:
Jul 13 13:36:27 29[IKE]  sending DPD request
Jul 13 13:36:27 29[ENC]  generating INFORMATIONAL request 0 [ 
]
Jul 13 13:36:27 29[NET]  sending packet: from 
192.168.142.17[4500] to 192.168.142.13[60908] (80 bytes)
Jul 13 13:36:27 14[NET]  received packet: from 
192.168.142.13[60908] to 192.168.142.17[4500] (80 bytes)
Jul 13 13:36:27 14[ENC]  parsed INFORMATIONAL response 0 [ ]
:


Please note the "expected a virtual IP request". Unfortunately the
printer does not provide any logging, AFAICT.


Every helpful comment is highly appreciated
Harri
-
ipsec.conf:

conn %default
# left=%any
left= gate.example.com
fragmentation   = yes
leftsubnet  = 172.16.96.0/19
leftfirewall= no
ikelifetime = 1d
lifetime= 8h
rekey   = yes
dpdaction   = none  # default: no dead peer detection
dpddelay= 30s   # default: 30s
dpdtimeout  = 150s  # default: 150s, used for IKEv1 only

#
# IKEv2 using RSA authentication
conn IPSec-IKEv2
keyexchange = ikev2
leftcert= gate.example.com_3.pem
also= roadwarrior
ike = 
aes256-sha256-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024!
esp = 
aes256-sha256-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024,aes256-sha256,aes256-sha1,aes128-sha1!
right   = %any
rightca = "C=DE, O=example, OU=Certificate Authority, 
CN=root-CA"
rightauth   = pubkey
rightsendcert   = ifasked
rightsourceip   = %dhcp
auto= add

#
# connection to prn17
conn prn17-ikev2
# left=%any
left= gate.example.com
leftid  = @gate.example.com
leftfirewall= no
right   = 5.145.142.13
rightid = @prn17.red.example.de
rightsourceip   = %dhcp
authby  = secret

keyexchange = ikev2
ike = 
aes256-sha256-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024!
esp = 

[strongSwan] syntax question about PSKs in ipsec.secrets (and Wiki)

[Harald Dunkel]

Hi folks,

https://wiki.strongswan.org/projects/strongswan/wiki/PskSecret shows several
examples for entries in ipsec.secrets with '@' at the begin of a FQDN. There
is no example for a PSK using FQDNs without '@'.

https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets does not
mention the '@' at the beginning of a FQDN at all. There is just a tiny hint
in the config manual (ipsec.conf) about using '@' to avoid a DNS lookup of
the leftid or rightid for strongswan < 5.0.

Which one is right? Is the '@' obsolete today? Apparently the PskSecret page
is pretty old.


Every helpful comment is highly appreciated
Harri

Re: [strongSwan] IPsec broken for iphone with ios11?

[Harald Dunkel]

On 03/29/18 18:23, Harald Dunkel wrote:
> Hi folks,
> 
> is it just me, or is IPsec broken for ios 11 (iphone)? I can establish
> an IPsec connection once, but if I reconnect then the routing appears
> to be broken. I cannot ping the DNServer on the remote net.
> 
> My ipad (ios 10) with a similar profile has no such problem.
> 
> Can anybody reproduce this?
> 

Using the new ios 11.3 or macos 10.13.4 the problem vanished.


Regards
Harri

Re: [strongSwan] IPsec broken for iphone with ios11?

[Harald Dunkel]

IPv4 or dual-stack?

> On Mar 29, 2018, at 19:07, Robert Leonard <rjlcontract...@gmail.com> wrote:
> 
> I am using IPsec w/ IKEv2 reliably on iOS 11.2.6
> 
>> On Thu, Mar 29, 2018 at 12:23 PM, Harald Dunkel <ha...@afaics.de> wrote:
>> Hi folks,
>> 
>> is it just me, or is IPsec broken for ios 11 (iphone)? I can establish
>> an IPsec connection once, but if I reconnect then the routing appears
>> to be broken. I cannot ping the DNServer on the remote net.
>> 
>> My ipad (ios 10) with a similar profile has no such problem.
>> 
>> Can anybody reproduce this?
>> 
>> 
>> Regards
>> Harri
> 
> 
> 
> -- 
> Rob Leonard
> RJL Contracting
> Cell:  (248) 214 7559
> E-Mail:  rjlcontract...@gmail.com

[strongSwan] IPsec broken for iphone with ios11?

[Harald Dunkel]

Hi folks,

is it just me, or is IPsec broken for ios 11 (iphone)? I can establish
an IPsec connection once, but if I reconnect then the routing appears
to be broken. I cannot ping the DNServer on the remote net.

My ipad (ios 10) with a similar profile has no such problem.

Can anybody reproduce this?


Regards
Harri

[strongSwan] Question about routing (maybe OT)

[Harald Dunkel]

Hi folks,

Question: If a roadwarrior running MacOS sets up a connection
via IPv4 to my strongswan server, then the Mac gets an additional
routing entry for my server, e.g.

192.168.1.209  10.100.0.1 UGHS00 en0

192.168.1.209 in this example is the IP address of my server.
10.100.0.1 is the default gateway in the road warriors local
network. Payload is IPv4 only. IKEv2.

Question is, who tells the Mac to setup this routing entry?
Is this initiated by Charon on my server somehow, or is this
Apple's code?

Point is, using IPv6 for ike and esp there is no such routing
entry on the Mac, even though the IPsec connection still might
affect IPv4 routing for 192.168.1.209.


Every helpful comment is highly appreciated
Regards
Harri

Re: [strongSwan] dhcp plugin using CN or FQDN as the client host name?

[Harald Dunkel]

On 03/06/18 10:42, Tobias Brunner wrote:

Hi Harald,


Question is, how can I tell charon's dhcp plugin to forward either
the FQDN or the CN from the DN entry in the dhcp request?


You can't, the plugin simply uses the client's (IKE or EAP) identity, so
it's up to the client to use the identity you want to see on the server.



OK, so how can I tell charon-nm?


You currently can't.



That hurts alot. Hope you don't mind that I created an
enhancement request for this:

https://wiki.strongswan.org/issues/2581


Regards
Harri

Re: [strongSwan] dhcp plugin using CN or FQDN as the client host name?

[Harald Dunkel]

On 03/06/18 10:32, Tobias Brunner wrote:

Hi Harald,


Question is, how can I tell charon's dhcp plugin to forward either
the FQDN or the CN from the DN entry in the dhcp request?


You can't, the plugin simply uses the client's (IKE or EAP) identity, so
it's up to the client to use the identity you want to see on the server.



OK, so how can I tell charon-nm?


Regards
Harri

[strongSwan] dhcp plugin using CN or FQDN as the client host name?

[Harald Dunkel]

Hi folks,

Setup: road warrior, strongswan 5.6.2 on both peers, the gateway
runs dnsmasq to manage an IP address pool and DNS.

Problem: charon-nm seems to forwards the DN from the certificate
as the identifier. Apparently charon on the peer seems to ignore
the FQDN from the certificate's DNS entry in this case, and the
dhcp plugin does not set a client host name in the DHCP request.

An iphone (with a client certificate created using the same
template) selects the DNS entry from the v3 extensions as the
identifier, charon on the peer accepts it and the dhcp plugin
sets the client host name accordingly.

Question is, how can I tell charon's dhcp plugin to forward either
the FQDN or the CN from the DN entry in the dhcp request?


Every helpful comment is highly appreciated
Harri

Re: [strongSwan] how to send/request the intermediate CAs?

[Harald Dunkel]

Hi Tobias,

On 02/23/18 14:25, Tobias Brunner wrote:
> Hi Harri,
> 
>> I had hoped that putting the whole chain into /etc/ipsec.d/certs/mycert.pem
>> would help, but apparently it doesn't.
> 
> strongSwan reads only the first certificate from PEM encoded files.  So
> put them in separate files.
> 

I have 2 additional question here (hope you don't mind):

Even if Strongswan ignores the additional certs, is it possible that
some crypto implementation *used* by Strongswan does not, but reads
all certificates found in the cert files (in /etc/ipsec.d)?

Does Strongswan send just the first certificates it has read to the
peer, or does it send the whole certificate file (the chain)?


Reason for asking is that I see some weird authentication failures if
I cut off the additional certificates from the chain files and put
them into seperate files.


Regards
Harri



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] how to send/request the intermediate CAs?

[Harald Dunkel]

Hi Tobias,

On 02/26/18 09:28, Tobias Brunner wrote:

Hi Harri,


I had hoped that putting the whole chain into /etc/ipsec.d/certs/mycert.pem
would help, but apparently it doesn't.


strongSwan reads only the first certificate from PEM encoded files.  So
put them in separate files.



This is unusual, is it?


What is?



AFAICT its unusual, that the other certificates a chain file
are ignored. In most cases they have been added on purpose,
e.g. to simplify the deployment of certificate files, it is the
regular output of openssl pkcs12 -cacerts ..., etc. IMHO its
unexpected, that they are silently ignored. But maybe I don't
see the downside of these chain files.


If I do, will charon send or request the whole chain?


Depends on the settings (send_certreq, send_cert in swanctl.conf,
left|rightsendcert in ipsec.conf).  With the default settings the client
will send certificate requests for all trusted CA certificates it has
loaded (root or intermediate), or if a CA is assigned in the config only
for that CA. 


Understood (hopefully). I would assume that if leftsendcert is set
to "always", then charon will push the certificates to the
peer without having received a request. But what about "never"?
How is authentication supposed to happen in this case? (Sorry for
asking, but its not documented in the Wiki, AFAICS.)


As responder, if any certificate requests are received (no
matter for what CA) the end entity certificate along with the
intermediate CA certificates will be sent to the client.



Thats the part I would like to see in charon's log file.
Some basic certificate info should show up, for each certificate,
as it is sent or received. Subject, issuers and KeyIDs should do.
Maybe the notBefore and notAfter entries as well, to spot
expired certificates.

I understand that this option might severely impact performance.
Surely not a default log setting.


I highly appreciate your work on Strongswan.

Regards
Harri

Re: [strongSwan] how to send/request the intermediate CAs?

[Harald Dunkel]

Hi Tobias,

On 02/23/18 14:25, Tobias Brunner wrote:
> Hi Harri,
> 
>> I had hoped that putting the whole chain into /etc/ipsec.d/certs/mycert.pem
>> would help, but apparently it doesn't.
> 
> strongSwan reads only the first certificate from PEM encoded files.  So
> put them in separate files.
> 

This is unusual, is it? If I do, will charon send or request the whole
chain?

IMHO certificate handling is a major pitfall, making IPsec configuration
hard to manage. This is surely not an issue with Strongswan alone.

I would suggest to improve logging here. asn = 1 doesn't list the subject
and authority key IDs, for example. asn = 2 overwhelms you with unwanted
details. Something inbetween would be nice.


Thanx for your help
Harri



signature.asc
Description: OpenPGP digital signature

[strongSwan] how to send/request the intermediate CAs?

[Harald Dunkel]

Hi folks,

Question: How can I tell charon to send or request intermediate
certificates to/from the peer?

Sample case would be a common root CA, one or two intermediate CAs,
and a client certificate for each peer. Both are using strongswan.

IMU charon has to trust the root CA to verify the whole chain up to
the client certs. The root cert has to go to /etc/ipsec.d/cacerts,
but the intermediate CAs could be provided by the peer. Are they?
They don't show up in the log file (asn = 2).

I had hoped that putting the whole chain into /etc/ipsec.d/certs/mycert.pem
would help, but apparently it doesn't.


Every insightful comment is highly appreciated.

Regards
Harri

[strongSwan] sending DHCP DISCOVER failed: Operation not permitted

[Harald Dunkel]

Hi folks,

I would like to run dnsmasq on the strongswan server to
manage an address pool (providing dhcp and dns). dhcp.conf:

dhcp {
force_server_address = yes
identity_lease = yes
interface = lo
load = yes
server = 127.0.0.1
}

Problem: In phase 2 the dhcp request runs into a timeout:

:
Feb 20 12:47:33 12[IKE]  peer requested virtual IP %any
Feb 20 12:47:33 12[CFG]  sending DHCP DISCOVER to 127.0.0.1
Feb 20 12:47:34 12[CFG]  sending DHCP DISCOVER to 127.0.0.1
Feb 20 12:47:36 12[CFG]  sending DHCP DISCOVER to 127.0.0.1
Feb 20 12:47:39 12[CFG]  sending DHCP DISCOVER to 127.0.0.1
Feb 20 12:47:43 12[CFG]  sending DHCP DISCOVER to 127.0.0.1
Feb 20 12:47:48 12[CFG]  DHCP DISCOVER timed out
:

dnsmasq conf says:

Feb 20 12:47:33 dnsmasq-dhcp[10706]: no address range available for DHCP 
request via 192.168.1.209
Feb 20 12:47:34 dnsmasq-dhcp[10706]: no address range available for DHCP 
request via 192.168.1.209
Feb 20 12:47:36 dnsmasq-dhcp[10706]: no address range available for DHCP 
request via 192.168.1.209
Feb 20 12:47:39 dnsmasq-dhcp[10706]: no address range available for DHCP 
request via 192.168.1.209
Feb 20 12:47:43 dnsmasq-dhcp[10706]: no address range available for DHCP 
request via 192.168.1.209

192.168.1.209 is bound to the eth0 interface, i.e. the
connection to the peer. Obviously the "interface = lo" was
ignored. I get the same problem using a local bridge instead of
lo, or if I drop the "interface = lo" line. Using eth0 is off
limits.

How can I tell the dhcp plugin to use the right interface?


Strongswan is version 5.6.1 (still).

Every helpful comment is highly appreciated.
Harri

Re: [strongSwan] question about rightca

[Harald Dunkel]

Hi Noel,

On Tue, 5 Sep 2017 15:34:40 +0200
Noel Kuntze  wrote:

> Hi,
> 
> No, that is not the default. Any authenticatable certificate with a matching 
> ID to it is accepted (Unless it's revoked via CRLs or OCSP).
> In your case, just set leftca to the DN of your root CA certificate, and 
> rightca to that, too or to %same.
> 

I got that from the documentation. I would like to make %same 
work without specifying any DN in ipsec.conf. Specifying the 
leftcert for a connection should be sufficient for Strongswan 
to find the root certificate and its DN.

I am still hoping that this approach is reasonable.


Regards
Harri

Re: [strongSwan] question about rightca

[Harald Dunkel]

On Tue, 5 Sep 2017 13:33:59 +0200
Noel Kuntze  wrote:

> Hi,
> 
> > a matching root CA by default  
> 
> What do you mean with that? charon always authenticates the certificates. You 
> can't turn that off.
> 


I don't want to turn that off. AFAIU left and right side can use 
independent certificate chains for authorization. I want to make
sure that left and right side are based upon the same root certificate.
Is this the default?


Regards
Harri

[strongSwan] question about rightca

[Harald Dunkel]

Hi folks,

the documentation says for left|rightca:

%same means that the value configured for the other participant 
should be reused.


Please note the "configured". How can I tell charon to do require
a matching root CA by default, without explicitly configuring the 
peer's CA?


I am not sure if this approach would be reasonable. Is it? Every 
helpful comment is highly appreciated

Harri

Re: [strongSwan] "auto = try_again_later" on DNS problems?

[Harald Dunkel]

On Tue, 18 Jul 2017 16:00:07 +0200
Harald Dunkel <harald.dun...@aixigo.de> wrote:

> Hi Tobias,
> 
> On Fri, 14 Jul 2017 13:59:05 +0200
> Tobias Brunner <tob...@strongswan.org> wrote:
> 
> > Hi Harald,
> >   
> > > I tried both "auto = start"
> > 
> > You could set charon.retry_initiate_interval, then initiation will be
> > tried again if the DNS resolution failed.
> >   
> 
> Sorry, my bad. I had expected some connection specific config
> option, so I didn't look at the global options.
> 

PS: I am not sure if charon.retry_initiate_interval = 0 is a 
reasonable default. What are the odds that a local network admin
expects Strongswan to give up early in case of a DNS failure?

Maybe something like 300 would be a better choice? 


Just a suggestion, of course. Regards
Harri

Re: [strongSwan] "auto = try_again_later" on DNS problems?

[Harald Dunkel]

Hi Tobias,

On Fri, 14 Jul 2017 13:59:05 +0200
Tobias Brunner  wrote:

> Hi Harald,
> 
> > I tried both "auto = start"  
> 
> You could set charon.retry_initiate_interval, then initiation will be
> tried again if the DNS resolution failed.
> 

Sorry, my bad. I had expected some connection specific config
option, so I didn't look at the global options.

> > and "auto = route".  
> 
> I pushed a change to the child-sa-rekeying branch that addresses this.
> Unless %dynamic is used in the remote traffic selector (the default if
> rightsubnet is not set) no remote address is needed when the trap policy
> is installed during startup of the daemon.  However, later the remote
> address has obviously to be known to actually establish the SAs (if the
> remote is not resolvable, the option above could again be enabled, but
> with trap policies new acquires will be triggered anyway later when
> traffic matches).
> 

Thats very interesting. I will try. 


Thanx very much
Harri

[strongSwan] "auto = try_again_later" on DNS problems?

[Harald Dunkel]

Hi folks,

sometimes starting charon fails with "Temporary failure 
in name resolution", e.g.

Jul 10 19:58:50 00[DMN] Starting IKE charon daemon (strongSwan 5.5.3, Linux 
4.11.9-raw, x86_64)
Jul 10 19:58:50 00[CFG] PKCS11 module '' lacks library path
Jul 10 19:58:50 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jul 10 19:58:50 00[CFG]   loaded ca certificate "C=DE, O=example AG, OU=example 
Certificate Authority, CN=example Root CA" from 
'/etc/ipsec.d/cacerts/root-ca.pem'
Jul 10 19:58:50 00[CFG]   loaded ca certificate "C=DE, O=example AG, OU=example 
Certificate Authority, CN=ws-example-CA" from 
'/etc/ipsec.d/cacerts/ws-example-CA-public.root-ca.pem'
Jul 10 19:58:50 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jul 10 19:58:50 00[CFG] loading ocsp signer certificates from 
'/etc/ipsec.d/ocspcerts'
Jul 10 19:58:50 00[CFG] loading attribute certificates from 
'/etc/ipsec.d/acerts'
Jul 10 19:58:50 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jul 10 19:58:50 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jul 10 19:58:50 00[CFG]   loaded RSA private key from 
'/etc/ipsec.d/private/local.sample.de.key.pem'
Jul 10 19:58:50 00[LIB] loaded plugins: charon test-vectors ldap pkcs11 aesni 
aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 
pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp 
curve25519 agent xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve 
socket-default connmark stroke vici updown
Jul 10 19:58:50 00[LIB] dropped capabilities, running as uid 0, gid 0
Jul 10 19:58:50 00[JOB] spawning 16 worker threads
Jul 10 19:58:50 05[CFG] received stroke: add connection 'sample-example'
Jul 10 19:58:50 17[LIB] resolving 'gate.example.com' failed: Temporary failure 
in name resolution
Jul 10 19:58:50 05[CFG]   loaded certificate "C=DE, O=sample.de, 
CN=local.sample.de, E=j...@sample.de" from 'local.sample.de.cert.pem'
Jul 10 19:58:50 05[CFG] added configuration 'sample-example'
Jul 10 19:58:50 06[CFG] received stroke: route 'sample-example'
Jul 10 19:58:50 17[LIB] resolving 'gate.example.com' failed: Temporary failure 
in name resolution
Jul 10 19:58:50 06[CFG] installing trap failed, remote address unknown

I tried both "auto = start" and "auto = route". Of course I can add 
the missing DNS entry to /etc/hosts, but I wonder if there some 
smart trick to tell charon to try again later?


Regards
Harri

[strongSwan] farp problem

[Harald Dunkel]

Hi folks,

Consider a road warrior setup (>20 peers online). Strongswan 5.5.3 on
Debian 8. The right addresses are grabbed via dhcp, farp is supposed
to answer the arp requests.

Problem is, sometimes farp ignores the arp requests for one (or more?)
IP address bound to a child SA.

I saw this on my IPsec gateway, for example:


# ipsec statusall
:
 IPSec-IKEv2[2772]: ESTABLISHED 85 minutes ago, 
2001:db8:13b0:::63[gate.example.com]...2001:db8:30:fff0:ed29:6621:7cf8:6387[ppcm005.example.de]
 IPSec-IKEv2[2772]: IKEv2 SPIs: b6cf4a195efbe943_i 90855da73ac9b14c_r*, public 
key reauthentication in 22 hours
 IPSec-IKEv2[2772]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 IPSec-IKEv2{4107}:  INSTALLED, TUNNEL, reqid 2323, ESP SPIs: c68adec6_i 
0bf997dc_o
 IPSec-IKEv2{4107}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 741797 bytes_i 
(5250 pkts, 0s ago), 1479117 bytes_o (1653 pkts, 1666s ago), rekeying in 21 
minutes
 IPSec-IKEv2{4107}:   x.xxx.142.192/26 10.47.11.0/24 yy.yy.169.96/27 
10.19.96.0/19 10.22.111.0/24 10.23.15.0/24 zzz.zz.32.0/27 === 10.19.97.55/32
:

The IP address bound to the peer is 10.19.97.55 in this case. tcpdump
shows the incoming arp request, but they are not answered:


# tcpdump -i eth1 -env arp and host 10.19.97.55
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 
bytes
15:12:17.654382 00:16:5a:xx:ce:a9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.124, length 46
15:12:17.785501 00:20:8c:xx:51:83 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.11, length 46
15:12:18.805539 00:20:8c:xx:51:83 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.11, length 46
15:12:19.869832 00:1e:67:xx:9b:a9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.98.253, length 46
15:12:20.677828 00:1e:67:xx:9b:a9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.98.253, length 46
15:12:20.826525 00:20:8c:xx:51:83 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.11, length 46
15:12:21.676258 00:1e:67:xx:9b:a9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.98.253, length 46
15:12:21.845542 00:20:8c:xx:51:83 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.11, length 46
15:12:22.869629 00:20:8c:xx:51:83 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.11, length 46
15:12:23.611081 00:16:5a:xx:ce:a9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.124, length 46
15:12:24.610385 00:16:5a:xx:ce:a9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.19.97.55 tell 
10.19.96.124, length 46
^C
11 packets captured
12 packets received by filter
0 packets dropped by kernel

Farp answers the arp requests for the other road warrior IP addresses
(not shown here). "arp" on the gateway shows "incomplete" for all road
warrior IP addresses.

The problem in this example came up after more than 70 minutes uptime
of the IPsec connection to this peer (AFAIK). The peer is a Mac.


By now I haven't found a way to reproduce this problem, but it will
come back. Has any body seen something similar?


Every helpful hint would be highly appreciated.
Harri

[strongSwan] log file question

[Harald Dunkel]

Hi folks,

What is the exact meaning of these fancy strings like "07[NET]",
"26[ENC]" etc. in the logfile? They seem to be related to 
charondebug, but are they? What does the number tell me? Some 
kind of "context id"?


I haven't found it in the wiki, but maybe I was too blind to
see. Every helpful comment is highly appreciated.

Harri

[strongSwan] how to watch farp at work?

[Harald Dunkel]

Hi folks,

Is there a config option for strongswan to watch farp at
work? I had the impression that sometimes it forgets
a client.

Long story:

Consider a road warrior setup. The IPsec gateway to the
company network has a direct connection to the internet
via IPv4 and IPv6. No NAT. It runs strongswan 5.5.3 on
Debian 8. dhcp and farp are in place.

The IPsec peer (MacOS) runs in a natted network, provided
by an OpenBSD gateway/firewall.

Sometimes, when the Mac wakes up from hibernate, it seems
to have lost its IPsec connection, even though the GUI
says "connected". Both involved gateways still have a
valid IKE SA, child SA and NAT table entry.

A ping from the Mac to (lets say) our internal DNS server
comes through, but tcpdump on the DNS server shows it
doesn't send an echo reply back. IMU this means that the
host couldn't match the echo reply's destination IP address
to the mac address of the IPsec gateway. farp is bad, is
it?

Unfortunately the Mac gave up and created a new IPsec
connection, so I couldn't examine the arp table or watch
the arp traffic on the DNS host.

The problem is hard to reproduce. And usually there are 20+
road warriors online in parallel.

Obviously I am not finished with examining the problem,
but every helpful advice is highly appreciated.

Harri

[strongSwan] charon-nm (5.5.3): building CRED_PRIVATE_KEY - RSA failed, tried 10 builders

[Harald Dunkel]

Hi folks,

charon-nm seems to reject a key, but its error message doesn't
appear to be very useful:

Jun 05 11:42:13 ppcl001 charon-nm[6609]: 05[LIB] building CRED_PRIVATE_KEY - 
RSA failed, tried 10 builders
Jun 05 11:42:13 ppcl001 charon-nm[6609]: 05[CFG] received initiate for 
NetworkManager connection IKEv2
Jun 05 11:42:13 ppcl001 charon-nm[6609]: 05[CFG] using CA certificate, gateway 
identity 'gate.example.com'
Jun 05 11:42:13 ppcl001 charon-nm[6609]: 05[LIB] building CRED_PRIVATE_KEY - 
RSA failed, tried 10 builders

To make it work I could assign another passphrase to the key

openssl rsa -in oldkey.pem -aes256 -out newkey.pem

The question is, though, why the oldkey.pem didn't work? Was it
encrypted using a deprecated cipher? Bad passphrase?

I have to make sure that the passphrase wasn't corrupted by the
Network Manager integration. What would you suggest?


Regards
Harri

Re: [strongSwan] sending DHCP RELEASE failed: No buffer space available

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/03/16 15:35, Thomas Egerer wrote:
> Moinsen Harald,
> 
> On 12/03/2016 02:52 PM, Harald Dunkel wrote:
>> Hi folks,
> 
>> charon mentions a few lines in syslog every day saying
> 
>> sending DHCP RELEASE failed: No buffer space available
> This error message originates from src/libcharon/plugins/dhcp/dhcp_socket.c 
> It's generated after a sendto failed. Judging from sendto(2):  ENOBUFS 
> The  output queue for a network interface was full.  This generally indicates 
> that the interface has stopped sending, but may be caused by
> transient congestion. (Normally, this does  not occur in Linux.  Packets are 
> just silently dropped when a device queue overflows.)  You have a 
> problem sending your packets. Try netstat (netstat -planou) and check the 
> Send-Q.
> 

netstat -planou shows that the send-q is at 0 *every time* I
looked, even when some DHCP traffic was about to be sent.
Whats the size of a DHCP release, anyway? 342 bytes. How
comes it doesn't run out of buffer space on other much larger
packages to send?


Every helpful hint is highly appreciated.

Harri


-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAliHFK4ACgkQCp4qnmbT
gcveXwf+N5c3NGdtApB/gW9gPXJMuuWnCj+jH77ZVWSi7qOfNo3a0TpvsffGyaDB
E6Si+wPFfyCX6Ad9bdBV9OrzhHlkFr0gNz6g0c9CCeegNEJeLxw4oy3i9NSNK1Gm
h5IljCjSXFZy++lolyoVJvFbdcbm+5/9ReR3zAejwtmdzO9IoaJHQwvg/SSqW+xB
ZDbkyzIy+FtM+v93th4ZPg51LGCqmjbiLU+S9mrqbur8466j0y6W6dLWdt6J7oj2
e+u8+5r8vdkTXwhVU05bSYcQ01KB0x9isq/n6W34Xbf2vkAv7IQiXMuZiNV8W/5j
yNjLZeJtKTNGzJ2C7k/K1ov+sUOxcA==
=93fz
-END PGP SIGNATURE-
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] MacOS setting up new IKE_SA instead of using the old (IKEv2)

[Harald Dunkel]

Hi folks,

I have quite a number of MacOS 10.11 and 10.12 road warriors.
The common IPsec gateway is a Linux PC with strongswan 5.5.1.
IKEv2.

The problem is that some Macs loose the IPsec connection while
it is in use. The road warrior is working in an ssh session over
IPsec to another system in our left subnet, for example. He
has to stop typing and to manually click on [connect] in his
network GUI to make it work again. Sometimes the IPsec
connection is lost just a few minutes after creating it.

Looking at the gateway's logfile I see that the Mac creates a
new IKE_SA instead of using the old one. There is no DELETE
message or expired SA or anything.

Logfile is attached, but here is a grep to show what I mean:

% cat /var/log/daemon.log | grep charon | egrep IKE_SA\|CHILD_SA | grep ppcm009
Dec 13 15:28:13 srvl047 charon: 17[IKE] IKE_SA IPSec-IKEv2[7503] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 15:29:57 srvl047 charon: 13[IKE] deleting IKE_SA IPSec-IKEv2[7503] 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 15:30:24 srvl047 charon: 27[IKE] IKE_SA IPSec-IKEv2[7508] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:02:18 srvl047 charon: 18[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:02:18 srvl047 charon: 18[IKE] IKE_SA IPSec-IKEv2[7518] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:07:10 srvl047 charon: 16[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:07:10 srvl047 charon: 16[IKE] IKE_SA IPSec-IKEv2[7521] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:13:54 srvl047 charon: 18[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:13:54 srvl047 charon: 18[IKE] IKE_SA IPSec-IKEv2[7524] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:16:28 srvl047 charon: 09[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:16:28 srvl047 charon: 09[IKE] IKE_SA IPSec-IKEv2[7527] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:30:20 srvl047 charon: 25[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:30:20 srvl047 charon: 25[IKE] IKE_SA IPSec-IKEv2[7532] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:37:37 srvl047 charon: 19[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:37:37 srvl047 charon: 19[IKE] IKE_SA IPSec-IKEv2[7533] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:38:23 srvl047 charon: 05[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:38:23 srvl047 charon: 05[IKE] IKE_SA IPSec-IKEv2[7535] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]
Dec 13 16:53:59 srvl047 charon: 08[IKE] destroying duplicate IKE_SA for peer 
'ppcm009.ws.example.de', received INITIAL_CONTACT
Dec 13 16:53:59 srvl047 charon: 08[IKE] IKE_SA IPSec-IKEv2[7545] established 
between 
2001:db8:13b0:::63[gate1.example.com]...2001:db8:30:fff0:ae87:a3ff:fe30:d869[ppcm009.ws.example.de]


Has anybody seen something similar? Every helpful comment
is highly appreciated.


Harri
Dec 13 16:16:28 srvl047 charon: 17[NET] received packet: from 2001:db8:30:fff0:ae87:a3ff:fe30:d869[500] to 2001:db8:13b0:::63[500] (432 bytes)
Dec 13 16:16:28 srvl047 charon: 17[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Dec 13 16:16:28 srvl047 charon: 17[IKE] 2001:db8:30:fff0:ae87:a3ff:fe30:d869 is initiating an IKE_SA
Dec 13 16:16:28 srvl047 charon: 17[IKE] sending cert request for "C=DE, O=example AG, OU=example Certificate Authority, CN=example Root CA"
Dec 13 16:16:28 srvl047 charon: 17[IKE] sending cert request for "C=DE, ST=NRW, L=Aachen, O=example AG, OU=TI, CN=IPsec_ca, E=secur...@example.de"
Dec 13 16:16:28 srvl047 charon: 17[IKE] sending cert request for "C=DE, O=example AG, OU=example Certificate Authority, CN=ws-example-CA"
Dec 13 16:16:28 srvl047 charon: 17[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) V ]
Dec 13 16:16:28 srvl047 

Re: [strongSwan] received MS_NOTIFY_STATUS notify error

[Harald Dunkel]

PS: Its Windows 10, sorry.

Harri

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

[strongSwan] received MS_NOTIFY_STATUS notify error

[Harald Dunkel]

Hi folks,

I get these messages in the log file on my gateway:

:
Aug 10 08:56:49 srvl047 charon: 22[IKE] establishing CHILD_SA IPSec-IKEv2{271}
Aug 10 08:56:49 srvl047 charon: 22[ENC] generating CREATE_CHILD_SA request 190 
[ N(REKEY_SA) SA No KE TSi TSr ]
Aug 10 08:56:49 srvl047 charon: 22[NET] sending packet: from 2001:db8::63[4500] 
to 2001:db8::fff0:947:2f4f:e0cd:1844[4500] (780 bytes)
Aug 10 08:56:49 srvl047 charon: 11[NET] received packet: from 
2001:db8::fff0:947:2f4f:e0cd:1844[4500] to 2001:db8::63[4500] (76 bytes)
Aug 10 08:56:49 srvl047 charon: 11[ENC] parsed CREATE_CHILD_SA response 190 [ 
N(MS_STATUS(13816)) ]
Aug 10 08:56:49 srvl047 charon: 11[IKE] received MS_NOTIFY_STATUS notify error
Aug 10 08:56:49 srvl047 charon: 11[IKE] CHILD_SA rekeying failed, trying again 
in 9 seconds
Aug 10 08:56:50 srvl047 charon: 09[IKE] establishing CHILD_SA IPSec-IKEv2{271}
Aug 10 08:56:50 srvl047 charon: 09[ENC] generating CREATE_CHILD_SA request 191 
[ N(REKEY_SA) SA No KE TSi TSr ]
Aug 10 08:56:50 srvl047 charon: 09[NET] sending packet: from 2001:db8::63[4500] 
to 2001:db8::fff0:947:2f4f:e0cd:1844[4500] (780 bytes)
Aug 10 08:56:50 srvl047 charon: 26[NET] received packet: from 
2001:db8::fff0:947:2f4f:e0cd:1844[4500] to 2001:db8::63[4500] (76 bytes)
Aug 10 08:56:50 srvl047 charon: 26[ENC] parsed CREATE_CHILD_SA response 191 [ 
N(MS_STATUS(13816)) ]
Aug 10 08:56:50 srvl047 charon: 26[IKE] received MS_NOTIFY_STATUS notify error
Aug 10 08:56:50 srvl047 charon: 26[IKE] CHILD_SA rekeying failed, trying again 
in 9 seconds
Aug 10 08:56:58 srvl047 charon: 18[IKE] establishing CHILD_SA IPSec-IKEv2{271}
Aug 10 08:56:58 srvl047 charon: 18[ENC] generating CREATE_CHILD_SA request 192 
[ N(REKEY_SA) SA No KE TSi TSr ]
Aug 10 08:56:58 srvl047 charon: 18[NET] sending packet: from 2001:db8::63[4500] 
to 2001:db8::fff0:947:2f4f:e0cd:1844[4500] (780 bytes)
Aug 10 08:56:58 srvl047 charon: 27[NET] received packet: from 
2001:db8::fff0:947:2f4f:e0cd:1844[4500] to 2001:db8::63[4500] (76 bytes)
Aug 10 08:56:58 srvl047 charon: 27[ENC] parsed CREATE_CHILD_SA response 192 [ 
N(MS_STATUS(13816)) ]
Aug 10 08:56:58 srvl047 charon: 27[IKE] received MS_NOTIFY_STATUS notify error
Aug 10 08:56:58 srvl047 charon: 27[IKE] CHILD_SA rekeying failed, trying again 
in 15 seconds
Aug 10 08:56:59 srvl047 charon: 16[IKE] establishing CHILD_SA IPSec-IKEv2{271}
Aug 10 08:56:59 srvl047 charon: 16[ENC] generating CREATE_CHILD_SA request 193 
[ N(REKEY_SA) SA No KE TSi TSr ]
Aug 10 08:56:59 srvl047 charon: 16[NET] sending packet: from 2001:db8::63[4500] 
to 2001:db8::fff0:947:2f4f:e0cd:1844[4500] (780 bytes)
Aug 10 08:56:59 srvl047 charon: 13[NET] received packet: from 
2001:db8::fff0:947:2f4f:e0cd:1844[4500] to 2001:db8::63[4500] (76 bytes)
Aug 10 08:56:59 srvl047 charon: 13[ENC] parsed CREATE_CHILD_SA response 193 [ 
N(MS_STATUS(13816)) ]
Aug 10 08:56:59 srvl047 charon: 13[IKE] received MS_NOTIFY_STATUS notify error
Aug 10 08:56:59 srvl047 charon: 13[IKE] CHILD_SA rekeying failed, trying again 
in 13 seconds
:

The peer is running Windows 7. Of course I saw 
https://wiki.strongswan.org/projects/strongswan/wiki/Windows7.
The point here are the time stamps and the "trying again in" messages:
Doesn't it look like there are 2 rekeyeing jobs running in parallel
for the same peer?


Every helpful comment is highly appreciated
Harri
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] using 500/tcp

[Harald Dunkel]

Hi Tobias,

On 07/21/16 11:24, Tobias Brunner wrote:
> Hi Harald,
> 
>> AFAIU defragmentation is enabled in strongswan for incoming packages,
>> anyway.
> 
> That's basically for IKEv1 where the first message may already be
> fragmented and for misbehaving peers that send fragmented packets even
> if it wasn't enabled explicitly.  It does not mean that the notify to
> enable fragmentation is actually sent.  That's only the case if
> `fragmentation` is enabled.
> 

If the package to send is too large, what choice does a peer
initiating the connection have?

> 
> Interestingly, the capture does not show any retransmits and only one
> IKE_AUTH request on the second try (the last small message).  Since that
> message has still the same size I guess the IKE daemon did not adjust
> the fragment size but that the messages were just fragmented on the IP
> layer.  Anyway, it shows responses by strongSwan, so the messages
> apparently came through.  It also shows that strongSwan correctly
> fragments its response to a maximum size of 1280 for the complete IP
> packet (the 8 byte difference to that theoretical maximum is due to the
> 16-byte blocksize):
> 

Now I see. The "fragmentation" option is about fragmentation on
IKEv2 level.

> 
> So I guess you could also just start the connection, then manually
> disconnect (about when you are sure the IKE_AUTH requests were sent) and
> then connect again.
> 

Sure. But since this is understood now I have configured a higher
MTU for the IPv6 tunnel on sixxs.net, as described on their web pages.
Its not deeply verified yet, but the delay for IKEv2 over the IPv6
tunnel is gone.

Of course I had created a bug report on https://bugreport.apple.com/ .


Thanx very much
Harri

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

Re: [strongSwan] using 500/tcp

[Harald Dunkel]

Hi Tobias,

On 07/20/16 17:03, Tobias Brunner wrote:
> Hi Harald,
> 
> As you noticed the IKE_AUTH packet is the one that's problematic.  But
> since Mac OS X supports IKEv2 fragmentation
> 
>> Notify (IKEv2 Fragmentation Supported) Payload:
>> No Data
> 
> there is really no reason not to enable it (unless you use an old
> strongSwan version that does not support it yet).
> 

AFAIU defragmentation is enabled in strongswan for incoming packages,
anyway. I have enabled fragmentation explicitly yesterday (Stronswan 5.5.0).
Unfortunately it didn't help. MacOS does fragment the package, using an MTU
of 1500. My IPv6 tunnel supports 1280 only. Apparently IKEv2 on MacOS
ignores the icmp6 "package too big" pointing to the path MTU of 1280 bytes.

tcpdump:

19:56:21.292979 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), 
length 494: (flowlabel 0xc48b1, hlim 64, next-header UDP (17) payload length: 
440) 2001:db8:0:1:c1a8:d747:f5f0:d411.500 > 2001:db8:0:2::63.500: [udp sum ok] 
isakmp 2.0 msgid : parent_sa ikev2_init[I]:
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=prf id=#5 )
(t: #3 type=integ id=#12 )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=16 
data=(147c7063b0f6df32a2ed...5d770b5d54400a6763c60e230008402e))
(n: prot_id=#0 type=16406(status))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
19:56:21.350933 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), 
length 595: (flowlabel 0xc5feb, hlim 54, next-header UDP (17) payload length: 
541) 2001:db8:0:2::63.500 > 2001:db8:0:1:c1a8:d747:f5f0:d411.500: [udp sum ok] 
isakmp 2.0 msgid : parent_sa ikev2_init[R]:
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=#12 )
(t: #3 type=prf id=#5 )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=32 
data=(62d400bb1e01b7821568...0014882fe56d6fd20dbc2251613b2ebe5beb))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(v2cr: len=61)
(n: prot_id=#0 type=16430(status))
(n: prot_id=#0 type=16404(status))
(v2vid: len=16 vid=./.mo..."Qa;..[.)
19:56:21.450731 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), 
length 1318: (flowlabel 0x6067d, hlim 64, next-header UDP (17) payload length: 
1264) 2001:db8:0:1:c1a8:d747:f5f0:d411.4500 > 2001:db8:0:2::63.4500: [udp sum 
ok] NONESP-encap: isakmp 2.0 msgid 0001: child_sa  ikev2_auth[I]:
(#53) [|v2IDi]
19:56:21.450799 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), 
length 1318: (flowlabel 0x6067d, hlim 255, next-header UDP (17) payload length: 
1264) 2001:db8:0:1:c1a8:d747:f5f0:d411.4500 > 2001:db8:0:2::63.4500: [udp sum 
ok] NONESP-encap: isakmp 2.0 msgid 0001: child_sa  ikev2_auth[I]:
(#53)
19:56:21.450858 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), 
length 198: (flowlabel 0x6067d, hlim 255, next-header UDP (17) payload length: 
144) 2001:db8:0:1:c1a8:d747:f5f0:d411.4500 > 2001:db8:0:2::63.4500: [udp sum 
ok] NONESP-encap: isakmp 2.0 msgid 0001: child_sa  ikev2_auth[I]:
(#53)
19:56:21.452772 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), 
length 1294: (hlim 64, next-header ICMPv6 (58) payload length: 1240) 
2001:db8:0:1::2 > 2001:db8:0:1:c1a8:d747:f5f0:d411: [icmp6 sum ok] ICMP6, 
packet too big, mtu 1280
19:56:21.452775 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), 
length 1294: (hlim 64, next-header ICMPv6 (58) payload length: 1240) 
2001:db8:0:1::2 > 2001:db8:0:1:c1a8:d747:f5f0:d411: [icmp6 sum ok] ICMP6, 
packet too big, mtu 1280
19:56:40.108295 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), 
length 494: (flowlabel 0x1f858, hlim 64, next-header UDP (17) payload length: 
440) 2001:db8:0:1:c1a8:d747:f5f0:d411.500 > 2001:db8:0:2::63.500: [udp sum ok] 
isakmp 2.0 msgid : parent_sa ikev2_init[I]:
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=prf id=#5 )
(t: #3 type=integ id=#12 )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=16 
data=(cad5dbc58dc400cca047...77aa80e0a5adad9503cbb20d0008402e))
(n: prot_id=#0 type=16406(status))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
19:56:40.167134 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), 
length 595: (flowlabel 0xc5feb, 

Re: [strongSwan] using 500/tcp

[Harald Dunkel]

PS: Here is the tcpdump:

:
09:38:32.605298 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), 
length 1510: (flowlabel 0xe21e2, hlim 64, next-header Fragment (44) payload 
length: 1456) 2001:db8:0:1:3dfa:f382:2017:d7f7 > 2001:db8:0:2::63: frag 
(0xd1710203:0|1448) 4500 > 4500
09:38:32.605305 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), 
length 1090: (flowlabel 0xe21e2, hlim 64, next-header Fragment (44) payload 
length: 1036) 2001:db8:0:1:3dfa:f382:2017:d7f7 > 2001:db8:0:2::63: frag 
(0xd1710203:1448|1028)
09:38:32.607411 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), 
length 1294: (hlim 64, next-header ICMPv6 (58) payload length: 1240) 
2001:db8:0:1::2 > 2001:db8:0:1:3dfa:f382:2017:d7f7: [icmp6 sum ok] ICMP6, 
packet too big, mtu 1280
09:38:32.700898 84:1b:5e:49:b9:64 > 01:80:c2:00:00:00, 802.3, length 52: LLC, 
dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, 
Config, Flags [none], bridge-id 8000.84:1b:5e:49:b9:65.8003, length 35
:

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

[strongSwan] using 500/tcp

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi folks,

I am using IPv6 over IPv4 at home (via sixxs.net). No NAT.

Problem: The mtu of this tunnel is less than 1500. On the
first run IKEv2 on my Mac fails with icmp6 "Packet Too Big".
Since the protocol is udp there is no packet to fragment and
resend, which means a 10 seconds delay until a higher network
layer wakes up and tries to authenticate again. Then it works.

Looking at this I wonder if it is reasonable to ignore 500/tcp
for Strongswan?

Of course I saw https://wiki.strongswan.org/issues/830, but
IMHO the fragment feature in strongsan doesn't really help in
this case. The "Packet Too Big" is returned by the IPv6 tunnel.
Strongswan on the peer did not see any incoming packet to
defragment yet.


Every helpful comment is highly appreciated
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXipnrAAoJEAqeKp5m04HLRXYIAJat8BC7XiQPY4jhCbL0oc3p
JN8w7vJE1s5JvtHN49RqwJUqjdd28F1AIXbxznlJI73WoAkY3UIXmw3jfOsIBO9v
F0vp0dvNblgpLzu4JtTvWYZK/R8m7ox5hyV+82Qq53bx5T6XZUx46iUnBaZ18utD
DUuL5d38rSSAQ55zev6/JVXFRJPWCyCBX2TPISHlKbEyrffTPe6YJ1TGaRi1jmj1
BRxSnX7PuQDba1iq3N79AD5LZ1vpUFRHiSO9GNaaz+1okiAFfGldW8XXvslK2nRw
9Zq17fkW4lUgT/54NskAGNK2muWAyh6wly0aPHhZ5p68gC/oZpT1t3qnOB3P/hE=
=S4lC
-END PGP SIGNATURE-
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] dhcp plugin: migration from IKEv1 to IKEv2 breaks dhcp leases

[Harald Dunkel]

Hi folks,

if I migrate the road warriors from IKEv1 to IKEv2, then
they get new mac addresses (using identity_lease = yes in
dhcp.conf). This breaks their dhcp lease, and we have to
register the new mac addresses in the dhcp server
configuration for mac-based access control.

Each road warrior has kept his certificate and his ID
(AFAICT), so I wonder if missed some magic to keep the
computed MAC address stable?


Every helpful comment is highly appreciated.

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

Re: [strongSwan] firewall issue?

[Harald Dunkel]

Hi Noel,

On 07/05/16 14:12, Noel Kuntze wrote:
> That is what is happening. IPsec packets are processed as soon as the SAs and 
> SPs are inserted into the SAD and SPD, but
> the updown script takes some time to execute. Obviously the firewall rules 
> are inserted too late.
> 

I am glad that we agree on that.

> The only solution for you is to write your own firewall rule that allows the 
> IPsec protected IP packets from a roadwarrior IP to
> any other subnet. The SPs narrow down the allowed traffic further to what was 
> negotiated.
> 

Maybe I am too blind to see, but I haven't found this in
the wiki. This is the code I added to the forward chain:

iptables -A FORWARD -s ${right_lan} -d ${left_lan}  -i eth0 -m policy --dir in  
--pol ipsec --proto esp -j ACCEPT
iptables -A FORWARD -s ${left_lan}  -d ${right_lan} -o eth0 -m policy --dir out 
--pol ipsec --proto esp -j ACCEPT

Default policy is drop, of course. The leftsubnet lines in
ipsec.conf are set to "no".


Thanx for your help
Harri

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

Re: [strongSwan] firewall issue?

[Harald Dunkel]

Hi folks,

I would highly appreciate some feedback about this. Is it
unreasonable to expect that the IPsec payload should not be
affected by the slow updown script?

All the road warrior Macs and Iphones do VPN-on-demand.
Currently the IPsec connection succeeds, but the DNS lookup
(the "demand" in this case) fails. You might imagine that
this affects a lot of tools (calendar lookup, EMail, etc.)
From the user's point of view this is the difference between
"works" and "doesn't work".


Thanx very much
Harri

On 07/04/16 09:33, Harald Dunkel wrote:
> PS: I found out a little bit more. If there is a new connection
> initiated by a road warrior, then /var/log/messages shows me
> 
> Jul  4 08:55:03 srvl047 kernel: [73014.164939] iptables-dropped: IN=eth0 
> OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
> DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=23018 PROTO=UDP 
> SPT=50374 DPT=53 LEN=47
> Jul  4 08:55:03 srvl047 kernel: [73014.164948] iptables-dropped: IN=eth0 
> OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
> DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=21954 PROTO=UDP 
> SPT=62524 DPT=53 LEN=47
> Jul  4 08:55:03 srvl047 kernel: [73014.165334] iptables-dropped: IN=eth0 
> OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
> DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=383 PROTO=UDP 
> SPT=64310 DPT=53 LEN=46
> Jul  4 08:55:03 srvl047 kernel: [73014.165340] iptables-dropped: IN=eth0 
> OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
> DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=41664 PROTO=UDP 
> SPT=50876 DPT=53 LEN=46
> Jul  4 08:55:03 srvl047 vpn: + C=DE, O=example AG, OU=TI, 
> CN=ppcm026.ws.example.com 172.19.97.87/32 == 5.145.142.13 -- 5.145.142.17 == 
> 172.19.96.0/19
> 
> I know that the sequence in the log file might not match the
> actual sequence of events, but I wonder if there could be a
> race condition?
> 
> Is there some way to introduce an artificial "new connection
> delay" for the very first packages to give the firewall some
> time to come up?
> 
> https://wiki.strongswan.org/projects/strongswan/wiki/Updown
> suggests to introduce global iptable entries instead of
> setting leftfirewall=yes. Both source and destination address
> in the "iptables-dropped" lines are valid on eth1 (the
> internal side) only. I wouldn't like to support global
> forward rules between eth0 and eth1. Maybe there is a way to
> introduce a virtual network device to be used exclusively for
> the VPN payload, instead of eth0?
> 
> 
> Every helpful comment is highly appreciated. Regards
> 
> Harri
> 

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

Re: [strongSwan] firewall issue?

[Harald Dunkel]

Hi Dennis,

On 07/04/16 12:53, Dennis Jacobfeuerborn wrote:
> 
> I'm not sure what your objection is to creating the same rules
> permanently (which the page seems to call "global") that the updown
> script create dynamically anyway?
> 

The concern is to open a potential door for an intruder.

The default _updown script creates very "picky" rules,
giving just a single IP address on eth0 access to eth1.
Sample:

:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination
 4723  548K ACCEPT all  --  eth0   *   172.19.97.60 
172.19.96.0/19   policy match dir in pol ipsec reqid 275 proto 50
 9880   11M ACCEPT all  --  *  eth0172.19.96.0/19   
172.19.97.60 policy match dir out pol ipsec reqid 275 proto 50
:

I wouldn't like to replace the single IP address on eth0
by large subnets without need.

The problem is that eth0 has been reused for the decoded
traffic. The iptables entries about eth0 affect both
the connection to the internet as well as the connection
to the road warriors. If we want to let the road warriors
in but keep the rest of the internet out, then we end up
with separate iptables entries for each road warrior.

If there would be a dedicated network interface xyz0
for decoded traffic without connection to eth0, then the
iptables entries for the connection to the road warriors'
laptops could be kept separate from the internet connection.
We could open 172.19.97.0/24 on xyz0 without opening this
network on eth0.


Regards
Harri

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

Re: [strongSwan] firewall issue?

[Harald Dunkel]

PS: I found out a little bit more. If there is a new connection
initiated by a road warrior, then /var/log/messages shows me

Jul  4 08:55:03 srvl047 kernel: [73014.164939] iptables-dropped: IN=eth0 
OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=23018 PROTO=UDP 
SPT=50374 DPT=53 LEN=47
Jul  4 08:55:03 srvl047 kernel: [73014.164948] iptables-dropped: IN=eth0 
OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=21954 PROTO=UDP 
SPT=62524 DPT=53 LEN=47
Jul  4 08:55:03 srvl047 kernel: [73014.165334] iptables-dropped: IN=eth0 
OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=383 PROTO=UDP SPT=64310 
DPT=53 LEN=46
Jul  4 08:55:03 srvl047 kernel: [73014.165340] iptables-dropped: IN=eth0 
OUT=eth1 MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.87 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=41664 PROTO=UDP 
SPT=50876 DPT=53 LEN=46
Jul  4 08:55:03 srvl047 vpn: + C=DE, O=example AG, OU=TI, 
CN=ppcm026.ws.example.com 172.19.97.87/32 == 5.145.142.13 -- 5.145.142.17 == 
172.19.96.0/19

I know that the sequence in the log file might not match the
actual sequence of events, but I wonder if there could be a
race condition?

Is there some way to introduce an artificial "new connection
delay" for the very first packages to give the firewall some
time to come up?

https://wiki.strongswan.org/projects/strongswan/wiki/Updown
suggests to introduce global iptable entries instead of
setting leftfirewall=yes. Both source and destination address
in the "iptables-dropped" lines are valid on eth1 (the
internal side) only. I wouldn't like to support global
forward rules between eth0 and eth1. Maybe there is a way to
introduce a virtual network device to be used exclusively for
the VPN payload, instead of eth0?


Every helpful comment is highly appreciated. Regards

Harri

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

[strongSwan] default for "inactivity" config option?

[Harald Dunkel]

Hi folks,

what is the default for the inactivity config option?
https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
doesn't tell.


Thanx in advance
Harri
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] firewall issue?

[Harald Dunkel]

Hi folks,

environment:
IPsec gateway/firewall, Debian 8
strongswan 5.4.0
kernel 4.5.4-1~bpo8+1
about 30 road warriors (OS X, iphones)
IKEv1, IPv4 only, NAT at both sides

problem:

I see a number of DNS queries via IPsec blocked at the
internal firewall each day (apparently on the incoming
side eth0 pointing to the internet). Most of the queries
are not blocked, though.

Within the last month the percentage of blocked DNS
queries became worse. Much worse. Users started
complaining.

Sample:
:
Jul  1 14:56:55 gate1 kernel: [11376.265578] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.62 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=8365 PROTO=UDP SPT=53772 
DPT=53 LEN=46
Jul  1 14:56:55 gate1 kernel: [11376.265606] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.62 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=9010 PROTO=UDP SPT=59360 
DPT=53 LEN=46
Jul  1 15:04:21 gate1 kernel: [11822.343540] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.64 
DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=3336 PROTO=UDP SPT=65510 
DPT=53 LEN=47
Jul  1 15:04:21 gate1 kernel: [11822.343549] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.64 
DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=16828 PROTO=UDP 
SPT=65055 DPT=53 LEN=47
Jul  1 15:04:21 gate1 kernel: [11822.343933] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.64 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=41728 PROTO=UDP 
SPT=49163 DPT=53 LEN=46
Jul  1 15:04:21 gate1 kernel: [11822.343939] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.64 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=3549 PROTO=UDP SPT=54079 
DPT=53 LEN=46
Jul  1 15:04:21 gate1 kernel: [11822.393433] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.66 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=64135 PROTO=UDP 
SPT=64653 DPT=53 LEN=46
Jul  1 15:04:21 gate1 kernel: [11822.393448] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.66 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=4824 PROTO=UDP SPT=60342 
DPT=53 LEN=46
Jul  1 15:04:21 gate1 kernel: [11822.393455] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.66 
DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=27700 PROTO=UDP 
SPT=54769 DPT=53 LEN=47
Jul  1 15:04:21 gate1 kernel: [11822.393461] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.66 
DST=172.19.96.123 LEN=67 TOS=0x00 PREC=0x00 TTL=254 ID=17238 PROTO=UDP 
SPT=51462 DPT=53 LEN=47
Jul  1 15:04:25 gate1 kernel: [11825.955926] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.59 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=48167 PROTO=UDP 
SPT=55059 DPT=53 LEN=46
Jul  1 15:04:25 gate1 kernel: [11825.955939] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.59 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=22942 PROTO=UDP 
SPT=59174 DPT=53 LEN=46
Jul  1 15:04:25 gate1 kernel: [11826.071637] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.60 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=26638 PROTO=UDP 
SPT=50563 DPT=53 LEN=46
Jul  1 15:04:25 gate1 kernel: [11826.071651] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.60 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=41367 PROTO=UDP 
SPT=62579 DPT=53 LEN=46
Jul  1 15:04:25 gate1 kernel: [11826.071944] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.60 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=39892 PROTO=UDP 
SPT=61569 DPT=53 LEN=46
Jul  1 15:04:25 gate1 kernel: [11826.072200] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.60 
DST=172.19.96.123 LEN=66 TOS=0x00 PREC=0x00 TTL=254 ID=6242 PROTO=UDP SPT=59746 
DPT=53 LEN=46
Jul  1 15:06:07 gate1 kernel: [11927.933124] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.69 
DST=172.19.96.123 LEN=79 TOS=0x00 PREC=0x00 TTL=254 ID=25119 PROTO=UDP 
SPT=57108 DPT=53 LEN=59
Jul  1 15:06:07 gate1 kernel: [11927.933179] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 SRC=172.19.97.69 
DST=172.19.96.123 LEN=79 TOS=0x00 PREC=0x00 TTL=254 ID=12174 PROTO=UDP 
SPT=51598 DPT=53 LEN=59
Jul  1 15:06:07 gate1 kernel: [11927.933422] iptables-dropped: IN=eth0 OUT=eth1 
MAC=80:ee:73:a2:e6:17:00:00:5e:00:01:3d:08:00 

[strongSwan] "Cisco unity extensions" vs IKEv2

[Harald Dunkel]

Hi folks,

https://wiki.strongswan.org/projects/strongswan/wiki/Attrplugin
lists a few "Cisco Unity extensions for IKEv1". Apparently they
are sent to the peer for IKEv2 as well (as a log file written
on MacOS shows). Is this on purpose? A typo on the wiki page?


Every clarification is highly appreciated
Harri
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] dhcp plugin: how to verify dhcp options forwarded to road warrior?

[Harald Dunkel]

On 04/11/16 16:24, Harald Dunkel wrote:
> Hi folks,
> 
> Using IKEv2 to connect to MacOS 10.11.4:
> 

PS: Sorry, this was misleading. Its a road warrior scenario
between a few MacOS laptops and a central strongswan
installation using IKEv2. The connections are initiated
only by the laptops. Strongswan uses the dhcp plugin to
obtain an IP address and DNS information.

> It seems that either the received DHCP options are not forwarded
> to the MacOS client, or the MacOS client ignores these options.
> Charon's log file entries show the DHCP discover and the received
> IP address and netmask, but it doesn't show which options are
> sent to the road warrior, and if this information is accepted
> or rejected.
> 
> How can I verify? There are plenty of DNS related options in
> strongswan 5.3.4. Which options do I *really* have to set to
> make at least full DNS over IPsec work with MacOS?
> 
> 
> Every helpful comment is highly appreciated.
> Harri

Sorry for the confusion

Harri

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

Re: [strongSwan] MacOS: IKEv1 fails after wakeup

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

PS: After enabling debug logging in racoon and a reboot the problem
went away. I will keep debugging enabled, of course.


Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW6ZGyAAoJEAqeKp5m04HLpuUIAJAKHoBY+g7yNIIjWUoTqWFW
eRy8lzsx3/maWaV4N5foD194WLVJeB2sH/aq3Jx5e945DafJy0HwjDsxT5kHszog
z3stVwOCu1VHffQg09p2Oriv3KseHkPzW4fLP3w4WtQ4akT8ikOrt31xaPqej+4u
sVCtEKR+FNgZGrZQSKJK56FeYApy3+qvxvwTiXv0gVSajVxieeD8fCD/1fBU+48w
N7Gfy/53J79uybQKtnrM2hWITS6Mmcp6M1N9aCyv1sYlYm4lLihEfW8J7i9PXZuZ
DXFNmYwW+e6ldE61svUyruov7S6OAIuuElVn7+QKaOUeoEhbBv9HEzc3EHIyA7Y=
=Is7z
-END PGP SIGNATURE-
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MacOS: IKEv1 fails after wakeup

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Tobias,


On 03/15/16 12:13, Tobias Brunner wrote:
> Hi Harald,
> 
>> I have no idea why the Mac opens a new session now, instead of relying upon 
>> the old IKE_SA, but it seems to me that the Mac missed to send xauth info. 
>> Is this correct?
> 
> Yes, looks that way.  Which is strange because while in the previous 
> reconnection attempt the client did not request a virtual IP it did at least 
> respond to the XAuth request.  Here it apparently does neither before sending 
> a Quick Mode request.  Maybe it's a reauthentication. This was a
> problem with (older) iOS versions, which lead to the development of the 
> xauth-noauth plugin [1].

I have one suspect here: The previous session was done in the office
in a WLAN setup with an airport extreme. I don't have such a device at
home. From what I can tell these airports act very strange wrt other
apple devices that went to sleep.

> Try checking the client log.
> 

Good idea:

Mar 12 11:55:17 ppcm018 racoon[6849]: > phase change status = Phase 1 
started by peer
Mar 12 11:55:17 ppcm018 racoon[6849]: IKE Packet: receive success. (Initiator, 
Main-Mode message 2).
Mar 12 11:55:17 ppcm018 racoon[6849]: IKE Packet: transmit success. (Initiator, 
Main-Mode message 3).
Mar 12 11:55:17 ppcm018 racoon[6849]: IKE Packet: receive success. (Initiator, 
Main-Mode message 4).
Mar 12 11:55:17 ppcm018 racoon[6849]: IKE Packet: transmit success. (Initiator, 
Main-Mode message 5).
Mar 12 11:55:17 ppcm018 racoon[6849]: mode config 6 from 10.0.0.17[4500], but 
ISAKMP-SA 0c6de9a361463a33:612f076cd8c70cd6 isn't established.
Mar 12 11:55:17 ppcm018 racoon[6849]: preexisting CERT payload... chaining.
Mar 12 11:55:17 ppcm018 racoon[6849]: IKEv1 Phase 1 AUTH: success. (Initiator, 
Main-Mode Message 6).
Mar 12 11:55:17 ppcm018 racoon[6849]: IKE Packet: receive success. (Initiator, 
Main-Mode message 6).
Mar 12 11:55:17 ppcm018 racoon[6849]: IKEv1 Phase 1 Initiator: success. 
(Initiator, Main-Mode).
Mar 12 11:55:17 ppcm018 racoon[6849]: IPSec Phase 1 established (Initiated by 
me).
Mar 12 11:55:17 ppcm018 racoon[6849]: IPSec Phase 2 started (Initiated by me).
Mar 12 11:55:17 ppcm018 racoon[6849]: > phase change status = Phase 2 
started
Mar 12 11:55:17 ppcm018 racoon[6849]: IKE Packet: transmit success. (Initiator, 
Quick-Mode message 1).
Mar 12 11:55:19 ppcm018 racoon[6849]: failed to begin ipsec sa negotiation.
Mar 12 11:55:21 ppcm018 racoon[6849]: IKE Packet: transmit success. (Phase 2 
Retransmit).
Mar 12 11:55:22 ppcm018 racoon[6849]: failed to begin ipsec sa negotiation.
Mar 12 11:55:24 ppcm018 racoon[6849]: IKE Packet: transmit success. (Phase 2 
Retransmit).
Mar 12 11:55:26 ppcm018 racoon[6849]: failed to begin ipsec sa negotiation.
Mar 12 11:55:27 ppcm018 racoon[6849]: IKE Packet: transmit success. (Phase 2 
Retransmit).
Mar 12 11:55:29 ppcm018 racoon[6849]: failed to begin ipsec sa negotiation.
Mar 12 11:55:30 ppcm018 racoon[6849]: IKE Packet: transmit success. (Phase 2 
Retransmit).
Mar 12 11:55:34 ppcm018 racoon[6849]: IKE Packet: transmit success. (Phase 2 
Retransmit).
Mar 12 11:55:35 ppcm018 racoon[6849]: failed to begin ipsec sa negotiation.
Mar 12 11:55:37 ppcm018 racoon[6849]: IKE Packet: transmit success. (Phase 2 
Retransmit).
Mar 12 11:55:40 ppcm018 racoon[6849]: failed to begin ipsec sa negotiation.
Mar 12 11:55:43 ppcm018 racoon[6849]: IKE Packet: transmit success. (Phase 2 
Retransmit).
Mar 12 11:55:47 ppcm018 racoon[6849]: IPSec disconnecting from server 10.0.0.17
Mar 12 11:55:47 ppcm018 racoon[6849]: IKE Packet: transmit success. 
(Information message).
Mar 12 11:55:47 ppcm018 racoon[6849]: IKEv1 Information-Notice: transmit 
success. (Delete ISAKMP-SA).
Mar 12 11:55:47 ppcm018 racoon[6849]: IPSec disconnecting from server 10.0.0.17
Mar 12 11:55:47 ppcm018 racoon[6849]: glob found no matches for path 
"/var/run/racoon/*.conf"
Mar 12 11:55:49 ppcm018 racoon[6849]: Internal error - attempt to re-send Phase 
2 with no Phase 1 bound.


Obviously the protocol diverged at 11:55:19 (macbook time).

Do you think it would be reasonable to contact somebody at Apple directly?
I tried the recommended procedure (post in the apple forums) once, but this
was a frustrating experience.


Regards
Harri

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW6X4jAAoJEAqeKp5m04HLmQ4IAJBGrjMxEDb194S5I+pVMYIa
e8fSSNZCnhzcCuvpWUfbQBAjp3hd0e9wZFepYqR7DeAXghdl+9iuKMPQDBkj1Wvm
hK79fNV1Uv+1n37HvsJtQ0jHcAQgZSaW4pAgxnKyRBLLUWVPkqHUOM8M4pTCbhnF
82cscga7a2jXI21NfDaB+f+F5LkM3UN0CA5Mlabob/7izbUiIAIY6TmxbNuSm1US
YjxNkoWkD4PA9GRiUgmQ928zrlSJnkGtfO7KiI+ggeRx2pYc8ks/0GETEXaZnWGL
hWj9ygMNI1bFREgr057jE7Mr9hSkKijpcsT15C8k20kuH+pTYsbKg3DufeYalOs=
=12HR
-END PGP SIGNATURE-
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MacOS: IKEv1 fails after wakeup

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/16/16 18:02, Harald Dunkel wrote:
> PS: After enabling debug logging in racoon and a reboot the problem went 
> away. I will keep debugging enabled, of course.
> 

PPS: After my IP provider changed the external IP address over
night it was broken again.

I am not sure that we are on the right track here. Since NAT on
the right side is under control of others (IP provider, short
timeouts on an unknown DSL gateway, port number conflicts between
the hosts in the remote lan) this cannot be a stable solution.

What about the modecfg exchange the Mac doesn't do on a
reconnect? I understand that modecfg is not standardized, but on
the other hand it was invented by Cisco (AFAIK), and Apple calls
its IKEv1 support "Cisco IPsec". ???

I wonder what Apple thinks about how the reconnect is supposed
to work.


Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW6kYVAAoJEAqeKp5m04HLjgQH/0jI2MSeeGGvRFE64HsY0S90
VA5+txbMYcicvImZORNSCmoAmAXgiwV8dt+8i7UfJzzj3puDHiKGqUCMq86sXvii
FgQgmFuJmVNCVNUlfcCBA7ljNKFoYZSgVCIGtEvpC8RbNlHiA1ySzgRs8aFt7xsF
zsgK0doVV9NnTNtGLWZEAnfUCex+PM2o4WjCC/CRpwQ9btdK1Y05fZGGfVI5hm3T
rHdv8eELU2fhimloXxpcHgxcYfhXdh+Bkk6LC+XLqd2y2d13ersRb0RWRBBNRNSa
hZf336CCxXGVQvlFLNG1/6hMtJDSA2v1gzGr/soze2kRZr37Vwq6z+kiElL6UPU=
=TDHo
-END PGP SIGNATURE-
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MacOS: IKEv1 fails after wakeup

[Harald Dunkel]

Hi Tobias,

On 03/11/16 10:03, Tobias Brunner wrote:
> 
> One potential issue I hadn't considered so far is that while the client
> is asleep the mapping on the NAT router might time out (it probably does
> not send keepalives while asleep).  So when it reconnects it will do so
> from different source ports from the server's point of view.  Due to
> that the reauthentication detection will not recognize the new SA as
> reauthentication attempt and therefore not migrate the previous virtual
> IP.  So you'd end up in the same situation as before (i.e. the traffic
> selectors don't match and the CHILD_SA can't be established).  Try to
> compare the client's source ports to see if that's what happens here.
> 

I managed to configure my gateway at home to keep the mapped port number
(UDP) for 24h. This is the code for OpenBSD 5.8 packet filter:

:
pass in  quick on intern proto udp from (intern:network) to  port isakmp 
 tag RED_INET_IPSEC keep state (if-bound, max 256, udp.multiple 86400)
pass in  quick on intern proto udp from (intern:network) to  port 
ipsec-nat-t tag RED_INET_IPSEC keep state (if-bound, max 256, udp.multiple 
86400)
pass out quick on egress tagged RED_INET_IPSEC
:

Maybe 24h is not reasonable, but at least this fixes the lost
UDP port number for now.

Problem is: Now it fails on the left side with "received quick mode
request for unestablished IKE_SA, ignored" (see the attached logfile).

:
Mar 12 11:55:12 srvl047 charon: 26[IKE] authentication of 'gate1.example.com' 
(myself) successful
Mar 12 11:55:12 srvl047 charon: 26[IKE] queueing XAUTH task
Mar 12 11:55:12 srvl047 charon: 26[IKE] sending end entity cert "C=DE, ST=NRW, 
L=Aachen, O=example AG, CN=gate1.example.com/emailAddress=secur...@example.com"
Mar 12 11:55:12 srvl047 charon: 26[IKE] sending issuer cert "C=DE, O=example 
AG, OU=example Certificate Authority, CN=ws-example-CA"
Mar 12 11:55:12 srvl047 charon: 26[ENC] generating ID_PROT response 0 [ ID CERT 
CERT SIG ]
Mar 12 11:55:12 srvl047 charon: 26[NET] sending packet: from 10.0.0.17[4500] to 
192.168.0.17[60361] (3708 bytes)
Mar 12 11:55:12 srvl047 charon: 26[IKE] activating new tasks
Mar 12 11:55:12 srvl047 charon: 26[IKE]   activating XAUTH task
Mar 12 11:55:12 srvl047 charon: 03[NET] sending packet: from 10.0.0.17[4500] to 
192.168.0.17[60361]
Mar 12 11:55:12 srvl047 charon: 26[IKE] Hash => 20 bytes @ 0x7f3e1c0069b0
Mar 12 11:55:12 srvl047 charon: 26[IKE]0: 41 2B 58 8B BA C5 FD 1D B2 8F CC 
78 F0 83 D9 39  A+Xx...9
Mar 12 11:55:12 srvl047 charon: 26[IKE]   16: 16 01 44 94   
   ..D.
Mar 12 11:55:12 srvl047 charon: 26[ENC] generating TRANSACTION request 34192379 
[ HASH CPRQ(X_USER X_PWD) ]
Mar 12 11:55:12 srvl047 charon: 26[NET] sending packet: from 10.0.0.17[4500] to 
192.168.0.17[60361] (76 bytes)
Mar 12 11:55:12 srvl047 charon: 03[NET] sending packet: from 10.0.0.17[4500] to 
192.168.0.17[60361]
Mar 12 11:55:13 srvl047 charon: 02[NET] received packet: from 
192.168.0.17[60361] to 10.0.0.17[4500]
Mar 12 11:55:13 srvl047 charon: 02[NET] waiting for data on sockets
Mar 12 11:55:13 srvl047 charon: 20[NET] received packet: from 
192.168.0.17[60361] to 10.0.0.17[4500] (300 bytes)
Mar 12 11:55:13 srvl047 charon: 20[ENC] parsed QUICK_MODE request 3495102926 [ 
HASH SA No ID ID ]
Mar 12 11:55:13 srvl047 charon: 20[IKE] Hash(1) => 20 bytes @ 0x7f3e34010fb0
Mar 12 11:55:13 srvl047 charon: 20[IKE]0: 49 7A 47 EE F1 2F B4 F7 D2 8A 1D 
BB DC 8B CC 9F  IzG../..
Mar 12 11:55:13 srvl047 charon: 20[IKE]   16: C0 D9 32 69   
   ..2i
Mar 12 11:55:13 srvl047 charon: 20[IKE] received quick mode request for 
unestablished IKE_SA, ignored
Mar 12 11:55:13 srvl047 charon: 20[IKE] IKE_SA CiscoIPSec[178] state change: 
CONNECTING => DESTROYING

I have no idea why the Mac opens a new session now, instead of relying
upon the old IKE_SA, but it seems to me that the Mac missed to send
xauth info. Is this correct?


Every helpful suggestion is highly welcome
Regards
Harri

Mar 12 11:20:37 srvl047 charon: 02[NET] received packet: from 
192.168.0.17[53195] to 10.0.0.17[500]
Mar 12 11:20:37 srvl047 charon: 02[NET] waiting for data on sockets
Mar 12 11:20:37 srvl047 charon: 20[NET] received packet: from 
192.168.0.17[53195] to 10.0.0.17[500] (668 bytes)
Mar 12 11:20:37 srvl047 charon: 20[ENC] parsed ID_PROT request 0 [ SA V V V V V 
V V V V V V V V V ]
Mar 12 11:20:37 srvl047 charon: 20[CFG] looking for an ike config for 
10.0.0.17...192.168.0.17
Mar 12 11:20:37 srvl047 charon: 20[CFG] ike config match: 0 (10.0.0.17 
192.168.0.17 IKEv1)
Mar 12 11:20:37 srvl047 charon: 20[CFG] ike config match: 0 (10.0.0.17 
192.168.0.17 IKEv1)
Mar 12 11:20:37 srvl047 charon: 20[CFG] ike config match: 1052 (10.0.0.17 
192.168.0.17 IKEv1)
Mar 12 11:20:37 srvl047 charon: 20[CFG]   candidate: gate1.example.com...%any, 
prio 1052
Mar 12 11:20:37 srvl047 charon: 20[CFG] ike config match: 1052 (10.0.0.17 
192.168.0.17 IKEv1)
Mar 12 11:20:37 

Re: [strongSwan] MacOS: IKEv1 fails after wakeup

[Harald Dunkel]

Hi Tobias,

On 03/11/2016 10:03 AM, Tobias Brunner wrote:
> 
> Just as a side note, you might want to adjust your logger/syslog
> settings to avoid the duplicate log messages.
> 
This is debug mode. Usually I have

charondebug="dmn 1, mgr 1, ike 1, chd 1, cfg 1, net 1"

Which setting would you recommend for this problem?

>> How comes that destroying the IKE_SA works, even though strongswan
>> on the left side has lost the IKE_SA (following your description)?
> 
> The client deletes the new SA (id 65) that it failed to establish, not
> the old one.  The log does only show the reconnection attempt so it's
> not clear whether the old SA was still there or not.  You configured
> dpdtimeout=500s, so how long was the client away? 

That was clearly more than 500s. The log file shows:

Mar 11 07:02:50 srvl047 charon: 21[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:50 srvl047 charon: 26[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:50 srvl047 charon: 26[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:50 srvl047 charon: 05[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:50 srvl047 charon: 05[IKE] IKE_SA CiscoIPSec[62] established 
between 10.0.0.17[gate1.example.com]...10.0.0.13[C=DE, O=example AG, OU=TI, 
CN=ppcm018.ws.example.com]
Mar 11 07:02:50 srvl047 charon: 05[IKE] IKE_SA CiscoIPSec[62] state change: 
CONNECTING => ESTABLISHED
Mar 11 07:02:50 srvl047 charon: 05[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:50 srvl047 charon: 28[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:50 srvl047 charon: 28[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:50 srvl047 charon: 30[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:50 srvl047 charon: 30[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:50 srvl047 charon: 09[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:50 srvl047 charon: 09[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:50 srvl047 charon: 08[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:50 srvl047 charon: 08[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:54 srvl047 charon: 24[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:54 srvl047 charon: 24[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:54 srvl047 charon: 23[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:54 srvl047 charon: 23[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:02:54 srvl047 charon: 29[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:02:54 srvl047 charon: 29[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:03:20 srvl047 charon: 24[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:03:20 srvl047 charon: 24[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:04:30 srvl047 charon: 17[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:04:30 srvl047 charon: 17[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:06:09 srvl047 charon: 21[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:06:09 srvl047 charon: 21[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:06:38 srvl047 charon: 07[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:06:38 srvl047 charon: 07[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:08:18 srvl047 charon: 16[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:08:18 srvl047 charon: 16[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:09:58 srvl047 charon: 06[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:09:58 srvl047 charon: 06[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:11:38 srvl047 charon: 23[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:11:38 srvl047 charon: 23[MGR] checkin IKE_SA CiscoIPSec[62]
Mar 11 07:13:18 srvl047 charon: 05[MGR] IKE_SA CiscoIPSec[62] successfully 
checked out
Mar 11 07:13:18 srvl047 charon: 05[MGR] checkin and destroy IKE_SA 
CiscoIPSec[62]
Mar 11 07:13:18 srvl047 charon: 05[IKE] IKE_SA CiscoIPSec[62] state change: 
ESTABLISHED => DESTROYING

> And do you see the
> DPDs and the deletion of the previous SA in the log?
> 

The DPD notifications are shown too.

Mar 11 07:06:39 srvl047 ipsec[11514]: 07[ENC] generating INFORMATIONAL_V1 
request 565589809 [ HASH N(DPD) ]
Mar 11 07:06:39 srvl047 ipsec[11514]: 07[NET] sending packet: from 
10.0.0.17[4500] to 10.0.0.13[64402] (92 bytes)

BTW, currently I have set dpdaction = none. It still fails to reconnect.

> One potential issue I hadn't considered so far is that while the client
> is asleep the mapping on the NAT router might time out (it probably does
> not send keepalives while asleep).  So when it reconnects it will do so
> from different source ports from the server's point of view.  Due to
> that the reauthentication detection will not recognize the new SA as
> reauthentication attempt and therefore not migrate the previous virtual
> IP.  So you'd end up in the same situation as before (i.e. the traffic
> selectors don't match and the CHILD_SA can't be established).  Try to
> compare the client's source ports to see 

Re: [strongSwan] MacOS: IKEv1 fails after wakeup

[Harald Dunkel]

Hi Tobias,

your tips were very helpful. Using

dpdaction   = clear
dpdtimeout  = 1500s
dpddelay= 300s

the "no response to retransmit" messages are gone. The users
can access their desktop immediately and do not have to wait.
Very big improvement.

However, MacOS still shows me a popup saying

VPN connection
An unexpected error occured. 

on wakeup, as before. The VPN connection appears to be gone.

I still have to examine the log file for this.


Thanx very much for your help
Harri

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

[strongSwan] MacOS: IKEv1 fails after wakeup

[Harald Dunkel]

Hi folks,

left side is strongswan 5.3.5 on Debian, right side is a
road warrior macbook running MacOS 10.11.3. There is a
NAT gateway & firewall on both sides.

If the IPsec connection is activated and the mac is put to
sleep, then strongswan drops the connection after some
minutes. Problem: When the mac is woken up again, then quite
often IKEv1 seems to fail. After entering the screen lock
password the road warrior has to wait for a minute, then
he is authenticated using cached information. The mac shows
an error popup with "connection failed". The road warrior
has to explicitly click on [connect example IPsec] to get a
new connection.

Log file is attached. Please note that there are several
messages "received retransmit of request with ID 2615585018,
but no response to retransmit" near the end, before the mac
gives up. Google told me that this happened before, but it
was supposed to be fixed with strongswan 5.3.

Every helpful comment is highly appreciated
Harri
config setup
charondebug="dmn 2, mgr 2, ike 3, chd 2, cfg 3, net 2"

conn %default
left= gate1.example.com
leftcert= gate1.example.com.pem
leftsendcert= always
leftsubnet  = 172.19.96.0/19
leftfirewall= yes
ikelifetime = 3h
lifetime= 1h
rekey   = yes
dpdaction   = hold
dpddelay= 30s
#
# IKEv2 using RSA authentication
conn IPSec-IKEv2
keyexchange = ikev2
ike = 
aes256-sha256-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024!
esp = 
aes256-sha256-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024,aes256-sha256,aes256-sha1,aes128-sha1!
right   = %any
rightauth   = pubkey
rightsendcert   = ifasked
rightsourceip   = %dhcp
# fragmentation = yes
auto= add

#
# IKEv1 using xauth (i.e. enter password)
conn CiscoIPSec
keyexchange = ikev1
ike = aes256-sha1-modp1536!
esp = aes256-sha1!
rightauth   = pubkey
right   = %any
rightsourceip   = %dhcp
rightauth2  = xauth
auto= add
Mar  7 07:37:36 srvl047 ipsec[30549]: 18[CFG]  624: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
Mar  7 07:37:36 srvl047 ipsec[30549]: 18[CFG]  640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
Mar  7 07:37:36 srvl047 ipsec[30549]: 18[CFG]  656: 00 00..
Mar  7 07:37:41 srvl047 charon: 11[MGR] checkout IKE_SA
Mar  7 07:37:46 srvl047 charon: 02[NET] received packet: from 10.0.0.13[59979] to 10.0.0.17[4500]
Mar  7 07:37:46 srvl047 charon: 02[NET] waiting for data on sockets
Mar  7 07:37:46 srvl047 charon: 06[MGR] checkout IKE_SA by message
Mar  7 07:37:46 srvl047 charon: 06[MGR] created IKE_SA (unnamed)[9]
Mar  7 07:37:46 srvl047 charon: 06[NET] received packet: from 10.0.0.13[59979] to 10.0.0.17[4500] (668 bytes)
Mar  7 07:37:46 srvl047 charon: 06[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V V V ]
Mar  7 07:37:46 srvl047 charon: 06[CFG] looking for an ike config for 10.0.0.17...10.0.0.13
Mar  7 07:37:46 srvl047 charon: 06[CFG] ike config match: 0 (10.0.0.17 10.0.0.13 IKEv1)
Mar  7 07:37:46 srvl047 charon: 06[CFG] ike config match: 0 (10.0.0.17 10.0.0.13 IKEv1)
Mar  7 07:37:46 srvl047 charon: 06[CFG] ike config match: 1052 (10.0.0.17 10.0.0.13 IKEv1)
Mar  7 07:37:46 srvl047 charon: 06[CFG]   candidate: gate1.example.com...%any, prio 1052
Mar  7 07:37:46 srvl047 charon: 06[CFG] ike config match: 1052 (10.0.0.17 10.0.0.13 IKEv1)
Mar  7 07:37:46 srvl047 charon: 06[CFG]   candidate: gate1.example.com...%any, prio 1052
Mar  7 07:37:46 srvl047 charon: 06[CFG] ike config match: 0 (10.0.0.17 10.0.0.13 IKEv1)
Mar  7 07:37:46 srvl047 charon: 06[CFG] found matching ike config: gate1.example.com...%any with prio 1052
Mar  7 07:37:46 srvl047 charon: 06[IKE] received NAT-T (RFC 3947) vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received XAuth vendor ID
Mar  7 07:37:46 srvl047 charon: 06[IKE] received Cisco Unity vendor ID
Mar 

Re: [strongSwan] seeking advice: pfs on creating a child_sa?

[Harald Dunkel]

Hi John,

On 03/01/2016 12:55 PM, John Brown wrote:
> Hi,
>  
>  I can give you two links with some small amount information about your 
> question:
> 
> http://www.juniper.net/documentation/en_US/junos12.1x46/topics/concept/vpn-security-phase-2-ipsec-proposal-understanding.html
> 
> and
> 
> https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations#Perfect-Forward-Secrecy-PFS
> 

I saw the wiki article before, of course. Point is that some
implementations don't support PFS for phase 2, including the
iphones (at least for IKEv1), Windows(7?, 10?) and even
charon-nm. Since I made PFS optional for phase 2 in our road
warrior setup on the server a lot of "broken connection after
an hour or so" problems went away.

AFAIU PFS provides a means to create a symmetric key on both
peers without exchanging anything secret over a (possibly
unprotected or compromised) communication line. I am not sure
if this is an issue for phase 2. Is it?


Regards
Harri

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

[strongSwan] how to configure the ciphers for charon-nm?

[Harald Dunkel]

Hi folks,

I wonder how I can define the default ciphers for charon-nm?
The network-manager GUI doesn't support setting ciphers, so I
had hoped charon-nm could read /etc/ipsec.conf?


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

[strongSwan] seeking advice: pfs on creating a child_sa?

[Harald Dunkel]

Hi folks,

looking for some advice: Would you suggest to use pfs for esp?
Apparently pfs is a must-have to establish an ike_sa today, but
is this reasonable for the child_sas as well?

Every helpful comment is highly appreciated
Harri
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] domain search list for IKEv2?

[Harald Dunkel]

Hi folks,

what is the recommended procedure/option to forward a domain search
list to the peer using IKEv2?

I found the attr plugin

https://wiki.strongswan.org/projects/strongswan/wiki/Attrplugin

UNITY_DEF_DOMAIN and UNITY_SPLITDNS_NAME seem to be restricted
to IKEv1 only.


Every helpful comment is highly appreciated
Harri
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] linux 4.3 regression: received netlink error: Invalid argument (22)

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since kernel 4.3 routing seems to be broken. I get some messages
in /var/log/daemon.log saying

:
Nov  9 21:24:44 cecil charon: 13[IKE] installing new virtual IP 172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
Nov  9 21:24:44 cecil charon: 13[KNL] received netlink error: Invalid argument 
(22)
Nov  9 21:24:44 cecil charon: 13[KNL] unable to install source route for 
172.19.97.237
:

A ping to a host on the remote site fails.

I tried strongswan 5.3.2 and 5.3.3 (as provided by Debian). Moving
back to kernel 4.2.5 seems to fix this problem. Can anybody reproduce?


Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWQQR3AAoJEAqeKp5m04HLVuwIAIaMK5H00uIe/Nu1Rk0eXtwO
6sCEtAjlhW6UjrLTUs1mxoBP3WgObo+da0Twdue9s56hUyYTox3+e8Pyv06tB0Zf
VJn6bwEb7xZ/QPfHQjnAiRWphQFh+YOzGk4azJ0KHH20iMWvUiZe7visti4KeFWp
hwjVvDS0Lm9WFBqqvjKKQ4aLblk4uuecBu0nSOt0L2rSi7mcqhJ3BA9+STpJi7uK
BSrAb6bgxJ6c/UKh/gsqjq+Lr6Q54NtMx6iW7Azb43QmDJWmtE+pSToErko2/bTl
Fle7q2IqFl93/IzSAX50xvgXXoLKKiw5Ua9cerwxWkD2OAGGt1RpC3OYooT92TU=
=ZyrK
-END PGP SIGNATURE-
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] how to tell the iphone to send the issuer certificate?

[Harald Dunkel]

To send an update:

I found a working (more or less) configuration.

Somehow strongswan doesn't use the DN of the iphone's
certificate as the remote ID, but either the FQDN, IPv4
address or IPv6 address. (I didn't check USER_FQDN.)
Probably this is influenced by the iphone somehow?

In the iphone's config settings I had to explicitly set
the Local ID to the CN mentioned in the certificate. If
I leave this Local ID field empty, then strongswan uses
the iphone's IP address as the identifier.

This name has to be set in the Subject Alt Name in the
iphone's certificate as well.

Platform: IOS 9.1, strongswan 5.3.3 on Jessie


Hope this is helpful to anybody. Regards
Harri

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

Re: [strongSwan] how to tell the iphone to send the issuer certificate?

[Harald Dunkel]

Hi Tobias,

On 10/30/15 08:50, Tobias Brunner wrote:
> Hi Harald,
> 
>> Of course the whole chain has been loaded
>> on the iphone.
> 
> But not on the strongSwan host?
> 

The strongswan host has copies of the iphone's root and
issuing ca certificates in ipsec.d/cacerts. It's own
certificate has been signed by the same issuing ca.

Is it OK if I send you the log files and the real
config file in private mail? I wouldn't like to post
it on the mailing list.


Regards
Harri

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

[strongSwan] how to tell the iphone to send the issuer certificate?

[Harald Dunkel]

Hi folks,

strongswan 5.3.3 on Linux, IOS 9.1, IKEv2:

Using strongswan on both peers I see in the log file that
the roadwarrior sends the issuer certificate next to its
own end entity certificate to the gateway. The iphone doesn't.
Result:

no trusted RSA public key found for 'iphone01.example.com'
:-(

Which magic trick would you suggest to tell the iphone to
send the issuer certificate as well?

How comes that strongswan on the gateway doesn't use its
local cacerts database for the missing cert?

Anonymized ipsec.conf is attached. Please excuse that there
is no log file included, but it contains too much sensible
information to be posted on a mailing list.


Every helpful comment is highly appreciated.
Harri
config setup
charondebug="dmn 2, mgr 2, ike 3, chd 2, cfg 3, net 2"

conn %default
left= gate.example.com
leftcert= gate.example.com.pem
leftsendcert= always
leftsubnet  = 10.1.1.0/24
leftfirewall= yes
ikelifetime = 3h
lifetime= 1h
rekey   = yes
dpdaction   = hold
dpddelay= 30s
#
# IKEv2 using RSA authentication
conn IPSec-IKEv2
keyexchange = ikev2
ike = 
aes256-sha256-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024!
esp = 
aes256-sha256-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024!
right   = %any
rightauth   = pubkey
rightsendcert   = ifasked
rightsourceip   = %dhcp
# fragmentation = yes
auto= add

#
# IKEv1 using xauth (i.e. enter password)
conn CiscoIPSec
keyexchange = ikev1
ike = aes256-sha1-modp1536!
esp = aes256-sha1!
rightauth   = pubkey
right   = %any
rightsourceip   = %dhcp
rightauth2  = xauth
auto= add
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] show issuer for "no trusted RSA public key found for 'peer.example.com'" in the log file?

[Harald Dunkel]

Hi folks,

AFAIK a log file message like

no trusted RSA public key found for 'peer.example.com'

means that the issuer for peer's certificate is not trusted.
Wouldn't it be helpful if the issuer of the "bad" certificate
is shown in the log file as well?


Just a suggestion, of course. Regards
Harri
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] charon says "DH group MODP_1024 inacceptable, requesting MODP_1536"

[Harald Dunkel]

Hi folks,

I am trying to connect an ios 9.1 device to strongswan 5.3.3,
using IKEv2. Problem: It doesn't.

Here is the log file:

Oct 27 09:33:25 srvl047 charon: 02[NET] received packet: from 
2001:db8:30:fff0:4ff:fc45:f6a4:3860[500] to 2001:db8:13b0:::63[500]
Oct 27 09:33:25 srvl047 charon: 02[NET] waiting for data on sockets
Oct 27 09:33:25 srvl047 charon: 15[MGR] checkout IKE_SA by message
Oct 27 09:33:25 srvl047 charon: 15[MGR] created IKE_SA (unnamed)[5]
Oct 27 09:33:25 srvl047 charon: 15[NET] received packet: from 
2001:db8:30:fff0:4ff:fc45:f6a4:3860[500] to 2001:db8:13b0:::63[500] (388 
bytes)
Oct 27 09:33:25 srvl047 charon: 15[ENC] parsed IKE_SA_INIT request 0 [ SA KE No 
N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Oct 27 09:33:25 srvl047 charon: 15[CFG] looking for an ike config for 
2001:db8:13b0:::63...2001:db8:30:fff0:4ff:fc45:f6a4:3860
Oct 27 09:33:25 srvl047 charon: 15[CFG]   candidate: gate.example.com...%any, 
prio 1052
Oct 27 09:33:25 srvl047 charon: 15[CFG]   candidate: gate.example.com...%any, 
prio 1052
Oct 27 09:33:25 srvl047 charon: 15[CFG] found matching ike config: 
gate.example.com...%any with prio 1052
Oct 27 09:33:25 srvl047 charon: 15[IKE] 2001:db8:30:fff0:4ff:fc45:f6a4:3860 is 
initiating an IKE_SA
Oct 27 09:33:25 srvl047 charon: 15[IKE] IKE_SA (unnamed)[5] state change: 
CREATED => CONNECTING
Oct 27 09:33:25 srvl047 charon: 15[CFG] selecting proposal:
Oct 27 09:33:25 srvl047 charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Oct 27 09:33:25 srvl047 charon: 15[CFG] selecting proposal:
Oct 27 09:33:25 srvl047 charon: 15[CFG]   no acceptable DIFFIE_HELLMAN_GROUP 
found
Oct 27 09:33:25 srvl047 charon: 15[CFG] selecting proposal:
Oct 27 09:33:25 srvl047 charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Oct 27 09:33:25 srvl047 charon: 15[CFG] selecting proposal:
Oct 27 09:33:25 srvl047 charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Oct 27 09:33:25 srvl047 charon: 15[CFG] selecting proposal:
Oct 27 09:33:25 srvl047 charon: 15[CFG]   proposal matches
Oct 27 09:33:25 srvl047 charon: 15[CFG] received proposals: 
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, 
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Oct 27 09:33:25 srvl047 charon: 15[CFG] configured proposals: 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, 
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Oct 27 09:33:25 srvl047 charon: 15[CFG] selected proposal: 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
Oct 27 09:33:25 srvl047 charon: 15[IKE] sending strongSwan vendor ID
Oct 27 09:33:25 srvl047 charon: 15[IKE] DH group MODP_1024 inacceptable, 
requesting MODP_1536
Oct 27 09:33:25 srvl047 charon: 15[ENC] generating IKE_SA_INIT response 0 [ 
N(INVAL_KE) V ]
Oct 27 09:33:25 srvl047 charon: 15[NET] sending packet: from 
2001:db8:13b0:::63[500] to 2001:db8:30:fff0:4ff:fc45:f6a4:3860[500] (58 
bytes)
Oct 27 09:33:25 srvl047 charon: 15[MGR] checkin and destroy IKE_SA (unnamed)[5]
Oct 27 09:33:25 srvl047 charon: 03[NET] sending packet: from 
2001:db8:13b0:::63[500] to 2001:db8:30:fff0:4ff:fc45:f6a4:3860[500]
Oct 27 09:33:25 srvl047 charon: 15[IKE] IKE_SA (unnamed)[5] state change: 
CONNECTING => DESTROYING
Oct 27 09:33:25 srvl047 charon: 15[MGR] check-in and destroy of IKE_SA 
successful


Please note that both peers agreed upon a proposal including DH group 5,
but then there is a message "DH group MODP_1024 inacceptable, requesting
MODP_1536". The selected proposal wasn't DH2, so I wonder WTH?


Every helpful comment would be highly appreciated
Regards

Harri
-- 
aixigo AG, Karl-Friedrich-Strasse 68, 52072 Aachen, Germany
phone: +49 241 559709-79, fax: +49 241 559709-99
eMail: harald.dun...@aixigo.de, web: http://www.aixigo.de
Amtsgericht Aachen - HRB 8057, Vorstand: Erich Borsch, Christian Friedrich, 
Tobias Haustein, Vors. des Aufsichtsrates: Prof. Dr. Ruediger von Nitzsch
config setup
charondebug="dmn 2, mgr 2, ike 2, chd 2, cfg 2, net 2"

conn %default
left= gate.example.com
leftcert= gate.example.com.pem
leftsendcert= always
leftsubnet  = 10.1.1.0/24
leftfirewall= yes
ikelifetime = 3h
lifetime= 1h
rekey   = yes
dpdaction   = hold
dpddelay= 30s
#
# IKEv2 using RSA authentication
conn IPSec-IKEv2
keyexchange = ikev2
ike = 
aes256-sha256-modp2048,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha256-modp1024,aes256-sha1-modp1024!
esp = 
aes256-sha256-modp2048,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha256-modp1024,aes256-sha1-modp1024!
right   = 

Re: [strongSwan] charon says "DH group MODP_1024 inacceptable, requesting MODP_1536"

[Harald Dunkel]

Hi Tobias,

On 10/27/15 11:43, Tobias Brunner wrote:
> Hi Harald,
> 
>> Please note that both peers agreed upon a proposal including DH group 5,
>> but then there is a message "DH group MODP_1024 inacceptable, requesting
>> MODP_1536". The selected proposal wasn't DH2, so I wonder WTH?
> 
> Since the initiator has to send its public DH value in the KE payload in
> the first IKE_SA_INIT message it has to guess the DH group of the
> proposal the peer will select, in this case it guessed MODP_1024.
> However, because the selected proposal is with MODP_1536 the public DH
> value in the KE payload can't be used so the responder sends back an
> INVALID_KE_PAYLOAD notify with the DH group from the selected proposal.
>  But as is documented at [1] iOS apparently does not support this
> particular DH group so this fails.
> 
> Regards,
> Tobias
> 
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/IOS_(Apple)
> 

Thanx for the pointer. Seems I have missed the update to this wiki page.

If I got you correctly I would have to move back to DH2, just to make
the iphone users happy. Do you know of any commitments from Apple to fix
this?


Regards
Harri

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

[strongSwan] setting domain search via attr plugin (IKEv2)

[Harald Dunkel]

Hi folks,

I would like to modify the domain search list in /etc/resolv.conf
via the attr plugin on the road warrior laptop. For IKEv1 it seems
to work as described on the wiki, but I wonder why the UNITY_DEF_DOMAIN
and UNITY_SPLITDNS_NAME are not supported for IKEv2 as well?

Strongswan is version 5.2.1. The laptop runs network-manager-\
strongswan 1.3.0 and network-manager 0.9.4.0.


Every helpful comment is highly appreciated
Harri
-- 
aixigo AG, Karl-Friedrich-Strasse 68, 52072 Aachen, Germany
phone: +49 241 559709-0, fax: +49 241 559709-99
eMail: harald.dun...@aixigo.de, web: http://www.aixigo.de
Amtsgericht Aachen - HRB 8057, Vorstand: Erich Borsch, Christian Friedrich, 
Tobias Haustein, Vors. des Aufsichtsrates: Prof. Dr. Ruediger von Nitzsch
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] setting domain search via attr plugin (IKEv2)

[Harald Dunkel]

On 01/23/15 11:14, Martin Willi wrote:
 
 None of our backends (resolve plugin, charon-nm) actually handle such
 attributes. While you could send your own definition of such an
 attribute in IKEv2, it is not handled by strongSwan (or a third party
 client).
 

Thats the point. I would need support for new payload attributes on
both peers. Maybe Strongswan could support a callback function for private
payload attribute types? (Hopefully I wasn't too blind to see)

 In short, configuring domain search lists over IKE is currently not
 supported (and not standardized). All you currently can do is to send
 these Unity attributes to third party clients supporting this
 proprietary extension.
 

Cisco did not hesitate to use the private attributes for IKEv1. Do you
think it would be possible to support similar private attributes for
IKEv2 on both sides, as Cisco did?


Just a suggestion, of course. Keep on your good work.

Harri
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] resolv plugin: add domain/search to resolv.conf?

[Harald Dunkel]

Hi folks,

AFAICS the resolv plugin is responsible for adding the DNS
list to /etc/resolv.conf. Do you think it would be possible
to add the domain or search entries to resolv.conf as well?

It is not mentioned on

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml

nor does the special Cisco parameter (listed on the wiki
page for the attr plugin) work for IKEv2.

Every helpful comment is highly appreciated.


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

[strongSwan] network-manager-strongswan not compatible to new network-manager-gnome?

[Harald Dunkel]

Hi folks,

seems that network-manager-strongswan is not recognized
by the network-manager-gnome applet (0.9.10) anymore.
Its not listed in the connection types for creating a
new VPN connection. Existing connections still work,
but they cannot be edited.

Every helpful hint is highly appreciated
Harri
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] dhcp plugin: mac address unpredictable?

[Harald Dunkel]

Hi Andreas,

On 03/19/14 17:31, Andreas Steffen wrote:
 Hi Harri,
 
 the MAC address does not change if the new certificate
 has the same subjectDistinguishedName or subjectAlternativeName
 chosen as the IKEv2 ID.
 
 As an alternative you could explicitly register the client IKEv2 ID
 as a dhcp-client-identifier attribute with your DHCP server
 as in the following example scenario:
 
 http://www.strongswan.org/uml/testresults/ikev2/dhcp-static-client-id/console.log
 

If I got this right, then the dhcp-client-identifier is
supposed to be taken from either the CN or the DN in the
certificate. I tried both: The DHCP server doesn't
answer.

Looking at the DHCP discover packages sent by charon
(Wireshark) I do not see the CN, but some garbage (e.g.
a part from the OU and O entries). I see the mac address,
too.


???
Regards
Harri

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

[strongSwan] dhcp plugin: mac address unpredictable?

[Harald Dunkel]

Hi folks,

I have to restrict the IP address pool of my DHCP server to
known MAC addresses only. In this context I have 2 questions
about the dhcp plugin (using identity_lease = yes):

Wiki says, the mac address is derived from the IKEv2 identity.
Does this mean the mac address changes, if I renew the client's
certificate?

It is pretty difficult to find the right MAC address in the log
file of the DHCP server, and charon doesn't tell, either. (Maybe
I am too blind to see?) Would it be possible to hardwire the mac
address in the certificate?


Every helpful response is highly appreciated
Harri
-- 
aixigo AG, Karl-Friedrich-Strasse 68, 52072 Aachen, Germany
phone: +49 241 559709-79, fax: +49 241 559709-99
eMail: harald.dun...@aixigo.de, web: http://www.aixigo.de
Amtsgericht Aachen - HRB 8057, Vorstand: Erich Borsch, Christian Friedrich, 
Tobias Haustein, Vors. des Aufsichtsrates: Prof. Dr. Ruediger von Nitzsch
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users