Discussion:
racoon with rsasig and mode_cfg
(too old to reply)
Frank Wille
2016-03-02 16:13:00 UTC
Permalink
Hi!

Based on my previous thread to get an IPSec connection with a Lancom router
I did now set up a remote NetBSD router as VPN server (epia). It offers the
"rsasig" authentication method, IKE mode config and the same encryption
algorithms to simulate the Lancom.

Here is the racoon.conf of my VPN server: "epia". It has a WAN (dynamic
ADSL) and a LAN (192.168.0.0/24) interface.

---8<---
path certificate "/etc/racoon/certs";

log debug;

listen {
adminsock disabled;
}

remote anonymous {
exchange_mode main;

certificate_type x509 "vpngw_crt.pem" "vpngw_key.pem";
ca_type x509 "democa.pem";

my_identifier asn1dn;
peers_identifier asn1dn;
verify_identifier on;

generate_policy on;
nat_traversal on;
ike_frag on;
dpd_delay 20;
lifetime time 8 hour;
passive on;

proposal {
encryption_algorithm aes;
hash_algorithm md5;
authentication_method rsasig;
dh_group 2;
}
proposal_check claim;
}

mode_cfg {
# starting address of pool
network4 192.168.0.90;
# maximum number of clients
pool_size 10;
netmask4 255.255.255.0;
auth_source system;
dns4 192.168.0.254;
banner "/etc/racoon/motd";
}

