Re: [strongSwan] Roadwarriors can't ping eachother

[Bas van Dijk]

On 9 September 2017 at 16:34, Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:

> Well, you need to accept ESP packets obviously, if you don't use UDP
> encapsulation.
>

Got it. I enabled it.


> Other than that, make sure ip forwarding is enabled globally on moon and
> it is enabled for the involved interfaces.
>

IP forwarding is enabled globally on moon and on eth1 which is connected to
the same vlan that alice and carol are connected to:

[moon] $ sysctl -A | grep -E "ipv4.*(\.forwarding|ip_forward)"
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth1.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_use_pmtu = 0

On top of that, make sure the iptables rules in *filter FORWARD permit the
> traffic from Alice to Bob.
>

These rules on moon that were automatically added by strongswan should
permit that traffic right?

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  10.0.0.2 10.0.0.0/24  policy match
dir in pol ipsec reqid 2 proto esp
ACCEPT all  --  10.0.0.0/24  10.0.0.2 policy match
dir out pol ipsec reqid 2 proto esp
ACCEPT all  --  10.0.0.1 10.0.0.0/24  policy match
dir in pol ipsec reqid 1 proto esp
ACCEPT all  --  10.0.0.0/24  10.0.0.1 policy match
dir out pol ipsec reqid 1 proto esp


> Right now, you don't accept ESP packets, but it seems your tunnels use
> that. Check where the net unreachable comes from.
>

After enabling ESP traffic and doing a ping from alice to 10.0.0.2 I see
the following tcpdump on moon:

16:07:30.329243 IP 192.168.1.1 > 192.168.1.3: ESP(spi=0xc3ac1de0,seq=0x2),
length 136
16:07:30.329287 IP 192.168.1.1 > 10.0.0.2: ICMP echo request, id 1072, seq
1, length 64

I understand the first packet but I'm surprised by the source address of
the second packet. Shouldn't the source be 10.0.0.1?

If I compare routing table 220 of alice:

[alice] $ ip route list table 220
10.0.0.0/24 via 192.168.1.3 dev eth1 proto static src 192.168.1.1

with routing table 220 of my workstation (which is also using strongswan to
connect to our company VPN) I see that on my workstation the src is set to
the VPN assigned IP address and not the public IP address like on alice.
I'm surprised by this difference. Could this explain the routing failure?

I'm clearly not a networking expert so thanks a lot with your help so far.

Bas

Kind regards
>
> Noel
>
> On 09.09.2017 16:16, Bas van Dijk wrote:
> > (I removed the NFLOG rules)
> >
> > [alice] $ iptables-save -c
> > # Generated by iptables-save v1.6.1 on Sat Sep  9 14:02:40 2017
> > *nat
> > :PREROUTING ACCEPT [4:256]
> > :INPUT ACCEPT [0:0]
> > :OUTPUT ACCEPT [4:2672]
> > :POSTROUTING ACCEPT [4:2672]
> > COMMIT
> > # Completed on Sat Sep  9 14:02:40 2017
> > # Generated by iptables-save v1.6.1 on Sat Sep  9 14:02:40 2017
> > *raw
> > :PREROUTING ACCEPT [18:6158]
> > :OUTPUT ACCEPT [16:8534]
> > :nixos-fw-rpfilter - [0:0]
> > [18:6158] -A PREROUTING -j nixos-fw-rpfilter
> > [18:6158] -A nixos-fw-rpfilter -m rpfilter -j RETURN
> > [0:0] -A nixos-fw-rpfilter -s 0.0.0.0/32 <http://0.0.0.0/32> -d
> 255.255.255.255/32 <http://255.255.255.255/32> -p udp -m udp --sport 68
> --dport 67 -j RETURN
> > [0:0] -A nixos-fw-rpfilter -j DROP
> > COMMIT
> > # Completed on Sat Sep  9 14:02:40 2017
> > # Generated by iptables-save v1.6.1 on Sat Sep  9 14:02:40 2017
> > *filter
> > :INPUT ACCEPT [0:0]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [0:0]
> > :nixos-fw - [0:0]
> > :nixos-fw-accept - [0:0]
> > :nixos-fw-log-refuse - [0:0]
> > :nixos-fw-refuse - [0:0]
> > [0:0] -A INPUT -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.1/32 <
> http://10.0.0.1/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > [18:6158] -A INPUT -j nixos-fw
> > [0:0] -A FORWARD -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.1/32 <
> http://10.0.0.1/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > [0:0] -A FORWARD -s 10.0.0.1/32 <http://10.0.0.1/32> -d 10.0.0.0/24 <
> http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > [0:0] -A OUTPUT -s 10.0.0.1/32 <http://10.0.0.1/32> -d 10.0.0.0/24 <
> http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > [2:1152] -A nixos-fw -i lo -j nixos-fw-accept
> > [10:4622] -A nixos-fw -m conntrack --ctstate RELATED,ESTABLISHED -j
> nixos-fw-accept
> > [0:0] -A ni

Re: [strongSwan] Roadwarriors can't ping eachother

[Bas van Dijk]

INPUT ACCEPT [5:4546]
:OUTPUT ACCEPT [1:64]
:POSTROUTING ACCEPT [1:64]
COMMIT
# Completed on Sat Sep  9 14:02:37 2017
# Generated by iptables-save v1.6.1 on Sat Sep  9 14:02:37 2017
*raw
:PREROUTING ACCEPT [15:8288]
:OUTPUT ACCEPT [15:6477]
:nixos-fw-rpfilter - [0:0]
[15:8288] -A PREROUTING -j nixos-fw-rpfilter
[15:8288] -A nixos-fw-rpfilter -m rpfilter -j RETURN
[0:0] -A nixos-fw-rpfilter -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m
udp --sport 68 --dport 67 -j RETURN
[0:0] -A nixos-fw-rpfilter -j DROP
COMMIT
# Completed on Sat Sep  9 14:02:37 2017
# Generated by iptables-save v1.6.1 on Sat Sep  9 14:02:37 2017
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2:1432]
:nixos-fw - [0:0]
:nixos-fw-accept - [0:0]
:nixos-fw-log-refuse - [0:0]
:nixos-fw-refuse - [0:0]
[15:8288] -A INPUT -j nixos-fw
[0:0] -A FORWARD -s 10.0.0.2/32 -d 10.0.0.0/24 -i eth1 -m policy --dir in
--pol ipsec --reqid 3 --proto esp -j ACCEPT
[0:0] -A FORWARD -s 10.0.0.0/24 -d 10.0.0.2/32 -o eth1 -m policy --dir out
--pol ipsec --reqid 3 --proto esp -j ACCEPT
[0:0] -A FORWARD -s 10.0.0.1/32 -d 10.0.0.0/24 -i eth1 -m policy --dir in
--pol ipsec --reqid 2 --proto esp -j ACCEPT
[0:0] -A FORWARD -s 10.0.0.0/24 -d 10.0.0.1/32 -o eth1 -m policy --dir out
--pol ipsec --reqid 2 --proto esp -j ACCEPT
[0:0] -A nixos-fw -i lo -j nixos-fw-accept
[5:2328] -A nixos-fw -m conntrack --ctstate RELATED,ESTABLISHED -j
nixos-fw-accept
[4:3152] -A nixos-fw -p udp -m udp --dport 4500 -j nixos-fw-accept
[4:2680] -A nixos-fw -p udp -m udp --dport 500 -j nixos-fw-accept
[0:0] -A nixos-fw -p icmp -m icmp --icmp-type 8 -j nixos-fw-accept
[2:128] -A nixos-fw -j nixos-fw-log-refuse
[13:8160] -A nixos-fw-accept -j ACCEPT
[0:0] -A nixos-fw-log-refuse -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN
-j LOG --log-prefix "rejected connection: " --log-level 6
[2:128] -A nixos-fw-log-refuse -m pkttype ! --pkt-type unicast -j
nixos-fw-refuse
[0:0] -A nixos-fw-log-refuse -j nixos-fw-refuse
[2:128] -A nixos-fw-refuse -j DROP
COMMIT
# Completed on Sat Sep  9 14:02:37 2017

[moon] $ sysctl -A | grep rp_filter
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0

BTW note that if I execute the following on all hosts:

$ iptables --insert INPUT --protocol ESP --jump ACCEPT

pinging from alice to carol will actually give a "Destination Net
Unreachable" error instead of not giving any output:

[alice] $ ping -c 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
>From 192.168.1.3 icmp_seq=1 Destination Net Unreachable

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms


On 9 September 2017 at 15:57, Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:

> Hi Bas,
>
> Please provide the outputs of `iptables-save -c` on all hosts
> and the output of `sysctl -A | grep rp_filter`. `iptables -S` is not
> useful.
>
> Kind regards
>
> Noel
>
> On 09.09.2017 15:50, Bas van Dijk wrote:
> > Hi Noel,
> >
> > These are the firewall rules of all hosts after establishing the tunnels
> (all the NFLOG rules will be removed eventually, they're currently used for
> debugging):
> >
> > [alice] $ iptables -S
> > -P INPUT ACCEPT
> > -P FORWARD ACCEPT
> > -P OUTPUT ACCEPT
> > -N nixos-fw
> > -N nixos-fw-accept
> > -N nixos-fw-log-refuse
> > -N nixos-fw-refuse
> > -A INPUT -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.1/32 <
> http://10.0.0.1/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > -A INPUT -m addrtype ! --dst-type LOCAL -m policy --dir in --pol ipsec
> -j NFLOG --nflog-group 5
> > -A INPUT -m addrtype --dst-type LOCAL -m policy --dir in --pol ipsec -j
> NFLOG --nflog-group 5
> > -A INPUT -p udp -m multiport --dports 500,4500 -j NFLOG --nflog-group 5
> > -A INPUT -p ah -j NFLOG --nflog-group 5
> > -A INPUT -p esp -j NFLOG --nflog-group 5
> > -A INPUT -j nixos-fw
> > -A FORWARD -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.1/32 <
> http://10.0.0.1/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > -A FORWARD -s 10.0.0.1/32 <http://10.0.0.1/32> -d 10.0.0.0/24 <
> http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > -A OUTPUT -s 10.0.0.1/32 <http://10.0.0.1/32> -d 10.0.0.0/24 <
> http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1
> --proto esp -j ACCEPT
> > -A OUTPUT -m policy --dir out --pol ipsec -j NFLOG --nflog-group 5
> > -A O

Re: [strongSwan] Roadwarriors can't ping eachother

[Bas van Dijk]

cmp --icmp-type 8 -j nixos-fw-accept
-A nixos-fw -j nixos-fw-log-refuse
-A nixos-fw-accept -j ACCEPT
-A nixos-fw-log-refuse -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG
--log-prefix "rejected connection: " --log-level 6
-A nixos-fw-log-refuse -m pkttype ! --pkt-type unicast -j nixos-fw-refuse
-A nixos-fw-log-refuse -j nixos-fw-refuse
-A nixos-fw-refuse -j DROP


On 9 September 2017 at 15:34, Noel Kuntze <noel.kuntze+strongswan-users-
ml@thermi.consulting> wrote:

