Re: Simple IPSEC client with certificate - phase 1 time out

[Frank Wille <frank%phoenix.owl.de@localhost>]

Brett Lymn wrote:

> Well, there is a chance that the negotiation was failing due to packets
> not going where you expect.  That doesn't appear to be happening but
> checking the simple things can't hurt and can save a lot of grief :)

Sure. I will do what I can. Thanks for your detailed analyzation, BTW.


>> [VPN-Status] 2016/03/01 11:52:07,121
>> IKE info: Phase-1 [responder] for peer VPNCLIENT15EF90 initiator id
>> [...]
>
> This is good - we have a phase 1 done here, note the initiator and
> responder cookies match the SPI numbers from the NetBSD side.  Looking
> good at this point.

Besides that IKE mode config is not requested by the NetBSD client, although
explicitely stated in the racoon.conf.


>> [VPN-Status] 2016/03/01 11:52:27,223
>> IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer
>> VPNCLIENT15EF90 Seq-Nr 0xe8, expected 0xe8
>
>> 
>> [VPN-Status] 2016/03/01 11:52:27,224
>> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer
>> VPNCLIENT15EF90, sequence nr 0xe8
>
>
> OK and here is where things fall apart.  The client sends an "are you
> there" request and vpn server sends a reply but it seems like the
> packet did not get through and then things go bad from there...

What makes you think so? Looking at the tcpdump directly from the NetBSD
client shows that the ACK from the Lancom router arrived (those were the
only packets at 11:52:27):

11:52:27.567012 IP 192.168.1.5.4500 > 1.2.3.4.4500: NONESP-encap: isakmp:
phase 2/others I inf[E]
11:52:27.609318 IP 1.2.3.4.4500 > 192.168.1.5.4500: NONESP-encap: isakmp:
phase 2/others R inf[E]

IMHO, DPD works fine.


>> [VPN-Status] 2016/03/01 11:52:37,096
>> VPN: connection for VPNCLIENT15EF90 (91.56.237.127) timed out: no
>> response

BTW, this timeout is always 30 seconds after phase1 has been established. No
matter what I do. With of without DPD. With or without mode_cfg.


> OK so what we can see here is that there seems to be some packet loss
> that is causing the NetBSD client to wait for an answer but during that
> time the vpn server decides nothing is happening and tears the
> connection down.  So, some things to consider:

I'm not so sure about that packet loss. The only possible packet loss, which
Greg already noticed in a parallel thread on tech-net, seems to be with
NAT-T keepalive. But a test with a working Windows client using the same
certificate on the same LAN showed that those keepalive messages are not
replied either.


> 0) How reliable is the internet connection on the client side?  It
> seems these days there is an assumption the connection is fast.

ADSL with approx. 6 MBit down and 1 MBit up. But our DSLAM is already
capable of 50 or 100 MBit, and only 30m away.

I do not remember having any reliability problems.


> 1) Since one side is doing NAT-T, do you have port forwarding on the
> router so that the IKE packets (udp 500 and 4500) are forwarded back to
> the vpn client?  Though it seems you must already have this right to
> get the phase 1 done...

That's an interesting question. No, I don't have port forwarding enabled. Do
I really need that? I thought one of the reasons for using NAT-T is to work
around such problems?

But, as you said, I see UDP 500 and 4500 packets coming through on both
sides, and the Windows client is working over the same router. So I guess
everything is fine...


> 2) any firewall rules blocking the incoming traffic?  Again, just check
> though it doesn't make much sense give you have managed to get so far
> along.

My home router is a Soekris running NetBSD. A few days ago I added the
following ipf rules:

pass in quick proto 4 from any to any  
pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto udp from any port = 500 to any port = 500  
pass in quick proto udp from any port = 4500 to any port = 4500
pass out quick proto 4 from any to any  
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto udp from any port = 500 to any port = 500  
pass out quick proto udp from any port = 4500 to any port = 4500

But I don't think they are required, as the Windows VPN-client worked
without. Now I did:

pass in from any to any
pass out from any to any

...for a test. But it didn't change anything. So I don't think there is a
firewall problem.


> 3) some firewalls/routers don't like large udp packets, there are some
> racoon settings for fragmenting packets - perhaps you need those.

I already had "ike_frag on" in my config. Now I also added "esp_frag 552",
without making any difference.

My current racoon.conf:

path include "/etc/racoon";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";

# "log" specifies logging level.  It is followed by either "notify", "debug"
# or "debug2".
log debug;

#timer
#{
#   natt_keepalive 15 seconds;
#}

remote "wpsd"
{
    remote_address 1.2.3.4;
    exchange_mode main,base;

    my_identifier asn1dn;
    #peers_identifier asn1dn;
    #verify_identifier on;

    certificate_type x509 "vpnclient15.crt" "vpnclient15.key";
    ca_type x509 "ca.crt";

    mode_cfg on;    # ISAKMP mode config
    dpd_delay 20;   # peer detection (alive check)
    nat_traversal on;   # force

    ike_frag on;
    esp_frag 552;
    script "phase1-up.sh" phase1_up;
    script "phase1-down.sh" phase1_down;
    lifetime time 8 hour;

    # phase 1 proposal (for ISAKMP SA)
    proposal {
        encryption_algorithm aes;
        hash_algorithm md5;
        authentication_method rsasig;
        dh_group 2;
    }

    proposal_check obey;
}

# phase 2 proposal (for IPsec SA).
# actual phase 2 proposal will obey the following items:
# - kernel IPsec policy configuration (like "esp/transport//use)
# - permutation of the crypto/hash/compression algorithms presented below
sainfo anonymous
{
    pfs_group 2;
    lifetime time 8 hour;
    encryption_algorithm aes;
    authentication_algorithm hmac_md5;
    compression_algorithm deflate;
}


Unfortunately "log debug" doesn't work at all. I get no debug messages out
of racoon.

Also I'm getting doubt whether "authentication_method rsasig" is working at
all. Until now I found no success stories with such a configuration on the
net, especially when using mode_cfg.

Did anybody ever use "rsasig"?

-- 
Frank Wille