sainfo anonymous {
pfs_group 2;
lifetime time 8 hour;
encryption_algorithm aes;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
---8<---


My PowerBook is a NetBSD/macppc notebook in a 192.168.1.0/24 WLAN, using a
Soekris NetBSD router (LAN, WLAN, WAN dynamic ADSL) as default gateway and
name server.

----------- ----------- --------
|PowerBook|====| Soekris | ==> ( Internet ) <== | Epia |
----------- ----------- --------
192.168.1.5 192.168.1.1 192.168.0.254
91.56.255.78 78.49.97.71

When all works well the PowerBook should get an internal VPN address between
192.168.0.90 and 192.168.0.99 inside the remote LAN.

The PowerBook's (192.168.1.5) racoon.conf is similar to the previous Lancom
test:

---8<---
path include "/etc/racoon";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";

remote "epia"
{
remote_address 78.49.97.71;
exchange_mode main,base;

my_identifier asn1dn;
#peers_identifier asn1dn;
#verify_identifier on;

certificate_type x509 "client1crt.pem" "client1key.pem";
ca_type x509 "epiaCA.pem";

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;
}

sainfo anonymous
{
pfs_group 2;
lifetime time 8 hour;
encryption_algorithm aes;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
---8<---

Unfortunately I cannot use epia.mydomain.tld but have to insert the current
dynamic IP every time, which is really stupid. :|


When the racoon daemon is running on both sides and I start the IPSec
connection on the PowerBook with
# racoonctl vc 78.49.97.71

... then phase 1 and the certificates seem to be ok. But it just sits there
and does nothing. racoonctl never returns, and when I break it, it makes no
difference for the connection either.

The client does not request IKE mode config from the server, exactly like in
the previous thread with the Lancom.

I see no phase 2 negotiation. No idea what it is waiting for... :(


Soekris and Epia tcpdumps, as well as PowerBook and Epia racoon logs
attached (I tried to sync the clocks, but better than 0.2s was impossible).

What am I missing? Did "rsasig" and/or "mode_cfg" ever work for anybody?
--
Frank Wille
Frank Wille
2016-03-03 13:42:23 UTC
Permalink
Hi again,

today I successfully made a mode_cfg rsasig IPsec connection with my NetBSD
VPN gateway. But not with a NetBSD Roadwarrior client, but using the
commercial "Lancom Advanced VPN Client" under Windows.

Perhaps that leads to the conclusion that I'm not doing everything wrong,
but that we have a long-time bug in Racoon!

Seems that Racoon never worked with "authentication_mode rsasig" and
"mode_cfg on", when used as a Roadwarrior client. When anybody sees a
working example anywhere then please tell me! ;)


For comparison I attached the racoon log and the tcpdump from my VPN
gateway. The difference to a NetBSD client starts after "ISAKMP-SA
established":

Mar 3 13:49:34 epia racoon: INFO: Using port 0
Mar 3 13:49:34 epia racoon: WARNING: Ignored attribute 20002
Mar 3 13:49:34 epia racoon: WARNING: Ignored attribute 20003
Mar 3 13:49:34 epia racoon: WARNING: Ignored attribute 20004
Mar 3 13:49:34 epia racoon: WARNING: Ignored attribute 20005
Mar 3 13:49:34 epia racoon: INFO: respond new phase 2 negotiation:
77.181.56.246[4500]<=>91.56.248.239[6182]

"Using port 0" means IKE mode config. And the Windows client also starts the
phase 2 negotiation, while the NetBSD client does nothing.

This is mode config in the tcpdump (exchange type #6 means ISAKMP_ETYPE_CFG
in the racoon source):

13:49:34.274245 PPPoE [ses 0x17df] IP 91.56.248.239.6182 >
77.181.56.246.4500: NONESP-encap: isakmp: phase 2/others I #6[E]
13:49:34.347221 PPPoE [ses 0x17df] IP 77.181.56.246.4500 >
91.56.248.239.6182: NONESP-encap: isakmp: phase 2/others R #6[E]


In more detail (DEBUG output, with hex-dumps removed for security reasons)
you can see that the Windows-client immediately sends a MODE_CFG packet:

INFO: ISAKMP-SA established 77.181.56.246[4500]-91.56.248.239[6182]
spi:99558d082de065e3:fc9250ac263d19a6
DEBUG: ===
DEBUG: ===
DEBUG: 204 bytes message received from 91.56.248.239[6182] to
77.181.56.246[4500]
DEBUG: compute IV for phase2
DEBUG: phase1 last IV:
DEBUG: hash(md5)
DEBUG: encryption(aes)
DEBUG: phase2 IV computed:
DEBUG: begin decryption.
DEBUG: encryption(aes)
DEBUG: IV was saved for next processing:
DEBUG: encryption(aes)
DEBUG: with key:
DEBUG: decrypted payload by IV:
DEBUG: decrypted payload, but not trimed.
DEBUG: padding len=1
DEBUG: skip to trim padding.
DEBUG: decrypted.
DEBUG: MODE_CFG packet
[...]

While the NetBSD-client does nothing, except a late INITIAL-CONTACT packet,
which Windows sent before "ISAKMP-SA established".

INFO: ISAKMP-SA established 77.181.56.246[4500]-91.56.248.239[2500]
spi:87ff62d4b8b0f4e5:7f3eec686b044b29
DEBUG: ===
DEBUG: ===
DEBUG: 92 bytes message received from 91.56.248.239[2500] to
77.181.56.246[4500]
DEBUG: receive Information.
DEBUG: compute IV for phase2
DEBUG: phase1 last IV:
DEBUG: hash(md5)
DEBUG: encryption(aes)
DEBUG: phase2 IV computed:
DEBUG: begin decryption.
DEBUG: encryption(aes)
DEBUG: IV was saved for next processing:
DEBUG: encryption(aes)
DEBUG: with key:
DEBUG: decrypted payload by IV:
DEBUG: decrypted payload, but not trimed.
DEBUG: padding len=16
DEBUG: skip to trim padding.
DEBUG: decrypted.
DEBUG: IV freed
DEBUG: HASH with:
DEBUG: hmac(hmac_md5)
DEBUG: HASH computed:
DEBUG: hash validated.
DEBUG: begin.
DEBUG: seen nptype=8(hash)
DEBUG: seen nptype=11(notify)
DEBUG: succeed.
[91.56.248.239] INFO: received INITIAL-CONTACT
DEBUG: call pfkey_send_dump
DEBUG: pk_recv: retry[0] recv()
[...]
--
Frank Wille
Loading...