[strongSwan] FQDN usage changed.
Hello, I recently updated a system from 4.3.5 to 5.3.0 ( I know I have to go to 5.3.2) One of the things I noticed is a change in the way the new version is using the FQDN value I configured for the 'right' parameter ( no 'rightid' configured) It used to be that the IP address resulting from the name resolution of the FQDN was used as 'right' and 'rightid'. On 5.3.0 the IP address resulting from the name resolution of the FQDN is used as 'right' and the FQDN itself is used as 'rightid'. Is there a reason for this change? Is there a way to make it behave as it used to? I would rather not have to ask the server side to change what is currently using as ID. Here is the connection output of 'ipsec statusall' for a IKEv2 VPN on 4.3.5: Connections: VPN1: 192.168.1.1...200.X.X.X VPN1: local: [client] uses pre-shared key authentication VPN1: remote: [200.X.X.X] uses any authentication VPN1: child: 172.16.1.0/24 === 10.1.1.0/24 Here is the connection output of 'ipsec statusall' for a IKEv2 VPN on 5.3.0: Connections: VPN1: 192.168.1.1...vpn.example.com IKEv2 VPN1: local: [client] uses pre-shared key authentication VPN1: remote: [vpn.example.com] uses pre-shared key authentication VPN1: child: 172.16.1.0/24 === 10.1.1.0/24 TUNNEL Security Associations (1 up, 0 connecting): VPN1[38]: ESTABLISHED 21 minutes ago, 192.168.1.1[client]...200.X.X.X[vpn.example.com] Thanks, Alexis. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] payload of type AUTH more than 1 times (2) occurred in current message
From: Alexis Salinas Sent: July 14, 2015 12:05 To: Andreas Steffen Subject: RE: [strongSwan] payload of type AUTH more than 1 times (2) occurred in current message Thanks for the reply Andreas. That is what I thought too, but I was wondering if that was allowed. So, thank you for the strong clarification. Do you know if this was allowed in IKEv1 and perhaps these guys just re-use part of their code? As per your request, here are 2 files. One with ike=3 enabled, which didn't show much more detail around the error. On the second fiIe I also enable enc=2 in case that is more useful (you can see the parsing and verification of the message) Let me know if you need anything else. Cheers, Alexis. From: Andreas Steffen [andreas.stef...@strongswan.org] Sent: July 14, 2015 03:12 To: Alexis Salinas; users@lists.strongswan.org Subject: Re: [strongSwan] payload of type AUTH more than 1 times (2) occurred in current message Hi Alexis, it looks as if the 3rd party VPN client sends two AUTH payloads in its IKE_AUTH request. This does not conform with the IKEv2 RFC. Could you send me a strongSwan log file with the log level set to charondebug=ike 3 in ipsec.conf. Best regards Andreas On 07/13/2015 09:23 PM, Alexis Salinas wrote: Hello All, I'm testing strongSwan as a VPN gateway for a 3rd party VPN client. PSK and certificate authentication works fine, but when testing EAP-TLS and I get this error message on the strongSwan side, after the EAP authentication succeeds. Jul 10 16:42:11 debian-vm1-alexis charon: 14[ENC] payload of type AUTH more than 1 times (2) occurred in current message Jul 10 16:42:11 debian-vm1-alexis charon: 14[IKE] message verification failed See attachment for full logs. Here is my strongSwan configuration: # ipsec.conf - strongSwan IPsec configuration file config setup # strictcrlpolicy=yes # uniqueids = no conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 keyexchange=ikev2 conn rw-eap-tls left=10.1.65.147 leftid=o...@test.org leftsubnet=10.99.0.0/24 leftcert=ocmCert.pem leftauth=pubkey leftfirewall=yes rightsourceip=172.22.0.0/24 rightauth=eap-radius rightsendcert=never right=%any auto=add eap_identity=%identity Does any of you know what this is about? what is strongSwan expecting at this point? Looking at the RFC [1] there should be a message type AUTH (message 7). I can enable more logging if needed. Thanks. Alexis. [1] : https://tools.ietf.org/html/rfc7296#section-2.16 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] payload of type AUTH more than 1 times (2) occurred in current message
Hello All, I'm testing strongSwan as a VPN gateway for a 3rd party VPN client. PSK and certificate authentication works fine, but when testing EAP-TLS and I get this error message on the strongSwan side, after the EAP authentication succeeds. Jul 10 16:42:11 debian-vm1-alexis charon: 14[ENC] payload of type AUTH more than 1 times (2) occurred in current message Jul 10 16:42:11 debian-vm1-alexis charon: 14[IKE] message verification failed See attachment for full logs. Here is my strongSwan configuration: # ipsec.conf - strongSwan IPsec configuration file config setup # strictcrlpolicy=yes # uniqueids = no conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 keyexchange=ikev2 conn rw-eap-tls left=10.1.65.147 leftid=o...@test.org leftsubnet=10.99.0.0/24 leftcert=ocmCert.pem leftauth=pubkey leftfirewall=yes rightsourceip=172.22.0.0/24 rightauth=eap-radius rightsendcert=never right=%any auto=add eap_identity=%identity Does any of you know what this is about? what is strongSwan expecting at this point? Looking at the RFC [1] there should be a message type AUTH (message 7). I can enable more logging if needed. Thanks. Alexis. [1] : https://tools.ietf.org/html/rfc7296#section-2.16 ~# tail -f /var/log/daemon.log Jul 10 16:42:10 debian-vm1-alexis charon: 09[NET] received packet: from 10.1.65.126[49300] to 10.1.65.147[500] Jul 10 16:42:10 debian-vm1-alexis charon: 09[NET] waiting for data on sockets Jul 10 16:42:10 debian-vm1-alexis charon: 03[NET] received packet: from 10.1.65.126[49300] to 10.1.65.147[500] (460 bytes) Jul 10 16:42:10 debian-vm1-alexis charon: 03[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_D_IP) N(NATD_S_IP) V V V V ] Jul 10 16:42:10 debian-vm1-alexis charon: 03[ENC] received unknown vendor ID: eb:4c:1b:78:8a:fd:4a:9c:b7:73:0a:68:d5:6d:08:8b Jul 10 16:42:10 debian-vm1-alexis charon: 03[ENC] received unknown vendor ID: c6:1b:ac:a1:f1:a6:0c:c1:08:00:00:00:00:00:00:00 Jul 10 16:42:10 debian-vm1-alexis charon: 03[ENC] received unknown vendor ID: cb:e7:94:44:a0:87:0d:e4:22:4a:2c:15:1f:bf:e0:99 Jul 10 16:42:10 debian-vm1-alexis charon: 03[ENC] received unknown vendor ID: 40:48:b7:d5:6e:bc:e8:85:25:e7:de:7f:00:d6:c2:d3:c0:00:00:00 Jul 10 16:42:10 debian-vm1-alexis charon: 03[IKE] 10.1.65.126 is initiating an IKE_SA Jul 10 16:42:10 debian-vm1-alexis charon: 03[IKE] IKE_SA (unnamed)[20] state change: CREATED = CONNECTING Jul 10 16:42:10 debian-vm1-alexis charon: 03[IKE] remote host is behind NAT Jul 10 16:42:10 debian-vm1-alexis charon: 03[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ] Jul 10 16:42:10 debian-vm1-alexis charon: 03[NET] sending packet: from 10.1.65.147[500] to 10.1.65.126[49300] (376 bytes) Jul 10 16:42:10 debian-vm1-alexis charon: 10[NET] sending packet: from 10.1.65.147[500] to 10.1.65.126[49300] Jul 10 16:42:10 debian-vm1-alexis charon: 09[NET] received packet: from 10.1.65.126[49300] to 10.1.65.147[4500] Jul 10 16:42:10 debian-vm1-alexis charon: 09[NET] waiting for data on sockets Jul 10 16:42:10 debian-vm1-alexis charon: 12[NET] received packet: from 10.1.65.126[49300] to 10.1.65.147[4500] (1264 bytes) Jul 10 16:42:10 debian-vm1-alexis charon: 12[ENC] unknown attribute type (20002) Jul 10 16:42:10 debian-vm1-alexis charon: 12[ENC] unknown attribute type (20006) Jul 10 16:42:10 debian-vm1-alexis charon: 12[ENC] unknown attribute type (20007) Jul 10 16:42:10 debian-vm1-alexis charon: 12[ENC] unknown attribute type (20003) Jul 10 16:42:10 debian-vm1-alexis charon: 12[ENC] unknown attribute type (20004) Jul 10 16:42:10 debian-vm1-alexis charon: 12[ENC] unknown attribute type (20005) Jul 10 16:42:10 debian-vm1-alexis charon: 12[ENC] parsed IKE_AUTH request 1 [ V IDi CERT N(INIT_CONTACT) N(HTTP_CERT_LOOK) CERTREQ CPRQ(ADDR MASK DNS NBNS (20002) VER U_BANNER U_SAVEPWD U_DEFDOM (20006) (20007) U_SPLITDNS U_SPLITINC U_NATTPORT U_LOCALLAN U_PFS U_FWTYPE U_BKPSRV (20003) (20004) U_DDNSHOST (20005) U_DDNSHOST) SA No TSi TSr V N(MOBIKE_SUP) ] Jul 10 16:42:10 debian-vm1-alexis charon: 12[IKE] received end entity cert C=CA, O=Test, CN=Client Jul 10 16:42:10 debian-vm1-alexis charon: 12[CFG] looking for peer configs matching 10.1.65.147[%any]...10.1.65.126[172.22.0.101] Jul 10 16:42:10 debian-vm1-alexis charon: 12[CFG] selected peer config 'rw-eap-tls' Jul 10 16:42:10 debian-vm1-alexis charon: 12[IKE] initiating EAP_IDENTITY method (id 0x00) Jul 10 16:42:10 debian-vm1-alexis charon: 12[IKE] processing INTERNAL_IP4_ADDRESS attribute Jul 10 16:42:10 debian-vm1-alexis charon: 12[IKE] processing INTERNAL_IP4_NETMASK attribute Jul 10 16:42:10 debian-vm1-alexis charon: 12[IKE] processing INTERNAL_IP4_DNS attribute Jul 10 16:42:10 debian-vm1-alexis charon: 12[IKE] processing INTERNAL_IP4_NBNS attribute Jul 10 16:42:10 debian-vm1-alexis
[strongSwan] IKE_SA reauth failed with dual link.
Hello all, I have 2 gateways running Linux strongSwan U4.3.5/K2.6.32-526 configured for IKEv2, net-to-net with MOBIKE enabled. Gateway-A, the initiator, has 2 links. Gateway-B the responder, has only one link. These are the IP addresses. gateway-A_link1 = 172.19.78.72 gateway-A_link2 = 10.5.102.102 gateway-B_link1 = 192.168.10.10 Gateway-A uses both links, alternatively, as default link (depending of its location). MOBIKE works beautifully when switching links. Gateway-A can only reach gateway-B using the default route. The problem I'm observing is that if IKE_SA is established on one of gateway-A's link and the link switches before IKE_REAUTH starts, StrongSwan tries (and fails) to initiate the new IKE_SA using the IP address of the initial link. It doesn't matter which link starts, it happens regarding of the direction of the link switch. I also tested another machine in place of gateway-A, running Linux strongSwan U5.1.2/K3.4.11-527, with the same result. Here is an example. The tunnel initially established while gateway-A_link2 was the default route. Default route changed at around 16:00, making gateway-A_link1 the default route. Jul 7 16:22:34 gateway-A charon: 09[IKE] queueing IKE_REAUTH task Jul 7 16:22:34 gateway-A charon: 09[IKE] activating new tasks Jul 7 16:22:34 gateway-A charon: 09[IKE] activating IKE_REAUTH task Jul 7 16:22:34 gateway-A charon: 09[IKE] deleting IKE_SA Net-Net[1] between 172.19.78.72[gateway-A]...192.168.10.10[gateway-B] Jul 7 16:22:34 gateway-A charon: 09[IKE] IKE_SA Net-Net[1] state change: ESTABLISHED = DELETING Jul 7 16:22:34 gateway-A charon: 09[IKE] sending DELETE for IKE_SA Net-Net[1] Jul 7 16:22:34 gateway-A charon: 09[NET] sending packet: from 172.19.78.72[4500] to 192.168.10.10[4500] Jul 7 16:22:34 gateway-A charon: 05[NET] sending packet: from 172.19.78.72[4500] to 192.168.10.10[4500] Jul 7 16:22:34 gateway-A charon: 06[NET] received packet: from 192.168.10.10[4500] to 172.19.78.72[4500] Jul 7 16:22:34 gateway-A charon: 06[NET] waiting for data on raw sockets Jul 7 16:22:34 gateway-A charon: 08[NET] received packet: from 192.168.10.10[4500] to 172.19.78.72[4500] Jul 7 16:22:34 gateway-A charon: 08[IKE] IKE_SA deleted Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_INIT task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_NATD task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_CERT_PRE task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_AUTHENTICATE task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_CERT_POST task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_CONFIG task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_AUTH_LIFETIME task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_MOBIKE task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing CHILD_CREATE task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating new tasks Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_INIT task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_NATD task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_CERT_PRE task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_AUTHENTICATE task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_CERT_POST task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_CONFIG task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating CHILD_CREATE task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_AUTH_LIFETIME task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_MOBIKE task Jul 7 16:22:35 gateway-A charon: 08[IKE] initiating IKE_SA Net-Net[2] to 192.168.10.10 Jul 7 16:22:35 gateway-A charon: 08[IKE] IKE_SA Net-Net[2] state change: CREATED = CONNECTING Jul 7 16:22:35 gateway-A charon: 08[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:35 gateway-A charon: 05[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:35 gateway-A charon: 05[NET] error writing to socket: Operation not permitted Jul 7 16:22:35 gateway-A charon: 08[IKE] queueing CHILD_CREATE task Jul 7 16:22:35 gateway-A charon: 08[IKE] delaying task initiation, exchange in progress Jul 7 16:22:35 gateway-A charon: 08[IKE] IKE_SA Net-Net[1] state change: DELETING = DESTROYING Jul 7 16:22:39 gateway-A charon: 08[IKE] retransmit 1 of request with message ID 0 Jul 7 16:22:39 gateway-A charon: 08[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:39 gateway-A charon: 05[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:39 gateway-A charon: 05[NET] error writing to socket: Operation not permitted Jul 7 16:22:46 gateway-A charon: 09[IKE] retransmit 2 of request with message ID 0 Jul 7 16:22:46 gateway-A charon: 09[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:46 gateway-A charon: 05[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul
Re: [strongSwan] Packets not being encapsulated
Hi Russ, I noticed you are using 'forceencaps=yes', so I think your traffic will not be ESP but UDP port 4500. Do you see any of those packets?+ Cheers, Alexis From: users-bounces+alexis.salinas=inmotiontechnology@lists.strongswan.org [mailto:users-bounces+alexis.salinas=inmotiontechnology@lists.strongswan.org] On Behalf Of Russ Cox Sent: 23-Mar-11 09:52 To: Andreas Steffen Cc: users@lists.strongswan.org Subject: Re: [strongSwan] Packets not being encapsulated Hi Andreas, Thanks for the quick reply! I don't block anything at all outbound on either machine, plus the OUTPUT chain on both is set to ACCEPT I'm not 100% sure I've answered your question - shout back if you need any more info Cheers Russ iptables -nvL ... ... Chain OUTPUT (policy ACCEPT 2137K packets, 16G bytes) pkts bytes target prot opt in out source destination ... - rodney:~# iptables -nvL |grep 192.168.6 0 0 ACCEPT all -- eth2:8 * 192.168.6.0/24 192.168.0.0/24 policy match dir in pol ipsec reqid 16601 proto 50 0 0 ACCEPT all -- * eth2:8 192.168.0.0/24 192.168.6.0/24 policy match dir out pol ipsec reqid 16601 proto 50 -- root@granville:~# iptables -nvL |grep 192.168.0 0 0 ACCEPT all -- eth1 * 192.168.0.0/24 192.168.6.0/24 policy match dir in pol ipsec reqid 16385 proto 50 7607 647K ACCEPT all -- * eth1 192.168.6.0/24 192.168.0.0/24 policy match dir out pol ipsec reqid 16385 proto 50 On 23 March 2011 16:29, Andreas Steffen andreas.stef...@strongswan.org wrote: Hello Russ, what about the IPsec policy based firewall rules inserted with firewall=yes. Do you get any hits on the outbound rules? Regards Andreas On 03/23/2011 04:36 PM, Russ Cox wrote: Hi All, I'm having a bit of a strange issue with a net-net vpn setup where packets bound for the remote subnet don't appear to be getting encapsulated on either gateway, I see no ESP packets other than those attributed with existing functional tunnels. I've tried tcpdumping on both endpoints, and can see icmp packets coming in to the local gateway from hosts on both networks, but no ESP packets - and none of it seems to get across the tunnel. Any help would be greatly appreciated - I've tried doing the same thing with IKEV2 (with a couple of required changes) and had exactly the same result. Give me a shout if I can provide any additional information. Thanks! Russ - Here's my setup Rodney: Debian lenny x86_64 Strongswan 4.2.4-5 - from repo A number of existing working ikev1 tunnels set up to other networks/hosts Granville: Debian Squeeze x86_64 Strongswan 4.4.1-5.1 - from repo Iptables on both hosts: udp 500 and 4500 + esp open 192.168.0.0/24-RODNEYBRIGHTON_PUB_IP.ESSEX_PUB_IP---NAT_ROUTERGRANVILLE192.168.6.0/24 http://192.168.0.0/24-RODNEYBRIGHTON_PUB_IP.ESSEX_PUB_IP---NAT_ROUTERGRANVILLE192.168.6.0/24 Essex router nats absolutely everything to Granville (it's on the netgear router's dmz) -- ESSEX - IPSEC.CONF config setup plutodebug=control nat_traversal=yes charonstart=no plutostart=yes conn essex_brighton left=%defaultroute leftid=ESSEX_PUB_IP leftsubnet=192.168.6.0/24 http://192.168.6.0/24 leftfirewall=yes right=BRIGHTON_PUB_IP rightsubnet=192.168.0.0/24 http://192.168.0.0/24 forceencaps=yes keyexchange=ikev1 authby=secret auto=add -- BRIGHTON-IPSEC.CONF config setup plutodebug=control nat_traversal=yes charonstart=yes plutostart=yes conn essex_brighton left=BRIGHTON_PUB_IP leftsubnet=192.168.0.0/24 http://192.168.0.0/24 leftfirewall=yes right=ESSEX_PUB_IP rightsubnet=192.168.6.0/24 http://192.168.6.0/24 forceencaps=yes keyexchange=ikev1 authby=secret auto=add --- root@granville:~# ipsec status 000 essex_brighton: 192.168.6.0/24===192.168.16.2:4500[ESSEX_PUB_IP]---192.168.16.1...BRIGHTON_PUB_IP:4500[BRIGHTON_PUB_IP]===192.168.0.0/24 http://192.168.6.0/24===192.168.16.2:4500[ESSEX_PUB_IP]---192.168.16.1...BRIGHTON_PUB_IP:4500[BRIGHTON_PUB_IP]===192.168.0.0/24; erouted; eroute owner: #2 000 essex_brighton: newest ISAKMP SA: #1; newest IPsec SA: #2; 000 000 #2: essex_brighton STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 4s; newest IPSEC; eroute owner 000 #2: essex_brighton esp.9c28ba55@BRIGHTON_PUB_IP (0 bytes) esp.c32b10a1@192.168.16.2 mailto:esp.c32b10a1@192.168.16.2 (0 bytes); tunnel 000 #1: essex_brighton STATE_MAIN_I4 (ISAKMP SA established);
[strongSwan] IKEv2 PFS status
Hi All,
I'm wondering if someone knows how to check if PFS is enabled, and the DH group
being used by a given CHILD_SA.
From an older post
(https://lists.strongswan.org/pipermail/users/2008-October/002822.html) I got
this The modp option in the esp definition is ignored when setting up the
first CHILD_SA as part of the IKE_AUTH exchange. Separate DH factors are is
used by CREATE_CHILD_SA exchanges establishing additional CHILD_SAs or
during IPSec SA rekeying. With this behaviour Perfect Forward Secrecy is
achieved.
So I configured a couple of gateways like shown below, but when I check 'ipsec
statusall' I don't see any reference to PFS on the second CHILD_SA.
I'm I doing something wrong?
Thanks in advance.
config setup
cachecrls=no
charonstart=yes
crlcheckinterval=0
plutostart=yes
strictcrlpolicy=no
nat_traversal=yes
plutodebug=none
charondebug=dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0,
enc 0, lib 0
#gw1-to-gw2
conn gw1-to-gw2
left=192.168.3.31
leftid=@H020109D0001
leftsubnet=172.22.0.0/24
leftnexthop=192.168.2.128
leftfirewall=yes
right=192.168.3.110
rightsubnet=10.0.0.0/24
ike=aes128-md5-modp1536!
esp=aes128-md5-modp1024!
keyexchange=ikev2
mobike=yes
ikelifetime=60m
keylife=20m
compress=no
authby=secret
dpdaction=restart
dpddelay=10
dpdtimeout=30
auto=add
keyingtries=1
rekeymargin=3m
forceencaps=yes
reauth=yes
#gw1-to-gw2-child2
conn gw1-to-gw2-child2
left=192.168.3.31
leftid=@H020109D0001
leftsubnet=172.22.1.0/24
leftnexthop=192.168.2.128
leftfirewall=yes
right=192.168.3.110
rightsubnet=10.1.0.0/24
ike=aes128-md5-modp1536!
esp=aes128-md5-modp1024!
keyexchange=ikev2
mobike=yes
ikelifetime=60m
keylife=20m
compress=no
authby=secret
dpdaction=restart
dpddelay=10
dpdtimeout=30
auto=add
keyingtries=1
rekeymargin=3m
forceencaps=yes
reauth=yes
Security Associations:
gw1-to-gw2[1]: ESTABLISHED 50 seconds ago,
192.168.3.31[H020109D0001]...192.168.3.110[192.168.3.110]
gw1-to-gw2[1]: IKE SPIs: e60a4f49fa294bcd_i* f6d5a905dfa97711_r, pre-shared key
reauthentication in 55 minutes
gw1-to-gw2[1]: IKE proposal: AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
gw1-to-gw2{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c911f5f8_i cf631c91_o
gw1-to-gw2{1}: AES_CBC_128/HMAC_MD5_96, 0 bytes_i, 0 bytes_o, rekeying in 16
minutes
gw1-to-gw2{1}: 172.22.0.0/24 === 10.0.0.0/24
gw1-to-gw2-child2{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c3013ecc_i c2eb28c9_o
gw1-to-gw2-child2{2}: AES_CBC_128/HMAC_MD5_96, 0 bytes_i, 0 bytes_o, rekeying
in 15 minutes
gw1-to-gw2-child2{2}: 172.22.1.0/24 === 10.1.0.0/24
___
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 IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman group) with any value other than NONE
[strongSwan] interface selection on MOBIKE
Hi all, I'm wondering if there a way to tell MOBIKE which interfaces it should consider during path discovery. I have a couple of gateways with multiple WAN links, but they also have some GRE tunnels interfaces, and I would like to tell MOBIKE which links to use (or not to use) out of all the available. (Pluto is also running but the connection is defined for ikev2 and mobike) [r...@gateway1 ~]# ipsec statusall 000 Status of IKEv1 pluto daemon (strongSwan 4.3.5): 000 interface eth0.164/eth0.164 192.168.3.47:4500 000 interface eth0.164/eth0.164 192.168.3.47:500 000 interface lo/lo ::1:500 000 interface lo/lo 127.0.0.1:4500 000 interface lo/lo 127.0.0.1:500 000 interface lo:0/lo:0 192.168.22.206:4500 000 interface lo:0/lo:0 192.168.22.206:500 000 interface br0/br0 172.22.0.1:4500 000 interface br0/br0 172.22.0.1:500 000 interface ppp0/ppp0 10.179.141.133:4500 000 interface ppp0/ppp0 10.179.141.133:500 000 interface tun1/tun1 192.168.40.1:4500 000 interface tun1/tun1 192.168.40.1:500 000 %myid = '%any' 000 loaded plugins: aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem hmac gmp 000 debug options: none 000 Status of IKEv2 charon daemon (strongSwan 4.3.5): uptime: 2 hours, since Dec 28 13:49:10 2010 worker threads: 1 idle of 8, job queue load: 0, scheduled events: 4 loaded plugins: aes des sha1 sha2 md5 fips-prf random x509 pubkey pkcs1 pgp dnskey pem xcbc hmac gmp kernel-netlink stroke updown attr resolve Listening IP addresses: 172.22.0.1 192.168.3.47 10.179.141.133 192.168.40.1 10.4.0.18 Connections: TO-GATEWAY2: 192.168.3.47...XX.XX.XX.XX, dpddelay=10s TO-GATEWAY2: local: [GATEWAY1] uses pre-shared key authentication TO-GATEWAY2: remote: [XX.XX.XX.XX] uses any authentication TO-GATEWAY2: child: 192.168.22.206/32 === 192.168.4.203/32 , dpdaction=restart Cheers, Alexis ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKEv2 PFS disabled
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 IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE. You probably should report this bug to Fortigate and/or try it without PFS enabled. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] net-to-net with one gateway behind NAT
Hello Martin, Sorry it took me so long to set this up. Here is the output with the patch. I think it makes sense, but is no longer giving me the error. It may had something to do with the fact that I loaded the patch in the newest version of strongswan (4.5.0), maybe I should try again with the older version and see what is different: 01[KNL] getting a local address in traffic selector 0.0.0.0/0 01[KNL] using host %any 01[KNL] getting address to reach 174.90.237.73 01[KNL] getting interface name for 192.168.21.100 01[KNL] 192.168.21.100 is on interface eth0 01[KNL] installing route: 172.22.0.0/28 via 192.168.21.20 src %any dev eth0 01[KNL] getting iface index for eth0 01[KNL] getting interface name for 192.168.21.100 01[KNL] 192.168.21.100 is on interface eth0 01[ENC] generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) ] 01[NET] sending packet: from 192.168.21.100[4500] to 174.90.237.73[4500] 04[KNL] received a XFRM_MSG_MAPPING Also, I can see table 220 created: # ip route show table 220 172.22.0.0/28 via 192.168.21.20 dev eth0 proto static # ip rule 0: from all lookup local 220:from all lookup 220 220:from all lookup 220 32766: from all lookup main 32767: from all lookup default Cheers, Alexis -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: November-11-10 1:04 AM To: Alexis Salinas Cc: users@lists.strongswan.org Subject: Re: [strongSwan] net-to-net with one gateway behind NAT Hi Alexis, getting a local address in traffic selector 0.0.0.0/0 using host %any getting address to reach 174.90.242.85 getting interface name for 192.168.21.100 192.168.21.100 is on interface eth0 getting iface index for eth0 received netlink error: No such process (3) unable to install source route for %any Yes, I have seen this error once. But I was unable to reproduce or fix it. The daemon tries to install a source route for this policy, like: ip route add 172.22.0.0/28 via GATEWAY src 192.168.21.100 dev eth0 But the kernel does not like that route. Maybe the gateway lookup does not work correctly on your setup, hard to say. Please apply the attached patch. It shows the complete route the daemon tries to install. Does that route makes sense for your setup? Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] net-to-net with one gateway behind NAT
Hi all,
I tested this configuration successfully many times without the NAT. This time
I connected one of the GW behind a NAT/FIREWALL device and although the tunnel
comes up I get an error message regarding routes (you can see almost at the
bottom of the log). Have you seen this before?. Thanks in advance for your help
Cheers,
Alexis
My setup:
172.22.0.0/28--GW1--Internet--(24.207.4.81)NAT_DEVICE--(192.168.21.100)GW2--10.0.0.0/24--OTHER_ROUTERS
My configuration (full tunnel)
GW1(Linux strongSwan U4.3.5/K2.6.30-310):
config setup
cachecrls=no
charonstart=yes
crlcheckinterval=0
plutostart=yes
strictcrlpolicy=no
nat_traversal=yes
plutodebug=none
charondebug=dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0,
enc 0, lib 0
conn net-to-net
left=%defaultroute
left...@gw1
leftsubnet=172.22.0.0/28
leftfirewall=yes
right=24.207.4.81
right...@gw2
rightsubnet=0.0.0.0/0
keyexchange=ikev2
mobike=yes
ikelifetime=60m
keylife=20m
compress=no
authby=secret
dpdaction=restart
dpddelay=10
dpdtimeout=30
auto=add
keyingtries=1
rekeymargin=3m
forceencaps=no
GW2 (Linux strongSwan U4.3.2/K2.6.31-1)
config setup
charonstart=yes
nat_traversal=yes
charondebug=dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 2, net 0,
enc 0, lib 0
conn net2net
left=192.168.21.100
left...@gw2
right=%any
right...@gw1
rekey=no
leftsubnet=0.0.0.0/0
rightsubnet=172.22.0.0/28
ike=aes128-md5-modp1536!
ikelifetime=3600s
keyexchange=ikev2
mobike=yes
dpddelay=30s
dpdtimeout=120s
dpdaction=clear
esp=aes128-md5!
keylife=1200s
rekeymargin=540s
type=tunnel
pfs=yes
compress=no
authby=secret
auto=add
GW2 logs (I cut removed some part for brevity, let me now if you need the whole
thing)
Nov 9 10:56:46 GW2 charon: 09[IKE] 174.90.242.85 is initiating an IKE_SA
Nov 9 10:56:46 GW2 charon: 09[IKE] 174.90.242.85 is initiating an IKE_SA
Nov 9 10:56:46 GW2 charon: 09[IKE] IKE_SA (unnamed)[1] state change: CREATED
= CONNECTING
Nov 9 10:56:46 GW2 charon: 09[IKE] local host is behind NAT, sending keep
alives
Nov 9 10:56:46 GW2 charon: 08[IKE] authentication of 'GW1' with pre-shared key
successful
Nov 9 10:56:46 GW2 charon: 08[IKE] peer supports MOBIKE
Nov 9 10:56:46 GW2 charon: 08[IKE] got additional MOBIKE peer address:
172.22.0.1
Nov 9 10:56:46 GW2 charon: 08[IKE] got additional MOBIKE peer address:
172.22.1.1
Nov 9 10:56:46 GW2 charon: 08[IKE] got additional MOBIKE peer address:
172.22.2.1
Nov 9 10:56:46 GW2 charon: 08[IKE] authentication of 'GW2' (myself) with
pre-shared key
Nov 9 10:56:46 GW2 charon: 08[IKE] successfully created shared key MAC
Nov 9 10:56:46 GW2 charon: 08[IKE] IKE_SA net2net[1] state change: CONNECTING
= ESTABLISHED
Nov 9 10:56:46 GW2 charon: 08[IKE] IKE_SA net2net[1] established between
192.168.21.100[GW2]...174.90.242.85[GW1]
Nov 9 10:56:46 GW2 charon: 08[IKE] IKE_SA net2net[1] established between
192.168.21.100[GW2]...174.90.242.85[GW1]
Nov 9 10:56:46 GW2 charon: 08[KNL] getting SPI for reqid {1}
Nov 9 10:56:46 GW2 charon: 08[KNL] sending XFRM_MSG_ALLOCSPI: = 244 bytes @
0xb38adc68
Nov 9 10:56:46 GW2 charon: 08[KNL]0: F4 00 00 00 16 00 01 00 C9 00 00 00
14 42 00 00 .B..
Nov 9 10:56:46 GW2 charon: 08[KNL] 240: FF FF FF CF
Nov 9 10:56:46 GW2 charon: 08[KNL] got SPI ccbe182c for reqid {1}
Nov 9 10:56:46 GW2 charon: 08[KNL] adding SAD entry with SPI ccbe182c and
reqid {1}
Nov 9 10:56:46 GW2 charon: 08[KNL] using encryption algorithm AES_CBC with
key size 128
Nov 9 10:56:46 GW2 charon: 08[KNL] using integrity algorithm HMAC_MD5_96
with key size 128
Nov 9 10:56:46 GW2 charon: 08[KNL] sending XFRM_MSG_UPDSA: = 440 bytes @
0xb38adbc4
Nov 9 10:56:46 GW2 charon: 08[KNL]0: B8 01 00 00 1A 00 05 00 CA 00 00 00
14 42 00 00 .B..
Nov 9 10:56:46 GW2 charon: 08[KNL] 432: 00 00 00 00 00 00 00 00
Nov 9 10:56:46 GW2 charon: 08[KNL] adding SAD entry with SPI c94ea202 and
reqid {1}
Nov 9 10:56:46 GW2 charon: 08[KNL] using encryption algorithm AES_CBC with
key size 128
Nov 9 10:56:46 GW2 charon: 08[KNL] using integrity algorithm HMAC_MD5_96
with key size 128
Nov 9 10:56:46 GW2 charon: 08[KNL] sending XFRM_MSG_NEWSA: = 440 bytes @
0xb38adbc4
Nov 9 10:56:46 GW2 charon: 08[KNL]0: B8 01 00 00 10 00 05 00 CB 00 00 00
14 42 00 00 .B..
Nov 9 10:56:46 GW2 charon: 08[KNL] 432: 00 00 00 00 00 00 00 00
Nov 9 10:56:46 GW2 charon: 08[KNL] adding policy 0.0.0.0/0 === 172.22.0.0/28
out
Nov 9 10:56:46 GW2 charon: 08[KNL] sending