> Hi,
>
> Check your iptables rules.
>
> Kind regards
>
> Noel
>
> On 09.09.2017 14:06, Bas van Dijk wrote:
> > Dear list,
> >
> > (I accidentally sent a previous message <https://groups.google.com/for
> um/#%21topic/strongswan-users/2ytikPcg7jA> to the read-only
> strongswan-us...@googlegroups.com <mailto:strongswan-users@googl
> egroups.com>. So let's try the real list.)
> >
> > I'm working on another NixOS strongswan test. This time I have two
> roadwarriors alice and carol that set up a connection to gateway moon. They
> request a virtual IP. The gateway moon assigns virtual IP addresses from a
> pool per roadwarrior containing a single IP address. Authentication is
> based on X.509 certificates. In order to test the tunnel alice and carol
> ping each other. The test configuration can be found in:
> >
> > https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl
> -pubkey-test/nixos/tests/strongswan-swanctl-pubkey.nix
> >
> > The roadwarriors alice and carol can successfully establish a CHILD_SA
> with the gateway moon. The problem is that the roadwarriors can't ping
> eachother.
> >
> > This is a tcpdump on alice while initiating the CHILD_SA and trying to
> ping carol:
> >
> > [alice] $ tcpdump -s 0 -n -i nflog:5
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> > listening on nflog:5, link-type NFLOG (Linux netfilter log messages),
> capture size 262144 bytes
> > # swanctl -i --child alice
> > 11:05:07.318185 IP 192.168.1.1.500 > 192.168.1.3.500: isakmp: parent_sa
> ikev2_init[I]
> > 11:05:07.318291 IP 192.168.1.3.500 > 192.168.1.1.500: isakmp: parent_sa
> ikev2_init[R]
> > 11:05:07.318296 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[I]
> > 11:05:07.318308 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[I]
> > 11:05:08.346181 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[R]
> > 11:05:08.346196 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[R]
> > # ping -c 1 10.0.0.2
> > 11:05:15.898172 IP 192.168.1.1 > 10.0.0.2 <http://10.0.0.2>: ICMP echo
> request, id 1120, seq 1, length 64
> > 11:05:15.898200 IP 192.168.1.1 > 10.0.0.2 <http://10.0.0.2>: ICMP echo
> request, id 1120, seq 1, length 64
> > 11:05:15.898205 IP 192.168.1.1 > 192.168.1.3 <http://192.168.1.3>:
> ESP(spi=0xc6877d56,seq=0x1), length 136
> >
> > So it looks like the ping packet gets encapsulated and send to
> moon. This is the dump on moon:
> >
> > [moon] $ tcpdump -s 0 -n -i nflog:5
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> > listening on nflog:5, link-type NFLOG (Linux netfilter log messages),
> capture size 262144 bytes
> > 11:05:07.170190 IP 192.168.1.1.500 > 192.168.1.3.500: isakmp: parent_sa
> ikev2_init[I]
> > 11:05:07.170218 IP 192.168.1.3.500 > 192.168.1.1.500: isakmp: parent_sa
> ikev2_init[R]
> > 11:05:07.170221 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[I]
> > 11:05:07.170227 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[I]
> > 11:05:08.225827 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[R]
> > 11:05:08.225843 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
> isakmp: child_sa  ikev2_auth[R]
> >
> > 11:05:15.87 IP 192.168.1.1 > 192.168.1.3 <http://192.168.1.3>:
> ESP(spi=0xc6877d56,seq=0x1), length 136
> >
> > So moon receives the encapsulated ping message from alice but it never
> reroutes it to carol. Is this caused by a bad routing configuration? These
> are the routes on alice and her auto-generated swanctl configuration:
> >
> > [alice] $ ip route list table 220
> > 10.0.0.0/24 <http://10.0.0.0/24> via 192.168.1.3 dev eth1 proto static
> src 192.168.1.1
> >
> > [alice] $ cat /etc/swanctl/swanctl.conf
> > connections {
> >   alice {
> > children {
> >   alice 

[strongSwan] Roadwarriors can't ping eachother

[Bas van Dijk]

Dear list,

(I accidentally sent a previous message
 to
the read-only strongswan-us...@googlegroups.com. So let's try the real
list.)

I'm working on another NixOS strongswan test. This time I have two
roadwarriors alice and carol that set up a connection to gateway moon. They
request a virtual IP. The gateway moon assigns virtual IP addresses from a
pool per roadwarrior containing a single IP address. Authentication is
based on X.509 certificates. In order to test the tunnel alice and carol
ping each other. The test configuration can be found in:

https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-pubkey-test/nixos/tests/strongswan-swanctl-pubkey.nix

The roadwarriors alice and carol can successfully establish a CHILD_SA with
the gateway moon. The problem is that the roadwarriors can't ping
eachother.

This is a tcpdump on alice while initiating the CHILD_SA and trying to ping
carol:

[alice] $ tcpdump -s 0 -n -i nflog:5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nflog:5, link-type NFLOG (Linux netfilter log messages),
capture size 262144 bytes
# swanctl -i --child alice
11:05:07.318185 IP 192.168.1.1.500 > 192.168.1.3.500: isakmp: parent_sa
ikev2_init[I]
11:05:07.318291 IP 192.168.1.3.500 > 192.168.1.1.500: isakmp: parent_sa
ikev2_init[R]
11:05:07.318296 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]
11:05:07.318308 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]
11:05:08.346181 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[R]
11:05:08.346196 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[R]
# ping -c 1 10.0.0.2
11:05:15.898172 IP 192.168.1.1 > 10.0.0.2: ICMP echo request, id 1120, seq
1, length 64
11:05:15.898200 IP 192.168.1.1 > 10.0.0.2: ICMP echo request, id 1120, seq
1, length 64
11:05:15.898205 IP 192.168.1.1 > 192.168.1.3: ESP(spi=0xc6877d56,seq=0x1),
length 136

So it looks like the ping packet gets encapsulated and send to moon. This
is the dump on moon:

[moon] $ tcpdump -s 0 -n -i nflog:5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nflog:5, link-type NFLOG (Linux netfilter log messages),
capture size 262144 bytes
11:05:07.170190 IP 192.168.1.1.500 > 192.168.1.3.500: isakmp: parent_sa
ikev2_init[I]
11:05:07.170218 IP 192.168.1.3.500 > 192.168.1.1.500: isakmp: parent_sa
ikev2_init[R]
11:05:07.170221 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]
11:05:07.170227 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]
11:05:08.225827 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[R]
11:05:08.225843 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[R]

11:05:15.87 IP 192.168.1.1 > 192.168.1.3: ESP(spi=0xc6877d56,seq=0x1),
length 136

So moon receives the encapsulated ping message from alice but it never
reroutes it to carol. Is this caused by a bad routing configuration? These
are the routes on alice and her auto-generated swanctl configuration:

[alice] $ ip route list table 220
10.0.0.0/24 via 192.168.1.3 dev eth1 proto static src 192.168.1.1

[alice] $ cat /etc/swanctl/swanctl.conf
connections {
  alice {
children {
  alice {
remote_ts = 10.0.0.0/24
start_action = trap
updown =
/nix/store/jdcviy5z25xamq35g8k9qbdpskkx3w9g-strongswan-5.6.0/libexec/ipsec/_updown
iptables
  }
}
local-main {
  auth = pubkey
  certs = aliceCert.der
  id = alice
}
remote-main {
  auth = pubkey
  id = moon
}
remote_addrs = moon
version = 2
vips = 0.0.0.0
  }
}

Routing table 220 is empty on moon. Is that how it's supposed to be? This
is its auto-generated swanctl configuration:

[moon] $ cat /etc/swanctl/swanctl.conf
connections {
  alice {
children {
  alice {
local_ts = 10.0.0.0/24
updown =
/nix/store/jdcviy5z25xamq35g8k9qbdpskkx3w9g-strongswan-5.6.0/libexec/ipsec/_updown
iptables
  }
}
local-main {
  auth = pubkey
  certs = moonCert.der
  id = moon
}
pools = alice
remote-main {
  auth = pubkey
  id = alice
}
version = 2
  }
  carol {
children {
  carol {
local_ts = 10.0.0.0/24
updown =
/nix/store/jdcviy5z25xamq35g8k9qbdpskkx3w9g-strongswan-5.6.0/libexec/ipsec/_updown
iptables
  }
}
local-main {
  auth = pubkey
  certs = moonCert.der
  id = moon
}
pools = carol
remote-main {
  auth = pubkey
  id = carol
}
version = 2
  }
}
pools {
  alice {
addrs = 10.0.0.1
  }
  carol {
addrs = 10.0.0.2
  }
}

I'm sure I'm not configuring something correctly. Can somebody point me in
the right direction to get this test succeeding?

Re: [strongSwan] Cannot ping machines on remote local network

[Bas van Dijk]

Hi Ric,

Is IP forwarding enabled on the router?

sysctl net.ipv4.ip_forward=1

Bas

On 5 Sep 2017 12:53 AM, "Ric S"  wrote:

> Hi folks,
>
> I have been ripping my hair out with this issue.
>
> I'm running strongswan 5.5.3 on a router. The routers lan subnet is
> 192.168.0.1/24.
> I can successfully connect to it with an Ipad with ikev2 and surf the
> internet, but I cannot reach any internal machines.
>
> My config is the following:
>
> ipsec.conf:
>
> config setup
>  charondebug="net 2, knl 2, cfg 2"
>
> conn ikev2
>  keyexchange=ikev2
>  ike=aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-
> modp2048,aes128-
> sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes1
>  esp=aes128-aes256-sha1-sha256-modp2048-modp4096-
> modp1024,aes128-sha1,aes128-
> sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128
>  dpdaction=clear
>  dpddelay=60s
>  left=%defaultroute
>  leftfirewall=yes
>  lefthostaccess=yes
>  leftid=myname.ddns.net
>  leftsubnet=192.168.0.0/24
>  leftcert=host-vpn.der
>  leftsendcert=always
>  right=%any
>  rightauth=eap-tls
>  rightsourceip=%dhcp
>  eap_identity=%any
>  type=passthrough
>  auto=add
>
> strongswanf.conf:
>
> charon {
> interfaces_ignore = vlan2, eth0, eth1, eth2, wl0.1, wl1.1
> plugins {
> dhcp {
> force_server_address = yes
> server = 192.168.0.1
> identity_lease = yes
> }
> farp {
> load = yes
> }
> }}
>
> threads = 8
> dns1 = 8.8.8.8
> dns1 = 8.8.8.4
>
>
>
> Status:
>
> Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.4.80, armv7l):
>   uptime: 14 minutes, since Sep 05 00:09:53 2017
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 8
>   loaded plugins: charon test-vectors aes des blowfish rc2 sha2 sha1 md5
> random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12
> pgp
> dnskey sshkey pem openssl fips-prf gmp curve25519 agent xcbc cmac hmac
> sqlite
> attr kernel-pfkey kernel-netlink resolve socket-default farp stroke vici
> updown eap-identity eap-aka eap-md5 eap-mschapv2 eap-radius eap-tls xauth-
> generic xauth-eap dhcp whitelist led duplicheck
> Listening IP addresses:
>   169.254.255.1
>   192.168.0.1
>   87.168.243.83
> Connections:
>ikev2:  %any...%any  IKEv2, dpddelay=60s
>ikev2:   local:  [myname.ddns.net] uses public key authentication
>ikev2:cert:  "C=DE, O=MYORG, CN=myname.ddns.net"
>ikev2:   remote: uses EAP_TLS authentication with EAP identity
> '%any'
>ikev2:   child:  192.168.0.0/24 === dynamic PASS, dpdaction=clear
> Security Associations (1 up, 0 connecting):
>ikev2[6]: ESTABLISHED 11 seconds ago, 87.168.243.83[myname.ddns.net
> ]...
> 109.43.1.19[R6400]
>ikev2[6]: IKEv2 SPIs: 243db36d71718704_i 688c466c497d2b9a_r*, public
> key reauthentication in 2 hours
>ikev2[6]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/
> MODP_1024
>ikev2{4}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c0983fe7_i
> 04eb0f50_o
>ikev2{4}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o,
> rekeying in 48 minutes
>ikev2{4}:   192.168.0.0/24 === 192.168.0.121/32
>
> swanctl --list-sas
> ikev2: #6, ESTABLISHED, IKEv2, 243db36d71718704_i 688c466c497d2b9a_r*
>   local  'myname.ddns.net' @ 87.168.243.83[4500]
>   remote 'R6400' @ 109.43.1.19[39898] [192.168.0.121]
>   AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>   established 92s ago, reauth in 9765s
>   ikev2: #4, reqid 3, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/
> HMAC_SHA2_256_128
> installed 89s ago, rekeying in 2800s, expires in 3511s
> in  c0983fe7,  0 bytes, 0 packets
> out 04eb0f50,  0 bytes, 0 packets
> local  192.168.0.0/24
> remote 192.168.0.121/32
>
> ip route list table 220
> 192.168.0.121 via 62.155.242.107 dev ppp0  proto static  src 192.168.0.1
>
> FARP seems to work, this is a ping from one of the local machines:
>
> ping R6400
> PING R6400 (192.168.0.121) 56(84) bytes of data.
> From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host
> Unreachable
> From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination Host
> Unreachable
>
>
> Routers iptable output:
>
> iptables -vnL
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT 0--  ppp0   *   192.168.0.121
> 192.168.0.0/24  policy match dir in pol ipsec reqid 4 proto 50
>   161 29398 ACCEPT udp  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> udp dpt:4500
> 8  4544 ACCEPT udp  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> udp dpt:500
> 0 0 log
> ...
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT 0--  ppp0   *   192.168.0.121
> 192.168.0.0/24  policy match dir in pol ipsec reqid 4 proto 50
> 0 0 ACCEPT 0--  *

