[strongSwan] strongswan xauth
Hi All, I have a question about strongswan xauth. When I use strongswan to get connection with a VPN device, I always get this error"xauth miss match" in peer side, and cannot get connect with that device, I have capture packet, I find that it is because the phase I packet contains draft-beaulieu-ike-xauth-02.txt, so the peer side will consider it has xauth information(of course, it is not right), so will reject this connect. I have check some documents, find thar when I configure the strongswan with "--disable-xauth-vid" this draft-beaulieu-ike-xauth-02.txt will disappear. So I want to check you, is this the perfect solution for this problem? This just disable the function of Xauth? And if I also need this function how can I do? Thanks very much!! Brian phase_I_.pcap Description: phase_I_.pcap ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Deleting connections
Hi Tobias, Tobias Brunner wrote: > Hi Mike, > >> The crash is in thread 08 in the DBG2 processing below, because the thread's >> ike_sa value is set to the now-deleted ike_sa_t. > > That's exactly what happened. The problem is that the IKE_SA is checked > out by one thread and then checked in by another, thus the thread local > IKE_SA is not reset in the thread that checked it out. > I pushed a patch to master that should fix it (see [1]). > > Regards, > Tobias > > [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=dcab9d39 > > > ___ > Users mailing list > Users@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users > Thanks for the quick fix - it has eliminated the crashes. Regards, -mike ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] XFRM for IPv6 ND/NA bypass
Martin, Martin Willi wrote: > Hi Mike, > >> I have these policies installed but the NA always seems to hit the >> strongswan-installed policy rather than my manual ones. > >> src ::/0 dst ::/0 proto ipv6-icmp type 135 code 0 >> dir in priority 1073741824 ptype main >> src ::/0 dst ::/0 proto ipv6-icmp type 136 code 0 >> dir in priority 1073741824 ptype main > >> src ::/0 dst ::/0 proto ipv6-icmp type 135 code 0 >> dir out priority 1073741824 ptype main >> src ::/0 dst ::/0 proto ipv6-icmp type 136 code 0 >> dir out priority 1073741824 ptype main > > The priority value you set is higher than any policy installed by > strongSwan, but a higher priority value actually means a lower > priority ;-). > > Have you tried to install with "prio 1"? I don't have a full IPv6 > network for testing, but at least for ICMP pings it works. > > Regards > Martin > > I could have sworn I tried using a small prio number, but obviously I didn't as it's now working perfectly! Thanks! -mike ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKEv2 PFS disabled
I'm answering this request with copy to the list in case some else wants the configuration. As I said before, notice that PFS has to be disabled on StrongSwan for this to work. Cheers, Alexis. Strongswan: config setup cachecrls=no charonstart=yes crlcheckinterval=0 plutostart=no strictcrlpolicy=no nat_traversal=yes plutodebug=none charondebug="dmn 0, mgr 0, ike 2, chd 0, job 0, cfg 3, knl 2, net 2, enc 0, lib 0" conn to-fortigate4.0 left=192.168.3.47 leftid=@H020109D0206 leftsubnet=172.22.0.0/24 leftnexthop=192.168.2.128 leftfirewall=yes right=XX.XX.XX.95 rightsubnet=10.0.0.0/24 ike=aes128-md5-modp1536! esp=aes128-md5! keyexchange=ikev2 mobike=no ikelifetime=60m keylife=20m compress=no authby=secret dpdaction=restart dpddelay=10 dpdtimeout=30 auto=add keyingtries=1 rekeymargin=3m forceencaps=no reauth=yes Fortigate: config vpn ipsec phase1-interface edit "omg-p1" set type dynamic set interface "wan1" set ike-version 2 set proposal aes128-md5 set psksecret ENC wYvCBAv7cFED5aApm22Ps1hhGZr5pZ4gnAYth7T+a7bN6TVrX9qlZR6gzP6T8JyOQ7zzHZGZR5biQJoHDU4Kz172t5AO0xyVr5zX88g57PwQv+BM next end config vpn ipsec phase2-interface edit "omg-p2" set phase1name "omg-p1" set proposal aes128-md5 set replay disable set dst-subnet 172.22.0.0 255.255.255.0 set src-subnet 10.0.0.0 255.255.255.0 next end config firewall policy edit 1 set srcintf "internal" set dstintf "wan1" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ANY" set nat enable next edit 2 set srcintf "internal" set dstintf "omg-p1" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ANY" next edit 3 set srcintf "omg-p1" set dstintf "internal" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ANY" next end Cheers, Alexis -Original Message- From: Nicole Hähnel [mailto:m...@nicole-haehnel.de] Sent: 28-Feb-11 06:21 To: Alexis Salinas Subject: Re: [strongSwan] IKEv2 PFS disabled Hi, we are also trying to connect a FortiGate 50B to our strongswan gateway with ikev2. But we are not able to bring the tunnel up until now. Can you please provide us your FortiGate vpn and firewall configs? Thanks in advance! Nicole Am 13.12.2010 19:04, schrieb Alexis Salinas: > Thank you both very much for your quick answer, I'll certainly report this to > Fortinet as I already have a ticket open with them. And if you think it could > be of any help, I can report back when they fix the bug. Just to confirm, by > disabling PFS on the Fortigate, everything works. > > Thank you, > Alexis > > > > -Original Message- > From: Martin Willi [mailto:mar...@strongswan.org] > Sent: December-13-10 12:52 AM > To: Alexis Salinas > Cc: users@lists.strongswan.org > Subject: Re: [strongSwan] IKEv2 PFS disabled > > Hi Alexis, > >> esp=aes128-md5-modp1536! >> pfs=yes > The pfs keyword is not used for IKEv2 connections. If the esp proposal > contains a DH group, a DH exchange is done for CREATE_CHILD_SA > exchanges. > >> ike 0:omg-p1:64:omg-p2:962: incoming proposal: >> ike 0:omg-p1:64:omg-p2:962: proposal id = 1: >> ike 0:omg-p1:64:omg-p2:962: protocol = ESP: >> ike 0:omg-p1:64:omg-p2:962: encapsulation = TUNNEL >> ike 0:omg-p1:64:omg-p2:962: type=ENCR, val=AES_CBC (key_len = 128) >> ike 0:omg-p1:64:omg-p2:962: type=INTEGR, val=MD5 >> ike 0:omg-p1:64:omg-p2:962: PFS is disabled >> ike 0:omg-p1:64:omg-p2:962: my proposal: >> ike 0:omg-p1:64:omg-p2:962: proposal id = 1: >> ike 0:omg-p1:64:omg-p2:962: protocol = ESP: >> ike 0:omg-p1:64:omg-p2:962: encapsulation = TUNNEL >> ike 0:omg-p1:64:omg-p2:962: type=ENCR, val=AES_CBC (key_len = 128) >> ike 0:omg-p1:64:omg-p2:962: type=INTEGR, val=MD5 >> ike 0:omg-p1:64:omg-p2:962: type=DH_GROUP, val=1536 >> ike 0:omg-p1:64:omg-p2:962: lifetime=1800 >> ike 0:omg-p1:64:omg-p2:962: no proposal chosen > Fortigate expects a DH group in the piggy-packed CHILD_SA creation in > IKE_AUTH. This seems wrong to me. As we have done a DH exchange in > IKE_SA_INIT, it does not make much sense to repeat one in IKE_AUTH. > > End of section 1.2 RFC5996 says: > >> Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. >> Thus, the SA payloads in the
Re: [strongSwan] Deleting connections
Hi Mike, > The crash is in thread 08 in the DBG2 processing below, because the thread's > ike_sa value is set to the now-deleted ike_sa_t. That's exactly what happened. The problem is that the IKE_SA is checked out by one thread and then checked in by another, thus the thread local IKE_SA is not reset in the thread that checked it out. I pushed a patch to master that should fix it (see [1]). Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=dcab9d39 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] XFRM for IPv6 ND/NA bypass
Hi Mike, > I have these policies installed but the NA always seems to hit the > strongswan-installed policy rather than my manual ones. > src ::/0 dst ::/0 proto ipv6-icmp type 135 code 0 > dir in priority 1073741824 ptype main > src ::/0 dst ::/0 proto ipv6-icmp type 136 code 0 > dir in priority 1073741824 ptype main > src ::/0 dst ::/0 proto ipv6-icmp type 135 code 0 > dir out priority 1073741824 ptype main > src ::/0 dst ::/0 proto ipv6-icmp type 136 code 0 > dir out priority 1073741824 ptype main The priority value you set is higher than any policy installed by strongSwan, but a higher priority value actually means a lower priority ;-). Have you tried to install with "prio 1"? I don't have a full IPv6 network for testing, but at least for ICMP pings it works. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
