[Openswan Users]
Cannot connect XP SP2 roadwarrior to server - any known issues?
Marcus Blomenkamp
mblomenk at gmx.de
Thu Sep 16 22:17:51 CEST 2004
Hi there,
i have serious problems connecting a client machine with fresh Windows XP SP2
installation to my roaming server. My IPSec setup is without any fancy
features, just plain tunnels to roaming server with PSK authentication, no
NAT-T, no certs etc.
Client side configuration is done from within management console completely.
The previous installation (still available *g*) is XP SP1a and works
flawlessly. To ease porting IPSec settings from old to new setup i made a
configuration snapshot of the IPSec polices.
Importing this snapshot into SP2 works fine. I can get a connection to my
roaming server as always, however no packets can trespass the created tunnel.
On server side nothing abnormal is visible - the only difference is a notion
of additional vendor tags ignored.
Firsts tests have been run against openswan-2.0.x, now i'm using
strongswan-2.2.0 with no change in behaviour.
Appended are log screenshots taken during testing with status output looking
quite scattered (this cleans up after a few seconds but not shown here).
Are there any known issues regarding interoperability with SP2? Is NAT-T
required on server side?
Server is configured from commandline without help of config file. The
following commands are used to setup pluto:
ipsec pluto --ctlbase /tmp/pluto --secretsfile /tmp/pluto/secrets \
--uniqueids --stderrlog 2> /tmp/pluto.log
ipsec whack --listen
ipsec whack --name gate --host 0.0.0.0 \
--to --host 192.168.2.10 --nexthop 192.168.2.10 --client 0.0.0.0/0 \
--encrypt --psk --pfs
BTW: server is plain 2.6.8.1 running as UML guest.
Thanks for any hints,
Marcus
root at debian:~/opt# ipsec whack --statusall
000 interface eth0/eth0 10.0.2.20
000 interface eth1/eth1 192.168.2.10
000 interface lo/lo 127.0.0.1
000 %myid = (none)
000 debug none
000
000 "gate": 0.0.0.0/0===192.168.2.10---192.168.2.10...%any; unrouted; eroute
owner: #0
000 "gate": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 3
000 "gate": policy: PSK+ENCRYPT+TUNNEL+PFS; prio: 0,32; interface: eth1;
000 "gate": newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "gate"[1]: 0.0.0.0/0===192.168.2.10---192.168.2.10...192.168.2.100;
prospective erouted; eroute owner: #0
000 "gate"[1]: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 3
000 "gate"[1]: policy: PSK+ENCRYPT+TUNNEL+PFS; prio: 0,32; interface: eth1;
000 "gate"[1]: newest ISAKMP SA: #7; newest IPsec SA: #8;
000 "gate"[1]: IKE algorithm newest: 3DES_CBC_192-SHA-MODP1024
000
000 #2: "gate"[1] 192.168.2.100 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_EXPIRE in 219s
000 #2: "gate"[1] 192.168.2.100 esp.226eca46 at 192.168.2.100
esp.43cd58a6 at 192.168.2.10 tun.0 at 192.168.2.100 tun.0 at 192.168.2.10
000 #1: "gate"[1] 192.168.2.100 STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 1748s
000 #4: "gate"[1] 192.168.2.100 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 280s
000 #4: "gate"[1] 192.168.2.100 esp.673eec6b at 192.168.2.100
esp.21b72cfa at 192.168.2.10 tun.0 at 192.168.2.100 tun.0 at 192.168.2.10
000 #6: "gate"[1] 192.168.2.100 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 441s
000 #6: "gate"[1] 192.168.2.100 esp.f1f7772 at 192.168.2.100
esp.cdd2e7d9 at 192.168.2.10 tun.0 at 192.168.2.100 tun.0 at 192.168.2.10
000 #5: "gate"[1] 192.168.2.100 STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 2240s
000 #8: "gate"[1] 192.168.2.100 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 774s; newest IPSEC; eroute owner
000 #8: "gate"[1] 192.168.2.100 esp.bfbc0c7f at 192.168.2.100
esp.6928434f at 192.168.2.10 tun.0 at 192.168.2.100 tun.0 at 192.168.2.10
000 #7: "gate"[1] 192.168.2.100 STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 2574s; newest ISAKMP
/tmp/pluto.log
packet from 192.168.2.100:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY
00000004]
packet from 192.168.2.100:500: ignoring Vendor ID payload [FRAGMENTATION]
packet from 192.168.2.100:500: ignoring Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n]
packet from 192.168.2.100:500: ignoring Vendor ID payload
[26244d38eddb61b3172a36e3d0cfb819]
"gate"[1] 192.168.2.100 #7: responding to Main Mode from unknown peer
192.168.2.100
"gate"[1] 192.168.2.100 #7: Peer ID is ID_IPV4_ADDR: '192.168.2.100'
"gate"[1] 192.168.2.100 #7: sent MR3, ISAKMP SA established
"gate"[1] 192.168.2.100 #8: responding to Quick Mode
"gate"[1] 192.168.2.100 #8: IPsec SA established {ESP=>0xbfbc0c7f <0x6928434f}
More information about the Users
mailing list