Re: [strongSwan] NixOS test

[Bas van Dijk]

On 31 August 2017 at 19:40, Noel Kuntze
<noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:
> The aborting of the initation is a deliberate design decision. That is 
> because this is a configuration error of the remote peer.
> Use auto=route to get the kernel and charon to try to establish a matching 
> CHILD_SA for the traffic matching the TS.

Hi Noel,

Thanks for the explanation. I guess the swanctl equivalent of
auto=route is start_action=trap. What do you mean by "remote peer"?
The initiator carol or the responder moon? I actually tried setting
start_action=trap on carol before but got the same NO_PROPOSAL_CHOSEN
error after a few successful test runs.

I just tried setting start_action=trap on moon as well and I haven't
been able to reproduce the error after many test runs. So this might
indeed fix the problem! I am surprised this setting is not set on the
same test in the strongSwan project:

  
https://github.com/strongswan/strongswan/blob/master/testing/tests/swanctl/rw-psk-ipv4/hosts/moon/etc/swanctl/swanctl.conf

Maybe the machines in the strongSwan test suite are booted
sequentially instead of in parallel like in my NixOS test so the error
doesn't appear.

> There are many more failure cases than just that that would need to be 
> considered to make charon try to keep a CHILD_SA up at all times.

Is there any documentation on how to configure strongSwan for systems
that need to work reliably and fully autonomously?

Thanks a lot for the start_action=trap tip. I think I'm also going to
set that on my company VPN because it seems to make things more
reliable.

Bas

> On 31.08.2017 19:31, Bas van Dijk wrote:
>> I've now changed the testScript[1] to first start moon, wait for the
>> strongswan-swanctl service to start and then start carol. Using this
>> setup it's almost guaranteed that moon has loaded the connection
>> before carol initiates the connection.
>>
>> In the process of debugging this I did discover the option:
>> charon.retry_initiate_interval "Interval in seconds to use when
>> retrying to initiate an IKE_SA (e.g. if
>> DNS resolution failed)". Would it make sense to extend the behavior of
>> this option to also retry an IKE_SA if a previous attempt failed *for
>> any reason* (so not just on DNS failures)? If it works like that it
>> will solve my problem because carol will just retry initiating the
>> connection after it gets the NO_PROP message. It will make initiation
>> more automatic and robust.
>>
>> Bas
>>
>> [1] 
>> https://github.com/LumiGuide/nixpkgs/blob/c16b7285fe9cc379227a255f955b38c6830a7b24/nixos/tests/strongswan-swanctl.nix#L150
>>
>> On 31 August 2017 at 11:04, Bas van Dijk <v.dijk@gmail.com> wrote:
>>> Ok after studying this part of the log a bit further:
>>>
>>> https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925#file-strongswan-swanctl-test-failure-log-L1428:L1459
>>>
>>> I see that the following is going on:
>>>
>>> 1. moon has started charon-systemd but hasn't loaded the connection yet
>>> 2. carol sends a IKE_SA_INIT request to moon
>>> 3. since moon hasn't loaded the connection yet it can't find an IKE
>>> config for 192.168.1.3...192.168.1.2 and sends a NO_PROP response back
>>> to carol
>>> 4. moon loads the connection
>>> 5. carol warns about the "received NO_PROPOSAL_CHOSEN notify error"
>>> 6. pings from carol to alice fail continuously because the VPN is not
>>> established
>>>
>>> Is there a way for carol to keep trying to establish a connection
>>> until it succeeds?
>>>
>>> Bas
>>>
>>>
>>> On 31 August 2017 at 09:14, Bas van Dijk <v.dijk@gmail.com> wrote:
>>>> I also included the log of a successful test run:
>>>>
>>>> https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925#file-strongswan-swanctl-test-success-log
>>>>
>>>> On 31 August 2017 at 09:09, Bas van Dijk <v.dijk@gmail.com> wrote:
>>>>> I noticed that my test succeeds most of the time but I just observed a
>>>>> test run where carol keeps trying to ping alice but fails each time.
>>>>> The following line from the test log[1] seems suspect:
>>>>>
>>>>> carol# [ 4.538963] charon-systemd[716]: received NO_PROPOSAL_CHOSEN 
>>>>> notify error
>>>>>
>>>>> I haven't looked into this error yet but I suspect it's a concurrency
>>>>> issue. Note that all machines start up at the same time[2]. I think if
>>>>> I first start moon, wait for the stron

Re: [strongSwan] NixOS test

[Bas van Dijk]

I've now changed the testScript[1] to first start moon, wait for the
strongswan-swanctl service to start and then start carol. Using this
setup it's almost guaranteed that moon has loaded the connection
before carol initiates the connection.

In the process of debugging this I did discover the option:
charon.retry_initiate_interval "Interval in seconds to use when
retrying to initiate an IKE_SA (e.g. if
DNS resolution failed)". Would it make sense to extend the behavior of
this option to also retry an IKE_SA if a previous attempt failed *for
any reason* (so not just on DNS failures)? If it works like that it
will solve my problem because carol will just retry initiating the
connection after it gets the NO_PROP message. It will make initiation
more automatic and robust.

Bas

[1] 
https://github.com/LumiGuide/nixpkgs/blob/c16b7285fe9cc379227a255f955b38c6830a7b24/nixos/tests/strongswan-swanctl.nix#L150

On 31 August 2017 at 11:04, Bas van Dijk <v.dijk@gmail.com> wrote:
> Ok after studying this part of the log a bit further:
>
> https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925#file-strongswan-swanctl-test-failure-log-L1428:L1459
>
> I see that the following is going on:
>
> 1. moon has started charon-systemd but hasn't loaded the connection yet
> 2. carol sends a IKE_SA_INIT request to moon
> 3. since moon hasn't loaded the connection yet it can't find an IKE
> config for 192.168.1.3...192.168.1.2 and sends a NO_PROP response back
> to carol
> 4. moon loads the connection
> 5. carol warns about the "received NO_PROPOSAL_CHOSEN notify error"
> 6. pings from carol to alice fail continuously because the VPN is not
> established
>
> Is there a way for carol to keep trying to establish a connection
> until it succeeds?
>
> Bas
>
>
> On 31 August 2017 at 09:14, Bas van Dijk <v.dijk@gmail.com> wrote:
>> I also included the log of a successful test run:
>>
>> https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925#file-strongswan-swanctl-test-success-log
>>
>> On 31 August 2017 at 09:09, Bas van Dijk <v.dijk@gmail.com> wrote:
>>> I noticed that my test succeeds most of the time but I just observed a
>>> test run where carol keeps trying to ping alice but fails each time.
>>> The following line from the test log[1] seems suspect:
>>>
>>> carol# [ 4.538963] charon-systemd[716]: received NO_PROPOSAL_CHOSEN notify 
>>> error
>>>
>>> I haven't looked into this error yet but I suspect it's a concurrency
>>> issue. Note that all machines start up at the same time[2]. I think if
>>> I first start moon, wait for the strongswan-swanctl.service to start
>>> and then start carol it always succeeds. But I rather not introduce
>>> that sequentialism and I suspect that strongSwan should be able to
>>> handle not fully booted gateways and that I just forgot to configure
>>> some option somewhere.
>>>
>>> Any ideas why the test sometimes fails?
>>>
>>> [1] https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925
>>> [2] 
>>> https://github.com/LumiGuide/nixpkgs/blob/b1bab8cff348ac743ecc6734f1852a16db41a9a2/nixos/tests/strongswan-swanctl.nix#L151
>>>
>>> On 30 August 2017 at 11:52, Bas van Dijk <v.dijk@gmail.com> wrote:
>>>> The test now succeeds[1].
>>>>
>>>> Thanks for your help.
>>>>
>>>> Bas
>>>>
>>>> [1] https://groups.google.com/d/msg/nix-devel/X-0T97MLR7I/cGUCWjXQAAAJ
>>>>
>>>> On 30 August 2017 at 02:57, Bas van Dijk <v.dijk@gmail.com> wrote:
>>>>> On 30 August 2017 at 02:29, Noel Kuntze
>>>>> <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:
>>>>>> Two things:
>>>>>> - Please don't pipe stuff from the web into bash, it just asks for 
>>>>>> trouble and especially don't advertise or advise people to do it.
>>>>>
>>>>> Hi Noel, good point. This should probably be removed from nixos.org/nix.
>>>>>
>>>>>> - Try enforcing UDP encapsulation. If the FW rules actually change 
>>>>>> something, then currently only IKE is allowed, but there's no NAT, so 
>>>>>> ESP is used as transport protocol.
>>>>>
>>>>> Something similar was suggested[1] on the nix-devel mailinglist. I
>>>>> will see how to get that to work.
>>>>>
>>>>> Bas
>>>>>
>>>>> [1] 
>>>>> https://groups.google.com/forum/#!msg/nix-devel/X-0T97MLR7I/jbPQ

Re: [strongSwan] NixOS test

[Bas van Dijk]

Ok after studying this part of the log a bit further:

https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925#file-strongswan-swanctl-test-failure-log-L1428:L1459

I see that the following is going on:

1. moon has started charon-systemd but hasn't loaded the connection yet
2. carol sends a IKE_SA_INIT request to moon
3. since moon hasn't loaded the connection yet it can't find an IKE
config for 192.168.1.3...192.168.1.2 and sends a NO_PROP response back
to carol
4. moon loads the connection
5. carol warns about the "received NO_PROPOSAL_CHOSEN notify error"
6. pings from carol to alice fail continuously because the VPN is not
established

Is there a way for carol to keep trying to establish a connection
until it succeeds?

Bas


On 31 August 2017 at 09:14, Bas van Dijk <v.dijk@gmail.com> wrote:
> I also included the log of a successful test run:
>
> https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925#file-strongswan-swanctl-test-success-log
>
> On 31 August 2017 at 09:09, Bas van Dijk <v.dijk@gmail.com> wrote:
>> I noticed that my test succeeds most of the time but I just observed a
>> test run where carol keeps trying to ping alice but fails each time.
>> The following line from the test log[1] seems suspect:
>>
>> carol# [ 4.538963] charon-systemd[716]: received NO_PROPOSAL_CHOSEN notify 
>> error
>>
>> I haven't looked into this error yet but I suspect it's a concurrency
>> issue. Note that all machines start up at the same time[2]. I think if
>> I first start moon, wait for the strongswan-swanctl.service to start
>> and then start carol it always succeeds. But I rather not introduce
>> that sequentialism and I suspect that strongSwan should be able to
>> handle not fully booted gateways and that I just forgot to configure
>> some option somewhere.
>>
>> Any ideas why the test sometimes fails?
>>
>> [1] https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925
>> [2] 
>> https://github.com/LumiGuide/nixpkgs/blob/b1bab8cff348ac743ecc6734f1852a16db41a9a2/nixos/tests/strongswan-swanctl.nix#L151
>>
>> On 30 August 2017 at 11:52, Bas van Dijk <v.dijk@gmail.com> wrote:
>>> The test now succeeds[1].
>>>
>>> Thanks for your help.
>>>
>>> Bas
>>>
>>> [1] https://groups.google.com/d/msg/nix-devel/X-0T97MLR7I/cGUCWjXQAAAJ
>>>
>>> On 30 August 2017 at 02:57, Bas van Dijk <v.dijk@gmail.com> wrote:
>>>> On 30 August 2017 at 02:29, Noel Kuntze
>>>> <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:
>>>>> Two things:
>>>>> - Please don't pipe stuff from the web into bash, it just asks for 
>>>>> trouble and especially don't advertise or advise people to do it.
>>>>
>>>> Hi Noel, good point. This should probably be removed from nixos.org/nix.
>>>>
>>>>> - Try enforcing UDP encapsulation. If the FW rules actually change 
>>>>> something, then currently only IKE is allowed, but there's no NAT, so ESP 
>>>>> is used as transport protocol.
>>>>
>>>> Something similar was suggested[1] on the nix-devel mailinglist. I
>>>> will see how to get that to work.
>>>>
>>>> Bas
>>>>
>>>> [1] 
>>>> https://groups.google.com/forum/#!msg/nix-devel/X-0T97MLR7I/jbPQucPOAAAJ
>>>>
>>>>> Kind regards
>>>>>
>>>>> Noel
>>>>>
>>>>> On 30.08.2017 02:18, Bas van Dijk wrote:
>>>>>> I've created a PR for the NixOS Linux distribution that adds a module
>>>>>> for strongswan-swanctl:
>>>>>>
>>>>>>   https://github.com/NixOS/nixpkgs/pull/27958
>>>>>>
>>>>>> Although the new module works on our company VPN I would also like to
>>>>>> add a NixOS test to ensure it keeps working. I've mimicked one of the
>>>>>> swanctl tests from the strongswan project:
>>>>>>
>>>>>>   
>>>>>> https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-test/nixos/tests/strongswan-swanctl.nix
>>>>>>
>>>>>> Although SAs get established successfully between gateway moon and
>>>>>> roadwarrior carol I can't seem to ping alice from carol. Since I'm no
>>>>>> networking expert I'm probably missing something obvious. It would be
>>>>>> great if somebody could give me a tip or point me in the right
>>>>>> direction.
>>>>>>
>>>>>> To run the test for yourself you don't need to install NixOS, you only
>>>>>> need the Nix package manager (which is easy to uninstall later on;
>>>>>> just rm -r /nix):
>>>>>>
>>>>>>   $ curl https://nixos.org/nix/install | sh
>>>>>>
>>>>>> Then clone my nixpkgs fork and checkout the right branch:
>>>>>>
>>>>>>   $ git clone https://github.com/LumiGuide/nixpkgs.git
>>>>>>   $ cd nixpkgs
>>>>>>   $ git checkout strongswan-swanctl-test
>>>>>>
>>>>>> Look in nixos/tests/strongswan-swanctl.nix to see how to run the test
>>>>>> but the following should get you started:
>>>>>>
>>>>>>   $ nix-build nixos/tests/strongswan-swanctl.nix
>>>>>>
>>>>>> Note that I also asked this question on the nix-devel mailinglist:
>>>>>>
>>>>>>   https://groups.google.com/forum/#!topic/nix-devel/X-0T97MLR7I
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Bas
>>>>>

Re: [strongSwan] NixOS test

[Bas van Dijk]

I also included the log of a successful test run:

https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925#file-strongswan-swanctl-test-success-log

On 31 August 2017 at 09:09, Bas van Dijk <v.dijk@gmail.com> wrote:
> I noticed that my test succeeds most of the time but I just observed a
> test run where carol keeps trying to ping alice but fails each time.
> The following line from the test log[1] seems suspect:
>
> carol# [ 4.538963] charon-systemd[716]: received NO_PROPOSAL_CHOSEN notify 
> error
>
> I haven't looked into this error yet but I suspect it's a concurrency
> issue. Note that all machines start up at the same time[2]. I think if
> I first start moon, wait for the strongswan-swanctl.service to start
> and then start carol it always succeeds. But I rather not introduce
> that sequentialism and I suspect that strongSwan should be able to
> handle not fully booted gateways and that I just forgot to configure
> some option somewhere.
>
> Any ideas why the test sometimes fails?
>
> [1] https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925
> [2] 
> https://github.com/LumiGuide/nixpkgs/blob/b1bab8cff348ac743ecc6734f1852a16db41a9a2/nixos/tests/strongswan-swanctl.nix#L151
>
> On 30 August 2017 at 11:52, Bas van Dijk <v.dijk@gmail.com> wrote:
>> The test now succeeds[1].
>>
>> Thanks for your help.
>>
>> Bas
>>
>> [1] https://groups.google.com/d/msg/nix-devel/X-0T97MLR7I/cGUCWjXQAAAJ
>>
>> On 30 August 2017 at 02:57, Bas van Dijk <v.dijk@gmail.com> wrote:
>>> On 30 August 2017 at 02:29, Noel Kuntze
>>> <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:
>>>> Two things:
>>>> - Please don't pipe stuff from the web into bash, it just asks for trouble 
>>>> and especially don't advertise or advise people to do it.
>>>
>>> Hi Noel, good point. This should probably be removed from nixos.org/nix.
>>>
>>>> - Try enforcing UDP encapsulation. If the FW rules actually change 
>>>> something, then currently only IKE is allowed, but there's no NAT, so ESP 
>>>> is used as transport protocol.
>>>
>>> Something similar was suggested[1] on the nix-devel mailinglist. I
>>> will see how to get that to work.
>>>
>>> Bas
>>>
>>> [1] https://groups.google.com/forum/#!msg/nix-devel/X-0T97MLR7I/jbPQucPOAAAJ
>>>
>>>> Kind regards
>>>>
>>>> Noel
>>>>
>>>> On 30.08.2017 02:18, Bas van Dijk wrote:
>>>>> I've created a PR for the NixOS Linux distribution that adds a module
>>>>> for strongswan-swanctl:
>>>>>
>>>>>   https://github.com/NixOS/nixpkgs/pull/27958
>>>>>
>>>>> Although the new module works on our company VPN I would also like to
>>>>> add a NixOS test to ensure it keeps working. I've mimicked one of the
>>>>> swanctl tests from the strongswan project:
>>>>>
>>>>>   
>>>>> https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-test/nixos/tests/strongswan-swanctl.nix
>>>>>
>>>>> Although SAs get established successfully between gateway moon and
>>>>> roadwarrior carol I can't seem to ping alice from carol. Since I'm no
>>>>> networking expert I'm probably missing something obvious. It would be
>>>>> great if somebody could give me a tip or point me in the right
>>>>> direction.
>>>>>
>>>>> To run the test for yourself you don't need to install NixOS, you only
>>>>> need the Nix package manager (which is easy to uninstall later on;
>>>>> just rm -r /nix):
>>>>>
>>>>>   $ curl https://nixos.org/nix/install | sh
>>>>>
>>>>> Then clone my nixpkgs fork and checkout the right branch:
>>>>>
>>>>>   $ git clone https://github.com/LumiGuide/nixpkgs.git
>>>>>   $ cd nixpkgs
>>>>>   $ git checkout strongswan-swanctl-test
>>>>>
>>>>> Look in nixos/tests/strongswan-swanctl.nix to see how to run the test
>>>>> but the following should get you started:
>>>>>
>>>>>   $ nix-build nixos/tests/strongswan-swanctl.nix
>>>>>
>>>>> Note that I also asked this question on the nix-devel mailinglist:
>>>>>
>>>>>   https://groups.google.com/forum/#!topic/nix-devel/X-0T97MLR7I
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bas
>>>>

Re: [strongSwan] NixOS test

[Bas van Dijk]

I noticed that my test succeeds most of the time but I just observed a
test run where carol keeps trying to ping alice but fails each time.
The following line from the test log[1] seems suspect:

carol# [ 4.538963] charon-systemd[716]: received NO_PROPOSAL_CHOSEN notify error

I haven't looked into this error yet but I suspect it's a concurrency
issue. Note that all machines start up at the same time[2]. I think if
I first start moon, wait for the strongswan-swanctl.service to start
and then start carol it always succeeds. But I rather not introduce
that sequentialism and I suspect that strongSwan should be able to
handle not fully booted gateways and that I just forgot to configure
some option somewhere.

Any ideas why the test sometimes fails?

[1] https://gist.github.com/basvandijk/a2de93d8c93ce925838c1dbf2ee1d925
[2] 
https://github.com/LumiGuide/nixpkgs/blob/b1bab8cff348ac743ecc6734f1852a16db41a9a2/nixos/tests/strongswan-swanctl.nix#L151

On 30 August 2017 at 11:52, Bas van Dijk <v.dijk@gmail.com> wrote:
> The test now succeeds[1].
>
> Thanks for your help.
>
> Bas
>
> [1] https://groups.google.com/d/msg/nix-devel/X-0T97MLR7I/cGUCWjXQAAAJ
>
> On 30 August 2017 at 02:57, Bas van Dijk <v.dijk@gmail.com> wrote:
>> On 30 August 2017 at 02:29, Noel Kuntze
>> <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:
>>> Two things:
>>> - Please don't pipe stuff from the web into bash, it just asks for trouble 
>>> and especially don't advertise or advise people to do it.
>>
>> Hi Noel, good point. This should probably be removed from nixos.org/nix.
>>
>>> - Try enforcing UDP encapsulation. If the FW rules actually change 
>>> something, then currently only IKE is allowed, but there's no NAT, so ESP 
>>> is used as transport protocol.
>>
>> Something similar was suggested[1] on the nix-devel mailinglist. I
>> will see how to get that to work.
>>
>> Bas
>>
>> [1] https://groups.google.com/forum/#!msg/nix-devel/X-0T97MLR7I/jbPQucPOAAAJ
>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> On 30.08.2017 02:18, Bas van Dijk wrote:
>>>> I've created a PR for the NixOS Linux distribution that adds a module
>>>> for strongswan-swanctl:
>>>>
>>>>   https://github.com/NixOS/nixpkgs/pull/27958
>>>>
>>>> Although the new module works on our company VPN I would also like to
>>>> add a NixOS test to ensure it keeps working. I've mimicked one of the
>>>> swanctl tests from the strongswan project:
>>>>
>>>>   
>>>> https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-test/nixos/tests/strongswan-swanctl.nix
>>>>
>>>> Although SAs get established successfully between gateway moon and
>>>> roadwarrior carol I can't seem to ping alice from carol. Since I'm no
>>>> networking expert I'm probably missing something obvious. It would be
>>>> great if somebody could give me a tip or point me in the right
>>>> direction.
>>>>
>>>> To run the test for yourself you don't need to install NixOS, you only
>>>> need the Nix package manager (which is easy to uninstall later on;
>>>> just rm -r /nix):
>>>>
>>>>   $ curl https://nixos.org/nix/install | sh
>>>>
>>>> Then clone my nixpkgs fork and checkout the right branch:
>>>>
>>>>   $ git clone https://github.com/LumiGuide/nixpkgs.git
>>>>   $ cd nixpkgs
>>>>   $ git checkout strongswan-swanctl-test
>>>>
>>>> Look in nixos/tests/strongswan-swanctl.nix to see how to run the test
>>>> but the following should get you started:
>>>>
>>>>   $ nix-build nixos/tests/strongswan-swanctl.nix
>>>>
>>>> Note that I also asked this question on the nix-devel mailinglist:
>>>>
>>>>   https://groups.google.com/forum/#!topic/nix-devel/X-0T97MLR7I
>>>>
>>>> Cheers,
>>>>
>>>> Bas
>>>

Re: [strongSwan] NixOS test

[Bas van Dijk]

The test now succeeds[1].

Thanks for your help.

Bas

[1] https://groups.google.com/d/msg/nix-devel/X-0T97MLR7I/cGUCWjXQAAAJ

On 30 August 2017 at 02:57, Bas van Dijk <v.dijk@gmail.com> wrote:
> On 30 August 2017 at 02:29, Noel Kuntze
> <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:
>> Two things:
>> - Please don't pipe stuff from the web into bash, it just asks for trouble 
>> and especially don't advertise or advise people to do it.
>
> Hi Noel, good point. This should probably be removed from nixos.org/nix.
>
>> - Try enforcing UDP encapsulation. If the FW rules actually change 
>> something, then currently only IKE is allowed, but there's no NAT, so ESP is 
>> used as transport protocol.
>
> Something similar was suggested[1] on the nix-devel mailinglist. I
> will see how to get that to work.
>
> Bas
>
> [1] https://groups.google.com/forum/#!msg/nix-devel/X-0T97MLR7I/jbPQucPOAAAJ
>
>> Kind regards
>>
>> Noel
>>
>> On 30.08.2017 02:18, Bas van Dijk wrote:
>>> I've created a PR for the NixOS Linux distribution that adds a module
>>> for strongswan-swanctl:
>>>
>>>   https://github.com/NixOS/nixpkgs/pull/27958
>>>
>>> Although the new module works on our company VPN I would also like to
>>> add a NixOS test to ensure it keeps working. I've mimicked one of the
>>> swanctl tests from the strongswan project:
>>>
>>>   
>>> https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-test/nixos/tests/strongswan-swanctl.nix
>>>
>>> Although SAs get established successfully between gateway moon and
>>> roadwarrior carol I can't seem to ping alice from carol. Since I'm no
>>> networking expert I'm probably missing something obvious. It would be
>>> great if somebody could give me a tip or point me in the right
>>> direction.
>>>
>>> To run the test for yourself you don't need to install NixOS, you only
>>> need the Nix package manager (which is easy to uninstall later on;
>>> just rm -r /nix):
>>>
>>>   $ curl https://nixos.org/nix/install | sh
>>>
>>> Then clone my nixpkgs fork and checkout the right branch:
>>>
>>>   $ git clone https://github.com/LumiGuide/nixpkgs.git
>>>   $ cd nixpkgs
>>>   $ git checkout strongswan-swanctl-test
>>>
>>> Look in nixos/tests/strongswan-swanctl.nix to see how to run the test
>>> but the following should get you started:
>>>
>>>   $ nix-build nixos/tests/strongswan-swanctl.nix
>>>
>>> Note that I also asked this question on the nix-devel mailinglist:
>>>
>>>   https://groups.google.com/forum/#!topic/nix-devel/X-0T97MLR7I
>>>
>>> Cheers,
>>>
>>> Bas
>>

Re: [strongSwan] NixOS test

[Bas van Dijk]

On 30 August 2017 at 02:29, Noel Kuntze
<noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:
> Two things:
> - Please don't pipe stuff from the web into bash, it just asks for trouble 
> and especially don't advertise or advise people to do it.

Hi Noel, good point. This should probably be removed from nixos.org/nix.

> - Try enforcing UDP encapsulation. If the FW rules actually change something, 
> then currently only IKE is allowed, but there's no NAT, so ESP is used as 
> transport protocol.

Something similar was suggested[1] on the nix-devel mailinglist. I
will see how to get that to work.

Bas

[1] https://groups.google.com/forum/#!msg/nix-devel/X-0T97MLR7I/jbPQucPOAAAJ

> Kind regards
>
> Noel
>
> On 30.08.2017 02:18, Bas van Dijk wrote:
>> I've created a PR for the NixOS Linux distribution that adds a module
>> for strongswan-swanctl:
>>
>>   https://github.com/NixOS/nixpkgs/pull/27958
>>
>> Although the new module works on our company VPN I would also like to
>> add a NixOS test to ensure it keeps working. I've mimicked one of the
>> swanctl tests from the strongswan project:
>>
>>   
>> https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-test/nixos/tests/strongswan-swanctl.nix
>>
>> Although SAs get established successfully between gateway moon and
>> roadwarrior carol I can't seem to ping alice from carol. Since I'm no
>> networking expert I'm probably missing something obvious. It would be
>> great if somebody could give me a tip or point me in the right
>> direction.
>>
>> To run the test for yourself you don't need to install NixOS, you only
>> need the Nix package manager (which is easy to uninstall later on;
>> just rm -r /nix):
>>
>>   $ curl https://nixos.org/nix/install | sh
>>
>> Then clone my nixpkgs fork and checkout the right branch:
>>
>>   $ git clone https://github.com/LumiGuide/nixpkgs.git
>>   $ cd nixpkgs
>>   $ git checkout strongswan-swanctl-test
>>
>> Look in nixos/tests/strongswan-swanctl.nix to see how to run the test
>> but the following should get you started:
>>
>>   $ nix-build nixos/tests/strongswan-swanctl.nix
>>
>> Note that I also asked this question on the nix-devel mailinglist:
>>
>>   https://groups.google.com/forum/#!topic/nix-devel/X-0T97MLR7I
>>
>> Cheers,
>>
>> Bas
>

[strongSwan] NixOS test

[Bas van Dijk]

I've created a PR for the NixOS Linux distribution that adds a module
for strongswan-swanctl:

  https://github.com/NixOS/nixpkgs/pull/27958

Although the new module works on our company VPN I would also like to
add a NixOS test to ensure it keeps working. I've mimicked one of the
swanctl tests from the strongswan project:

  
https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-test/nixos/tests/strongswan-swanctl.nix

Although SAs get established successfully between gateway moon and
roadwarrior carol I can't seem to ping alice from carol. Since I'm no
networking expert I'm probably missing something obvious. It would be
great if somebody could give me a tip or point me in the right
direction.

To run the test for yourself you don't need to install NixOS, you only
need the Nix package manager (which is easy to uninstall later on;
just rm -r /nix):

  $ curl https://nixos.org/nix/install | sh

Then clone my nixpkgs fork and checkout the right branch:

  $ git clone https://github.com/LumiGuide/nixpkgs.git
  $ cd nixpkgs
  $ git checkout strongswan-swanctl-test

Look in nixos/tests/strongswan-swanctl.nix to see how to run the test
but the following should get you started:

  $ nix-build nixos/tests/strongswan-swanctl.nix

Note that I also asked this question on the nix-devel mailinglist:

  https://groups.google.com/forum/#!topic/nix-devel/X-0T97MLR7I

Cheers,

Bas

Re: [strongSwan] Failure to connect on boot

[Bas van Dijk]

I managed to get charon-systemd to build on NixOS and created a PR to add
it to nixpkgs:

  https://github.com/NixOS/nixpkgs/pull/21872

Next up is writing a NixOS module that actually uses these new tools.

As explained in the commit it would be nice if swanctl could have a command
line option for specifying the configuration file/directory. In NixOS we
want to use /etc as little as possible and put most files in the immutable
nix store instead. But then we do need to tell swanctl to look for its
configuration directory in the nix store.

On 13 January 2017 at 21:49, Bas van Dijk <v.dijk@gmail.com> wrote:

> Thanks Noel.
>
> The NixOS StrongSwan module [1] is based on ipsec. I tried for a few hours
> to get StrongSwan to compile with --enable-systemd --enable-swanctl but
> failed so far. The problem was that libsystemd couldn't be found by
> configure even when I added it as a dependency to Nix's StrongSwan package
> [2].
>
> I currently have a systemd timer that calls "ipsec up ..." at 1 minute
> after boot. Hacky for sure but it works for now.
>
> Hopefully I have some time this weekend to figure out how to get
> StrongSwan to compile with --enable-systemd --enable-swanctl on NixOS.
>
> Cheers,
>
> Bas
>
> [1] https://github.com/NixOS/nixpkgs/blob/master/nixos/
> modules/services/networking/strongswan.nix
> [2] https://github.com/NixOS/nixpkgs/blob/master/pkgs/
> tools/networking/strongswan/default.nix
>
> On 10 January 2017 at 22:16, Noel Kuntze <n...@familie-kuntze.de> wrote:
>
>> On 10.01.2017 14:51, Bas van Dijk wrote:
>> > With the following config running on NixOS, strongswan fails to start
>> (or route) on boot:
>> > I've also found that adding a "sleep 60" before strongswan starts
>> resolves the problem. The connection starts properly when waiting 60
>> seconds.
>> >
>> >
>> > Setting the charonstart to "yes" explicitly has no noticeable effect.
>> Of course, that's deprecated since 5.0.0.
>> >
>> >
>> > How do I get strongswan to connect automatically without sleeping 60
>> seconds or doing it manually in a systemd timer?
>> >
>> >
>>
>> That is because systemd starts ipsec stroke when charon isn't ready yet,
>> so charon has no idea about the conns when your
>> systemd unit tells it to initiate the conn. The whole problem appears
>> because ipsec stroke is an asynchronous API.
>>
>> Use VICI/swanctl. That's a synchronous API and the configuration format
>> is much better. There's also charon-systemd that has
>> a nicer behaviour when used with systemd. If you want to use it, you
>> should use a swanctl (for which you need to rewrite your configuration
>> in swanctl.conf style). That's what I use on all my hosts as well.
>>
>>
>> --
>>
>> Mit freundlichen Grüßen/Kind Regards,
>> Noel Kuntze
>>
>> GPG Key ID: 0x63EC6658
>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>
>>
>>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Failure to connect on boot

[Bas van Dijk]

Thanks Noel.

The NixOS StrongSwan module [1] is based on ipsec. I tried for a few hours
to get StrongSwan to compile with --enable-systemd --enable-swanctl but
failed so far. The problem was that libsystemd couldn't be found by
configure even when I added it as a dependency to Nix's StrongSwan package
[2].

I currently have a systemd timer that calls "ipsec up ..." at 1 minute
after boot. Hacky for sure but it works for now.

Hopefully I have some time this weekend to figure out how to get StrongSwan
to compile with --enable-systemd --enable-swanctl on NixOS.

Cheers,

Bas

[1]
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/strongswan.nix
[2]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/networking/strongswan/default.nix

On 10 January 2017 at 22:16, Noel Kuntze <n...@familie-kuntze.de> wrote:

> On 10.01.2017 14:51, Bas van Dijk wrote:
> > With the following config running on NixOS, strongswan fails to start
> (or route) on boot:
> > I've also found that adding a "sleep 60" before strongswan starts
> resolves the problem. The connection starts properly when waiting 60
> seconds.
> >
> >
> > Setting the charonstart to "yes" explicitly has no noticeable effect.
> Of course, that's deprecated since 5.0.0.
> >
> >
> > How do I get strongswan to connect automatically without sleeping 60
> seconds or doing it manually in a systemd timer?
> >
> >
>
> That is because systemd starts ipsec stroke when charon isn't ready yet,
> so charon has no idea about the conns when your
> systemd unit tells it to initiate the conn. The whole problem appears
> because ipsec stroke is an asynchronous API.
>
> Use VICI/swanctl. That's a synchronous API and the configuration format is
> much better. There's also charon-systemd that has
> a nicer behaviour when used with systemd. If you want to use it, you
> should use a swanctl (for which you need to rewrite your configuration
> in swanctl.conf style). That's what I use on all my hosts as well.
>
>
> --
>
> Mit freundlichen Grüßen/Kind Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Failure to connect on boot

[Bas van Dijk]

Dear all,


With the following config running on NixOS, strongswan fails to start (or
route) on boot:


config setup


conn workstationVpn

  auto=route # Also tried with auto=start

  closeaction=restart

  dpdaction=restart

  keyexchange=ikev2

  leftauth=pubkey

  leftcert=/nix/store/xxx-certificate.der

  leftfirewall=yes

  leftid=f...@bar.com

  leftsourceip=%config4

  right=gateway.bar.com

  rightfirewall=yes

  rightid=gateway.bar.com

  rightsubnet=0.0.0.0/0

ca fooCert

  auto=add

  cacert=/nix/store/yyy-CACertificate.der


IPSec statusall gives the following:


Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.4.39, x86_64):
  uptime: 7 minutes, since Jan 10 14:01:34 2017
  malloc: sbrk 2686976, mmap 266240, used 425584, free 2261392
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 0
  loaded plugins: charon unbound pkcs11 aesni aes des rc2 sha2 sha1 md5
rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7
pkcs8 pkcs12 pgp dnskey sshkey dnscert pem af-alg fips-prf gmp xcbc cmac
hmac attr kernel-netlink resolve socket-default connmark forecast farp
stroke vici updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2
eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2
xauth-generic xauth-eap dhcp
Listening IP addresses:
  192.168.42.223 # wlan local IP
  192.168.42.199 # eth0 local IP
Connections:
workstationVpn:  %any...gateway.bar.com  IKEv2, dpddelay=30s
workstationVpn:   local:  [f...@bar.com] uses public key authentication
workstationVpn:cert:  "C=NL, O=Bar, L=Baz, S=Quux, CN=f...@bar.com"
workstationVpn:   remote: [gateway.bar.com] uses public key authentication
workstationVpn:   child:  dynamic === 0.0.0.0/0 TUNNEL, dpdaction=restart
Security Associations (0 up, 0 connecting):
  none



Even with all logging options set to 3, the journal doesn't seem to mention
anything about even trying to route or start the connection.


After a clean boot, the following lists shows some commands and their
effects:


systemctl restart strongswan - Both restarts strongswan and actually starts
the connection without errors or problems.

ipsec up workstationVpn - Starts the connection, without any errors or
problems.

ipsec reload - Starts the connection, but somehow *all* packages appear to
be routed through the VPN connection, rather than those in the subnets that
the server advertises. This persists until either rebooting or stopping
(not restarting) strongswan.


I've also found that adding a "sleep 60" before strongswan starts resolves
the problem. The connection starts properly when waiting 60 seconds.


Setting the charonstart to "yes" explicitly has no noticeable effect.


How do I get strongswan to connect automatically without sleeping 60
seconds or doing it manually in a systemd timer?


Regards,


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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

On 26 April 2015 at 23:46, Miroslav Svoboda goodmi...@goodmirek.cz wrote:
 Huh, it is a bit complicated.
 Routing table 220 empty... is not good most probably, but cannot help to fix
 it.

Routing table 220 is probably empty because strongswan fails to add a
route to it because of the Network is unreachable (101) error. Which
is the same error I get when I try to add the route manually.

 I would need to see configuration and packet dump to understand what packets
 go from where to there.

My network configuration boils down to the following sequence of commands:

ip link set eth0 up

ip addr add 136.243.25.125/32 dev eth0
ip addr add 136.243.25.108/32 dev eth0
ip addr add 172.16.48.17/28 dev eth0
ip addr add 136.243.17.41/26 dev eth0

ip route add default via 136.243.17.1

ip -6 addr add '2a01:4f8:211:2aa8::/64' dev 'eth0'
ip -4 route change '136.243.17.0/26' via '136.243.17.1' dev 'eth0'
ip -6 route add default via 'fe80::1' dev eth0

I'll look into making a packet dump.

 Anyway, it looks strange to me to route traffic into my own physical segment
 via gateway: 136.243.17.0/26 via 136.243.17.1 dev eth0
 But it will probably not help you.

I'm running my machine in a Hetzner data center where it's required to
route all traffic (including traffic to my own subnet) to the gateway.
(See: http://wiki.hetzner.de/index.php/Netzkonfiguration_Debian/en)

I also tried deleting that route and trying again but I got the same error:

# ip route del 136.243.17.0/26 via 136.243.17.1 dev eth0
# ip route add  10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
RTNETLINK answers: Network is unreachable

 Did you try to use lo:0 instead of eth0 for all you loopback addresses?

Adding it to lo yields the same error:

# ip addr add 172.16.48.17/28 dev lo
# ip route add 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
RTNETLINK answers: Network is unreachable

Cheers,

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

I just discovered that I can successfully manually add the route if I
leave of the via gateway option:

# ip route add  10.180.0.0/24 src 172.16.48.17 dev eth0

After this I can successfully ping hosts on the other side of the VPN!

So I think I just add this manual route addition to my startup scripts
and be done with it.

Cheers,

Bas

On 27 April 2015 at 11:42, Bas van Dijk v.dijk@gmail.com wrote:
 On 26 April 2015 at 23:46, Miroslav Svoboda goodmi...@goodmirek.cz wrote:
 Huh, it is a bit complicated.
 Routing table 220 empty... is not good most probably, but cannot help to fix
 it.

 Routing table 220 is probably empty because strongswan fails to add a
 route to it because of the Network is unreachable (101) error. Which
 is the same error I get when I try to add the route manually.

 I would need to see configuration and packet dump to understand what packets
 go from where to there.

 My network configuration boils down to the following sequence of commands:

 ip link set eth0 up

 ip addr add 136.243.25.125/32 dev eth0
 ip addr add 136.243.25.108/32 dev eth0
 ip addr add 172.16.48.17/28 dev eth0
 ip addr add 136.243.17.41/26 dev eth0

 ip route add default via 136.243.17.1

 ip -6 addr add '2a01:4f8:211:2aa8::/64' dev 'eth0'
 ip -4 route change '136.243.17.0/26' via '136.243.17.1' dev 'eth0'
 ip -6 route add default via 'fe80::1' dev eth0

 I'll look into making a packet dump.

 Anyway, it looks strange to me to route traffic into my own physical segment
 via gateway: 136.243.17.0/26 via 136.243.17.1 dev eth0
 But it will probably not help you.

 I'm running my machine in a Hetzner data center where it's required to
 route all traffic (including traffic to my own subnet) to the gateway.
 (See: http://wiki.hetzner.de/index.php/Netzkonfiguration_Debian/en)

 I also tried deleting that route and trying again but I got the same error:

 # ip route del 136.243.17.0/26 via 136.243.17.1 dev eth0
 # ip route add  10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
 RTNETLINK answers: Network is unreachable

 Did you try to use lo:0 instead of eth0 for all you loopback addresses?

 Adding it to lo yields the same error:

 # ip addr add 172.16.48.17/28 dev lo
 # ip route add 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
 RTNETLINK answers: Network is unreachable

 Cheers,

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

Hi Miroslav,

On 26 April 2015 at 08:26, Miroslav Svoboda goodmi...@goodmirek.cz wrote:
 Please can you add output of:
 ip route show
 ip route show table 220
 ip xfrm state
 ip a

Here you go:

# ip route show
default via 136.243.17.1 dev eth0
136.243.17.0/26 via 136.243.17.1 dev eth0
172.16.48.16/28 dev eth0  proto kernel  scope link  src 172.16.48.17

# ip route show table 220

# ip xfrm state
src 136.243.25.108 dst 213.163.70.4
  proto esp spi 0x700e6b6c reqid 1 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha1) 0x6d969125d32fd66fb899abfc60c4328be1404c03 96
  enc cbc(aes) 0xd5562d5113dfc4a8b9a0679990282860
src 213.163.70.4 dst 136.243.25.108
  proto esp spi 0xc15e6adb reqid 1 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha1) 0xf2be74d8b38d26fc2e2ee3adb1ccb59a4d06ff09 96
  enc cbc(aes) 0x1c6770d03daa3fa8a317fb7f22d144c8

# ip a
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 44:8a:5b:d8:85:8c brd ff:ff:ff:ff:ff:ff
inet 136.243.25.125/32 scope global eth0
   valid_lft forever preferred_lft forever
inet 136.243.25.108/32 scope global eth0
   valid_lft forever preferred_lft forever
inet 172.16.48.17/28 scope global eth0
   valid_lft forever preferred_lft forever
inet 136.243.17.41/26 scope global eth0
   valid_lft forever preferred_lft forever

 Are you able to successfully do:
 ip route add 10.180.0.0/24 via 172.16.48.17
 ?

Yes:

# ip route add 10.180.0.0/24 via 172.16.48.17

# ip route
default via 136.243.17.1 dev eth0
10.180.0.0/24 via 172.16.48.17 dev eth0
136.243.17.0/26 via 136.243.17.1 dev eth0
172.16.48.16/28 dev eth0  proto kernel  scope link  src 172.16.48.17

Thanks for your time,

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

Hello,

I recently changed something in my network setup (I added an IP
address to eth0) and now charon can't add the route to the rightsubnet
(10.180.0.0/24) anymore. This is the relevant log output from the KNL
subsystem:

getting a local address in traffic selector 172.16.48.16/28
using host 172.16.48.17
using 136.243.17.1 as nexthop to reach 213.163.70.4/32
136.243.25.108 is on interface eth0
installing route: 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
getting iface index for eth0
received netlink error: Network is unreachable (101)

If I try to do add the route manually I get the same error:

# ip route add  10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
RTNETLINK answers: Network is unreachable

I don't completely understand the error message. What network is unreachable?

Regards,

Bas


On 21 March 2015 at 12:21, Bas van Dijk v.dijk@gmail.com wrote:
 Hi Tobias,

 I added the address to `eth0` and now strongswan inserts the proper
 route. So I think I'm all set!

 Thanks for your insightful help,

 Bas

 On 20 March 2015 at 18:54, Tobias Brunner tob...@strongswan.org wrote:
 Hi Bas,

 My question now is to which interface should I attach 172.16.48.17?

 It doesn't really matter.  If you don't actually suffer from #197 [1],
 i.e. if you use strongSwan 5.0.1 or newer, you can add it to `lo`.
 Adding it to eth0 does work too, that's what strongSwan does by default
 when it installs virtual IPs it gets assigned dynamically from other
 peers [2].  Routers on the Internet won't route packets with that
 destination address to your host so it doesn't make much of a difference
 if you install it on an interface connected to it or not.

 Regards,
 Tobias

 [1] https://wiki.strongswan.org/issues/197
 [2] https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

Hi Tobias,

I added the address to `eth0` and now strongswan inserts the proper
route. So I think I'm all set!

Thanks for your insightful help,

Bas

On 20 March 2015 at 18:54, Tobias Brunner tob...@strongswan.org wrote:
 Hi Bas,

 My question now is to which interface should I attach 172.16.48.17?

 It doesn't really matter.  If you don't actually suffer from #197 [1],
 i.e. if you use strongSwan 5.0.1 or newer, you can add it to `lo`.
 Adding it to eth0 does work too, that's what strongSwan does by default
 when it installs virtual IPs it gets assigned dynamically from other
 peers [2].  Routers on the Internet won't route packets with that
 destination address to your host so it doesn't make much of a difference
 if you install it on an interface connected to it or not.

 Regards,
 Tobias

 [1] https://wiki.strongswan.org/issues/197
 [2] https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

I forgot to mention that I see the following in the log:

Mar 20 17:36:42 zeus charon[4136]: 14[KNL] getting a local address in
traffic selector 172.16.48.16/28
Mar 20 17:36:42 zeus charon[4136]: 14[KNL] no local address found in
traffic selector 172.16.48.16/28

On 20 March 2015 at 17:48, Bas van Dijk v.dijk@gmail.com wrote:
 Hi Tobias,

 Sorry for the late reply.

 It seems my strongswan doesn't setup the route since `ip route list
 table 220` doesn't show anything. I think I'm suffering from bug:
 https://wiki.strongswan.org/issues/197.

 As a work-around I will try to manually add the route:

   10.180.0.0/16 via default GW dev eth0 proto static src 172.16.48.16

 Cheers,

 Bas

 On 18 February 2015 at 17:03, Tobias Brunner tob...@strongswan.org wrote:
 Hi Bas,

 So am I right that the only thing left to do is configure my system so
 that packets to hosts on the 10.180.0.0/24 subnet appear to come from
 a host on the 172.16.48.16/28 subnet?

 To accomplish this I already added the additional IP address
 172.16.48.16 to my NIC (besides the DHCP configured 192.168.42.162).

 What's the next step? Do I need to add a route or some iptables rule?

 strongSwan should find the address you added to the NIC and install an
 appropriate route to routing table 220 automatically.  You may check
 with `ip route list table 220`.  This route will look similar to this:

   10.180.0.0/16 via default GW dev eth0 proto static src 172.16.48.16

 This should force 172.16.48.16 as source address for packets sent to
 hosts in 10.180.0.0/16.  (Depending on how the other peer is configured
 you might want to try a different IP from your source subnet e.g. .17,
 because .16 is the network ID, while .31 is the broadcast address).

 Regards,
 Tobias

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

I think I understand what I'm doing wrong: strongswan only inserts a
route if a local IP address can be found in the subnet
172.16.48.16/28. I currently don't have an IP address in that subnet
assigned to an interface on my system so no route gets installed.

So IIUC to fix this I need to add an IP address within the
172.16.48.16/28 subnet (for example 172.16.48.17) to some interface in
my system.

My question now is to which interface should I attach 172.16.48.17?

I don't think I should attach it to eth0 since that is connected to
the internet and I don't think you should attach local addresses to an
internet connected interface.

Should I create some virtual interface (tun/tap) and attach it to that?

Thanks for bearing with me so far!

Bas


On 20 March 2015 at 17:50, Bas van Dijk v.dijk@gmail.com wrote:
 I forgot to mention that I see the following in the log:

 Mar 20 17:36:42 zeus charon[4136]: 14[KNL] getting a local address in
 traffic selector 172.16.48.16/28
 Mar 20 17:36:42 zeus charon[4136]: 14[KNL] no local address found in
 traffic selector 172.16.48.16/28

 On 20 March 2015 at 17:48, Bas van Dijk v.dijk@gmail.com wrote:
 Hi Tobias,

 Sorry for the late reply.

 It seems my strongswan doesn't setup the route since `ip route list
 table 220` doesn't show anything. I think I'm suffering from bug:
 https://wiki.strongswan.org/issues/197.

 As a work-around I will try to manually add the route:

   10.180.0.0/16 via default GW dev eth0 proto static src 172.16.48.16

 Cheers,

 Bas

 On 18 February 2015 at 17:03, Tobias Brunner tob...@strongswan.org wrote:
 Hi Bas,

 So am I right that the only thing left to do is configure my system so
 that packets to hosts on the 10.180.0.0/24 subnet appear to come from
 a host on the 172.16.48.16/28 subnet?

 To accomplish this I already added the additional IP address
 172.16.48.16 to my NIC (besides the DHCP configured 192.168.42.162).

 What's the next step? Do I need to add a route or some iptables rule?

 strongSwan should find the address you added to the NIC and install an
 appropriate route to routing table 220 automatically.  You may check
 with `ip route list table 220`.  This route will look similar to this:

   10.180.0.0/16 via default GW dev eth0 proto static src 172.16.48.16

 This should force 172.16.48.16 as source address for packets sent to
 hosts in 10.180.0.0/16.  (Depending on how the other peer is configured
 you might want to try a different IP from your source subnet e.g. .17,
 because .16 is the network ID, while .31 is the broadcast address).

 Regards,
 Tobias

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

Hi Tobias,

Sorry for the late reply.

It seems my strongswan doesn't setup the route since `ip route list
table 220` doesn't show anything. I think I'm suffering from bug:
https://wiki.strongswan.org/issues/197.

As a work-around I will try to manually add the route:

  10.180.0.0/16 via default GW dev eth0 proto static src 172.16.48.16

Cheers,

Bas

On 18 February 2015 at 17:03, Tobias Brunner tob...@strongswan.org wrote:
 Hi Bas,

 So am I right that the only thing left to do is configure my system so
 that packets to hosts on the 10.180.0.0/24 subnet appear to come from
 a host on the 172.16.48.16/28 subnet?

 To accomplish this I already added the additional IP address
 172.16.48.16 to my NIC (besides the DHCP configured 192.168.42.162).

 What's the next step? Do I need to add a route or some iptables rule?

 strongSwan should find the address you added to the NIC and install an
 appropriate route to routing table 220 automatically.  You may check
 with `ip route list table 220`.  This route will look similar to this:

   10.180.0.0/16 via default GW dev eth0 proto static src 172.16.48.16

 This should force 172.16.48.16 as source address for packets sent to
 hosts in 10.180.0.0/16.  (Depending on how the other peer is configured
 you might want to try a different IP from your source subnet e.g. .17,
 because .16 is the network ID, while .31 is the broadcast address).

 Regards,
 Tobias

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

On 16 February 2015 at 17:19, Tobias Brunner tob...@strongswan.org wrote:
 As Noel pointed out it could mean the responder doesn't like the
 proposed algorithms.  But the responder could also return this error
 because it doesn't like the proposed traffic selectors (i.e. the subnets
 in `left|rightsubnet`) or the mode (type=tunnel|transport).

Hi Tobias, thanks for your very informative and helpful reply. You
were spot-on with the incomplete traffic selectors. It turned out the
server is configured to only accept traffic from the 172.16.48.16/28
subnet. So after setting:

  leftsubnet = 172.16.48.16/28

I can successfully establish the VPN with the server.

So am I right that the only thing left to do is configure my system so
that packets to hosts on the 10.180.0.0/24 subnet appear to come from
a host on the 172.16.48.16/28 subnet?

To accomplish this I already added the additional IP address
172.16.48.16 to my NIC (besides the DHCP configured 192.168.42.162).

What's the next step? Do I need to add a route or some iptables rule?

Cheers,

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

On 16 February 2015 at 07:59, Bas van Dijk v.dijk@gmail.com wrote:
 So with that esp setting the gateway sends me a DELETE instead of a
 NO_PROPOSAL_CHOSEN.

Mmm I can't seem to reproduce this anymore. Now with or without
esp=aes128-sha! I get a NO_PROPOSAL_CHOSEN response.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

Hi Noel,

Thanks for your help so far.

When setting:

  esp=aes128-sha!

I get the following:

 sudo ipsec up data-display
...
IKE_SA data-display[1] established between
192.168.42.213[83.161.66.130]...213.163.70.4[213.163.70.4]
scheduling reauthentication in 85738s
maximum IKE_SA lifetime 86278s
generating QUICK_MODE request 693888767 [ HASH SA No ID ID ]
sending packet: from 192.168.42.213[4500] to 213.163.70.4[4500] (172 bytes)
received packet: from 213.163.70.4[4500] to 192.168.42.213[4500] (84 bytes)
parsed INFORMATIONAL_V1 request 3364452724 [ HASH D ]
received DELETE for IKE_SA data-display[1]
deleting IKE_SA data-display[1] between
192.168.42.213[83.161.66.130]...213.163.70.4[213.163.70.4]
establishing connection 'data-display' failed

So with that esp setting the gateway sends me a DELETE instead of a
NO_PROPOSAL_CHOSEN.

I also enabled:

charon {
  cisco_unity = yes
  ...
}

but that didn't change anything.

Bas

On 13 February 2015 at 20:43, Noel Kuntze n...@familie-kuntze.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hello Bas,

 You might also want to enable the CISCO unity extension in strongswan by 
 setting charon.cisco_unity = yes
 in strongswan.conf and restart the daemon. For that to work, you also need to 
 have the unity plugin loaded.

 Mit freundlichen Grüßen/Regards,
 Noel Kuntze

 GPG Key ID: 0x63EC6658
 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

 Am 13.02.2015 um 21:17 schrieb Bas van Dijk:
 Hi Noel,

 Thanks for your reply.

 I did already try esp=aes128-sha1! which didn't help. I will try
 esp=aes128-sha! when I'm back at the office.

 Cheers,

 Bas

 On 13 February 2015 at 19:17, Noel Kuntze n...@familie-kuntze.de wrote:

 Hello Bas,

 That usually means that the two peers could not decide on a common cipher 
 proiposal.
 It is likely that the CISCO peer has PFS disabled. The normal cipher 
 proposal for phase two
 on strongSwan is all PFS by default. Try this: esp=aes128-sha1! or 
 esp=aes128-sha!
 That will set the proposal for phase two to only propose AES-cbc-128 and 
 SHA1 in combination
 without PFS.

 Mit freundlichen Grüßen/Regards,
 Noel Kuntze

 GPG Key ID: 0x63EC6658
 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

 Am 13.02.2015 um 16:48 schrieb Bas van Dijk:
  I solved the no netkey IPsec stack detected errors. It turned out
  that the NixOS strongSwan configuration used a modprobe which couldn't
  find the right kernel modules. I fixed that and now it starts up
  without that error. See the log at: http://pastebin.com/ufutkmdC
 
  However, my original problem remains. With the following ipsec.conf:
 
  conn data-display
aggressive=no
auto=add
fragmentation=yes
ike=des-sha1-modp1024
ikelifetime=24h
keyexchange=ikev1
left=%any
leftauth=psk
leftfirewall=yes
leftid=83.161.66.130
lifetime=1h
right=213.163.70.4
rightauth=psk
rightsubnet=10.180.0.0/16
 
  I get the following error:
 
  $ sudo ipsec up data-display
  initiating Main Mode IKE_SA data-display[1] to 213.163.70.4
  generating ID_PROT request 0 [ SA V V V V V ]
  sending packet: from 192.168.42.178[500] to 213.163.70.4[500] (220 bytes)
  received packet: from 213.163.70.4[500] to 192.168.42.178[500] (128 
  bytes)
  parsed ID_PROT response 0 [ SA V V ]
  received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
  received FRAGMENTATION vendor ID
  generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
  sending packet: from 192.168.42.178[500] to 213.163.70.4[500] (244 bytes)
  received packet: from 213.163.70.4[500] to 192.168.42.178[500] (304 
  bytes)
  parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
  received Cisco Unity vendor ID
  received XAuth vendor ID
  received unknown vendor ID: 
  4a:1c:a1:c6:1d:26:60:b5:3f:0b:02:29:da:eb:0e:5a
  received unknown vendor ID: 
  1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
  local host is behind NAT, sending keep alives
  generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
  sending packet: from 192.168.42.178[4500] to 213.163.70.4[4500] (84 
  bytes)
  received packet: from 213.163.70.4[4500] to 192.168.42.178[4500] (84 
  bytes)
  parsed ID_PROT response 0 [ ID HASH V ]
  received DPD vendor ID
  IKE_SA data-display[1] established between
  192.168.42.178[83.161.66.130]...213.163.70.4[213.163.70.4]
  scheduling reauthentication in 85668s
  maximum IKE_SA lifetime 86208s
  generating QUICK_MODE request 384749459 [ HASH SA No ID ID ]
  sending packet: from 192.168.42.178[4500] to 213.163.70.4[4500] (228 
  bytes)
  received packet: from 213.163.70.4[4500] to 192.168.42.178[4500] (84 
  bytes)
  parsed INFORMATIONAL_V1 request 1953095225 [ HASH N(NO_PROP) ]
  received NO_PROPOSAL_CHOSEN error notify
  establishing connection 'data-display' failed
 
  What does NO_PROPOSAL_CHOSEN mean?
 
  Thanks,
 
  Bas
 
  On 10 February 2015 at 16:48, Bas van Dijk v.dijk@gmail.com wrote:
  Hello,
 
  Apologies in advance for the rather long message but I'm

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

BTW is my following understanding of the NO_PROPOSAL_CHOSEN error
correct: strongSwan correcty executes phase 1 of IKE because I see the
message:

IKE_SA data-display[1] established between
  192.168.42.213[83.161.66.130]...213.163.70.4[213.163.70.4]

However, it can't finish phase 2 because the cipher suites that my
strongSwan says it supports (configured with the esp setting) are
not supported by the Cicso gateway on the other end. That is why the
gateway sends the NO_PROPOSAL_CHOSEN message:

received NO_PROPOSAL_CHOSEN error notify

Is there a way to find out which cipher suites the Cisco router
supports? I know that during phase 1 of IKE I get a received
proposals message:

charon[24416]: 08[CFG] received proposals:
  IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
charon[24416]: 08[CFG] configured proposals:
  IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
charon[24416]: 08[CFG] selected proposal:
  IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

Is there something similar for phase 2?

Are there also other tools to debug this problem? I already tried ike-scan:

sudo ike-scan -v -v -v 213.163.70.4

http://pastebin.com/FpwT6xEH

Cheers,

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

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

I solved the no netkey IPsec stack detected errors. It turned out
that the NixOS strongSwan configuration used a modprobe which couldn't
find the right kernel modules. I fixed that and now it starts up
without that error. See the log at: http://pastebin.com/ufutkmdC

However, my original problem remains. With the following ipsec.conf:

conn data-display
  aggressive=no
  auto=add
  fragmentation=yes
  ike=des-sha1-modp1024
  ikelifetime=24h
  keyexchange=ikev1
  left=%any
  leftauth=psk
  leftfirewall=yes
  leftid=83.161.66.130
  lifetime=1h
  right=213.163.70.4
  rightauth=psk
  rightsubnet=10.180.0.0/16

I get the following error:

$ sudo ipsec up data-display
initiating Main Mode IKE_SA data-display[1] to 213.163.70.4
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.42.178[500] to 213.163.70.4[500] (220 bytes)
received packet: from 213.163.70.4[500] to 192.168.42.178[500] (128 bytes)
parsed ID_PROT response 0 [ SA V V ]
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.42.178[500] to 213.163.70.4[500] (244 bytes)
received packet: from 213.163.70.4[500] to 192.168.42.178[500] (304 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: 4a:1c:a1:c6:1d:26:60:b5:3f:0b:02:29:da:eb:0e:5a
received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 192.168.42.178[4500] to 213.163.70.4[4500] (84 bytes)
received packet: from 213.163.70.4[4500] to 192.168.42.178[4500] (84 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received DPD vendor ID
IKE_SA data-display[1] established between
192.168.42.178[83.161.66.130]...213.163.70.4[213.163.70.4]
scheduling reauthentication in 85668s
maximum IKE_SA lifetime 86208s
generating QUICK_MODE request 384749459 [ HASH SA No ID ID ]
sending packet: from 192.168.42.178[4500] to 213.163.70.4[4500] (228 bytes)
received packet: from 213.163.70.4[4500] to 192.168.42.178[4500] (84 bytes)
parsed INFORMATIONAL_V1 request 1953095225 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection 'data-display' failed

What does NO_PROPOSAL_CHOSEN mean?

Thanks,

Bas

On 10 February 2015 at 16:48, Bas van Dijk v.dijk@gmail.com wrote:
 Hello,

 Apologies in advance for the rather long message but I'm new to
 strongSwan and want to include as much information as I think is
 relevant to my problem.

 I'm having some problems using strongSwan-5.2.2 to establish a
 connection to a host on the subnet 10.180.0.0/16 which is behind the
 gateway 213.163.70.4. The IP address of my machine is 192.168.42.162
 and I'm using NAT to access the internet. My public IP address is:
 83.161.66.130. I don't control the 213.163.70.4 gateway and I have
 been told it uses the following settings:

 Target address: 213.163.70.4
 Source address: 83.161.66.130
 IKE SA: Phase 1
 Encryption: AES-128 with SHA-1
 Diffie-hellman: Group 2
 SA lifetime: 86400 seconds
 IKE negotistion mode: Main (non aggressive)
 Pre-shared key:  (censored)
 IPsec proposal: Phase 2
 Encryption: AES-128 with SHA-1
 IPsec type: ESP
 IPsec tunnel lifetime: 3600 seconds

 I set my ipsec.secrets (censored) to:
 213.163.70.4 %any : PSK 0x

 ipsec.conf:
 conn data-display
   aggressive=no
   authby=secret
   auto=add
   esp=aes128-sha1
   fragmentation=yes
   ike=des-sha1-modp1024
   ikelifetime=24h
   keyexchange=ikev1
   left=%any
   leftfirewall=yes
   leftid=83.161.66.130
   lifetime=1h
   right=213.163.70.4
   rightsubnet=10.180.0.0/16

 I noticed from the strongSwan logs that the gateway is a Cisco Unity
 device so I configured strongSwan with --enable-unity. I'm not sure
 that is required.

 When I start stongSwan using sudo systemctl start strongswan I get
 the following log (I'm using logging level 2):

 http://pastebin.com/pC1WYegL

 I'm a bit confused why I get the no netkey IPsec stack detected
 warning since all required[1] kernel options are enabled (either build
 in or as modules). In particular:

 cat /proc/config.gz | gunzip | grep CONFIG_NET_KEY=
 CONFIG_NET_KEY=m

 Since it's a warning I ignore it for a moment and try to start up the
 data-display connection using sudo ipsec up data-display. I get
 the following output:

 initiating Main Mode IKE_SA data-display[1] to 213.163.70.4
 generating ID_PROT request 0 [ SA V V V V V ]
 sending packet: from 192.168.42.162[500] to 213.163.70.4[500] (220 bytes)
 received packet: from 213.163.70.4[500] to 192.168.42.162[500] (128 bytes)
 parsed ID_PROT response 0 [ SA V V ]
 received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
 received FRAGMENTATION vendor ID
 generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
 sending packet: from 192.168.42.162[500] to 213.163.70.4[500] (244 bytes

Re: [strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

Hi Noel,

Thanks for your reply.

I did already try esp=aes128-sha1! which didn't help. I will try
esp=aes128-sha! when I'm back at the office.

Cheers,

Bas

On 13 February 2015 at 19:17, Noel Kuntze n...@familie-kuntze.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hello Bas,

 That usually means that the two peers could not decide on a common cipher 
 proiposal.
 It is likely that the CISCO peer has PFS disabled. The normal cipher proposal 
 for phase two
 on strongSwan is all PFS by default. Try this: esp=aes128-sha1! or 
 esp=aes128-sha!
 That will set the proposal for phase two to only propose AES-cbc-128 and SHA1 
 in combination
 without PFS.

 Mit freundlichen Grüßen/Regards,
 Noel Kuntze

 GPG Key ID: 0x63EC6658
 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

 Am 13.02.2015 um 16:48 schrieb Bas van Dijk:
 I solved the no netkey IPsec stack detected errors. It turned out
 that the NixOS strongSwan configuration used a modprobe which couldn't
 find the right kernel modules. I fixed that and now it starts up
 without that error. See the log at: http://pastebin.com/ufutkmdC

 However, my original problem remains. With the following ipsec.conf:

 conn data-display
   aggressive=no
   auto=add
   fragmentation=yes
   ike=des-sha1-modp1024
   ikelifetime=24h
   keyexchange=ikev1
   left=%any
   leftauth=psk
   leftfirewall=yes
   leftid=83.161.66.130
   lifetime=1h
   right=213.163.70.4
   rightauth=psk
   rightsubnet=10.180.0.0/16

 I get the following error:

 $ sudo ipsec up data-display
 initiating Main Mode IKE_SA data-display[1] to 213.163.70.4
 generating ID_PROT request 0 [ SA V V V V V ]
 sending packet: from 192.168.42.178[500] to 213.163.70.4[500] (220 bytes)
 received packet: from 213.163.70.4[500] to 192.168.42.178[500] (128 bytes)
 parsed ID_PROT response 0 [ SA V V ]
 received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
 received FRAGMENTATION vendor ID
 generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
 sending packet: from 192.168.42.178[500] to 213.163.70.4[500] (244 bytes)
 received packet: from 213.163.70.4[500] to 192.168.42.178[500] (304 bytes)
 parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
 received Cisco Unity vendor ID
 received XAuth vendor ID
 received unknown vendor ID: 4a:1c:a1:c6:1d:26:60:b5:3f:0b:02:29:da:eb:0e:5a
 received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
 local host is behind NAT, sending keep alives
 generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
 sending packet: from 192.168.42.178[4500] to 213.163.70.4[4500] (84 bytes)
 received packet: from 213.163.70.4[4500] to 192.168.42.178[4500] (84 bytes)
 parsed ID_PROT response 0 [ ID HASH V ]
 received DPD vendor ID
 IKE_SA data-display[1] established between
 192.168.42.178[83.161.66.130]...213.163.70.4[213.163.70.4]
 scheduling reauthentication in 85668s
 maximum IKE_SA lifetime 86208s
 generating QUICK_MODE request 384749459 [ HASH SA No ID ID ]
 sending packet: from 192.168.42.178[4500] to 213.163.70.4[4500] (228 bytes)
 received packet: from 213.163.70.4[4500] to 192.168.42.178[4500] (84 bytes)
 parsed INFORMATIONAL_V1 request 1953095225 [ HASH N(NO_PROP) ]
 received NO_PROPOSAL_CHOSEN error notify
 establishing connection 'data-display' failed

 What does NO_PROPOSAL_CHOSEN mean?

 Thanks,

 Bas

 On 10 February 2015 at 16:48, Bas van Dijk v.dijk@gmail.com wrote:
 Hello,

 Apologies in advance for the rather long message but I'm new to
 strongSwan and want to include as much information as I think is
 relevant to my problem.

 I'm having some problems using strongSwan-5.2.2 to establish a
 connection to a host on the subnet 10.180.0.0/16 which is behind the
 gateway 213.163.70.4. The IP address of my machine is 192.168.42.162
 and I'm using NAT to access the internet. My public IP address is:
 83.161.66.130. I don't control the 213.163.70.4 gateway and I have
 been told it uses the following settings:

 Target address: 213.163.70.4
 Source address: 83.161.66.130
 IKE SA: Phase 1
 Encryption: AES-128 with SHA-1
 Diffie-hellman: Group 2
 SA lifetime: 86400 seconds
 IKE negotistion mode: Main (non aggressive)
 Pre-shared key:  (censored)
 IPsec proposal: Phase 2
 Encryption: AES-128 with SHA-1
 IPsec type: ESP
 IPsec tunnel lifetime: 3600 seconds

 I set my ipsec.secrets (censored) to:
 213.163.70.4 %any : PSK 0x

 ipsec.conf:
 conn data-display
   aggressive=no
   authby=secret
   auto=add
   esp=aes128-sha1
   fragmentation=yes
   ike=des-sha1-modp1024
   ikelifetime=24h
   keyexchange=ikev1
   left=%any
   leftfirewall=yes
   leftid=83.161.66.130
   lifetime=1h
   right=213.163.70.4
   rightsubnet=10.180.0.0/16

 I noticed from the strongSwan logs that the gateway is a Cisco Unity
 device so I configured strongSwan with --enable-unity. I'm not sure
 that is required.

 When I start stongSwan using sudo systemctl start strongswan I get
 the following log (I'm using logging level 2):

 http://pastebin.com/pC1WYegL

 I'm

[strongSwan] Problem connecting to a Cisco Unity gateway

[Bas van Dijk]

Hello,

Apologies in advance for the rather long message but I'm new to
strongSwan and want to include as much information as I think is
relevant to my problem.

I'm having some problems using strongSwan-5.2.2 to establish a
connection to a host on the subnet 10.180.0.0/16 which is behind the
gateway 213.163.70.4. The IP address of my machine is 192.168.42.162
and I'm using NAT to access the internet. My public IP address is:
83.161.66.130. I don't control the 213.163.70.4 gateway and I have
been told it uses the following settings:

Target address: 213.163.70.4
Source address: 83.161.66.130
IKE SA: Phase 1
Encryption: AES-128 with SHA-1
Diffie-hellman: Group 2
SA lifetime: 86400 seconds
IKE negotistion mode: Main (non aggressive)
Pre-shared key:  (censored)
IPsec proposal: Phase 2
Encryption: AES-128 with SHA-1
IPsec type: ESP
IPsec tunnel lifetime: 3600 seconds

I set my ipsec.secrets (censored) to:
213.163.70.4 %any : PSK 0x

ipsec.conf:
conn data-display
  aggressive=no
  authby=secret
  auto=add
  esp=aes128-sha1
  fragmentation=yes
  ike=des-sha1-modp1024
  ikelifetime=24h
  keyexchange=ikev1
  left=%any
  leftfirewall=yes
  leftid=83.161.66.130
  lifetime=1h
  right=213.163.70.4
  rightsubnet=10.180.0.0/16

I noticed from the strongSwan logs that the gateway is a Cisco Unity
device so I configured strongSwan with --enable-unity. I'm not sure
that is required.

When I start stongSwan using sudo systemctl start strongswan I get
the following log (I'm using logging level 2):

http://pastebin.com/pC1WYegL

I'm a bit confused why I get the no netkey IPsec stack detected
warning since all required[1] kernel options are enabled (either build
in or as modules). In particular:

cat /proc/config.gz | gunzip | grep CONFIG_NET_KEY=
CONFIG_NET_KEY=m

Since it's a warning I ignore it for a moment and try to start up the
data-display connection using sudo ipsec up data-display. I get
the following output:

initiating Main Mode IKE_SA data-display[1] to 213.163.70.4
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.42.162[500] to 213.163.70.4[500] (220 bytes)
received packet: from 213.163.70.4[500] to 192.168.42.162[500] (128 bytes)
parsed ID_PROT response 0 [ SA V V ]
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.42.162[500] to 213.163.70.4[500] (244 bytes)
received packet: from 213.163.70.4[500] to 192.168.42.162[500] (304 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: c5:dd:ab:2d:d0:7e:27:16:a3:59:1d:ba:91:49:75:8d
received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 192.168.42.162[4500] to 213.163.70.4[4500] (84 bytes)
received packet: from 213.163.70.4[4500] to 192.168.42.162[4500] (84 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received DPD vendor ID
IKE_SA data-display[1] established between
192.168.42.162[83.161.66.130]...213.163.70.4[213.163.70.4]
scheduling reauthentication in 85593s
maximum IKE_SA lifetime 86133s
generating QUICK_MODE request 3299461263 [ HASH SA No ID ID ]
sending packet: from 192.168.42.162[4500] to 213.163.70.4[4500] (204 bytes)
received packet: from 213.163.70.4[4500] to 192.168.42.162[4500] (84 bytes)
parsed INFORMATIONAL_V1 request 1571124148 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
received packet: from 213.163.70.4[4500] to 192.168.42.162[4500] (84 bytes)
parsed INFORMATIONAL_V1 request 3331205321 [ HASH D ]
received DELETE for IKE_SA data-display[1]
deleting IKE_SA data-display[1] between
192.168.42.162[83.161.66.130]...213.163.70.4[213.163.70.4]
establishing connection 'data-display' failed

The following is posted to syslog:

http://pastebin.com/1Vj1rXaq

So I can see that an IKE_SA is established between me and the gateway.
However, after that something goes wrong.

Can somebody explain what is going wrong and point me in the right direction?

Also note that I'm using NixOS running in VirtualBox. My virtual NIC
is bridged to my physical NIC.

Let me know if any more information is desired.

Cheers,

Bas

[1] https://wiki.strongswan.org/projects/strongswan/wiki/KernelModules
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users