[strongSwan] IPAD via NATed firewall doesn't work (Martin Kellermann)
Uli Joergens
uli.joergens at wanadoo.fr
Tue Apr 5 12:47:58 CEST 2011
Hi there
I tried it with older iOS version and it didn't work either.
I did manage to establish a local connection to a NATed virtual machine, so single NAT works fine.
I tried Andreas' suggestion to set leftsubnetwithin but I get the same error.
My configuration:
ipad -- nated mobile provider -- orange -- dr855 nated gw / firewall -- VPN gateway
ports are forwarded to the VPN gateway.
Any ideas how to make that work?
Cheers
Uli
On 05.04.2011, at 12:00, users-request at lists.strongswan.org wrote:
>
> hello andreas,
>
> yes, you are right, but this still doesn't solve the problem. i am still
> stuck...
>
> reading some current posts on APPLEs discussion forum
> (for ex: http://discussions.apple.com/thread.jspa?threadID=2778039)
> maybe this is a general problem with iOS > 4.3 ?
>
> so i'm very interested if anyone has managed to get the iPad 2 (iOS 4.3.1)
> connect to strongswan with one or both sides being NATed?
>
> or maybe someone has managed to connect to open-/freeSWAN ?
> (server is on debian 6)
>
> any help is really appreciated!
>
> thank you
>
> Martin
>
> Am 30.03.2011 12:37, schrieb Andreas Steffen:
>> Hello Martin,
>>
>> because the responder is NAT-ed you don't have to set
>> rightsubnetwithin but
>>
>> leftsubnetwithin=0.0.0.0/0
>>
>> Regards
>>
>> Andreas
>>
>> On 30.03.2011 09:57, Martin Kellermann wrote:
>>> hi,
>>>
>>> is there still no solution for this?
>>>
>>> i ran into the same situation like Uli getting the
>>> "cannot respond to IPsec SA request because no connection is known"
>>> error.
>>>
>>> i want the following setup:
>>>
>>> iPad<-- NOT NATed --> internet<-- DSL router --> strongswan (NATed)
>>>
>>> so just the strongswan server's side is NATed
>>>
>>> i recompiled strongswan (on debian) with NAT-T patch enabled and auth.log
>>> tells: "including NAT-Traversal patch (Version 0.6c)"
>>>
>>> ipsec.conf:
>>> config setup
>>> nat_traversal=yes
>>> charonstart=yes
>>> plutostart=yes
>>> conn ipads
>>> authby=psk
>>> pfs=no
>>> rekey=no
>>> type=tunnel
>>> forceencaps=yes
>>> esp=aes128-sha1
>>> ike=aes128-sha-modp1024
>>> left=%defaultroute
>>> leftprotoport=17/1701
>>> right=%any
>>> rightprotoport=17/%any
>>> rightsubnetwithin=0.0.0.0/0
>>> auto=add
>>>
>>> ipsec.secrets:
>>> 192.168.0.251 %any : PSK "xxxxxxxxxx"
>>>
>>> auth.log:
>>> Mar 29 16:39:45 vpn pluto[28437]: loaded PSK secret for 192.168.0.251 %any
>>> Mar 29 16:39:45 vpn ipsec_starter[28436]: charon (28444) started after 40 ms
>>> Mar 29 16:39:45 vpn pluto[28437]: added connection description "ipads"
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> received Vendor ID payload [RFC 3947]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
>>> Mar 29 16:39:51 vpn pluto[28437]: packet from 2.206.202.168:500:
>>> received Vendor ID payload [Dead Peer Detection]
>>> Mar 29 16:39:51 vpn pluto[28437]: "ipads"[1] 2.206.202.168 #1:
>>> responding to Main Mode from unknown peer 2.206.202.168
>>> Mar 29 16:39:51 vpn pluto[28437]: "ipads"[1] 2.206.202.168 #1:
>>> NAT-Traversal: Result using RFC 3947: i am NATed
>>> Mar 29 16:39:51 vpn pluto[28437]: "ipads"[1] 2.206.202.168 #1: ignoring
>>> informational payload, type IPSEC_INITIAL_CONTACT
>>> Mar 29 16:39:51 vpn pluto[28437]: "ipads"[1] 2.206.202.168 #1: Peer ID
>>> is ID_IPV4_ADDR: '2.206.202.168'
>>> Mar 29 16:39:51 vpn pluto[28437]: | NAT-T: new mapping
>>> 2.206.202.168:500/4500)
>>> Mar 29 16:39:51 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1: sent
>>> MR3, ISAKMP SA established
>>> Mar 29 16:39:53 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> cannot respond to IPsec SA request because no connection is known for
>>> 188.101.67.77/32===192.168.0.251:4500[192.168.0.251]:17/1701...2.206.202.168:4500[2.206.202.168]:17/%any
>>> Mar 29 16:39:53 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_ID_INFORMATION to 2.206.202.168:4500
>>> Mar 29 16:39:55 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:39:55 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:39:58 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:39:58 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:01 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:40:01 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:04 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:40:04 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:07 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:40:07 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:10 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:40:10 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:13 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:40:13 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:16 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:40:16 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:19 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> Quick Mode I1 message is unacceptable because it uses a previously used
>>> Message ID 0xcf9299e3 (perhaps this is a duplicated packet)
>>> Mar 29 16:40:19 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> sending encrypted notification INVALID_MESSAGE_ID to 2.206.202.168:4500
>>> Mar 29 16:40:23 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500 #1:
>>> received Delete SA payload: deleting ISAKMP State #1
>>> Mar 29 16:40:23 vpn pluto[28437]: "ipads"[1] 2.206.202.168:4500:
>>> deleting connection "ipads" instance with peer 2.206.202.168
>>> {isakmp=#0/ipsec=#0}
>>> Mar 29 16:40:23 vpn pluto[28437]: ERROR: asynchronous network error
>>> report on eth0 for message to 2.206.202.168 port 4500, complainant
>>> 2.206.202.168: Connection refused [errno 111, origin ICMP type 3 code 3
>>> (not authenticated)]
>>>
>>> any ideas?
>>>
>>> regards
>>>
>> ======================================================================
>> Andreas Steffen andreas.steffen at strongswan.org
>> strongSwan - the Linux VPN Solution! www.strongswan.org
>> Institute for Internet Technologies and Applications
>> University of Applied Sciences Rapperswil
>> CH-8640 Rapperswil (Switzerland)
>> ===========================================================[ITA-HSR]==
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 4 Apr 2011 15:48:59 -0500
> From: Dennis Frett <frett at us.ibm.com>
> Subject: [strongSwan] IKEv2 NAT issue
> To: users at lists.strongswan.org
> Message-ID:
> <OF923D4856.43799347-ON86257868.006FE754-86257868.0072598D at us.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I'm running an IKEv2 NAT-T test with Strongswan 4.5.0 behind a NAT
>
>
> Linux ------- NAT| -------- initiator
>
>
>
> The IKE_SA_INIT and IKE_AUTH are sent and received from the linux just
> fine.
> Strongswan detects the NAT in front of itself and also returns the
> IKE_AUTH on src port 4500; dst port 4500 just fine.
>
> However, after that everything that's sent from strongswan is w/ srcport
> 4500; dstport 500.
> That includes:
> - delete child_sa informational
> - any ESP packets that are sent in UDP encap
> - any create_child_sa requests.
>
>
> If i take the same configuration and initiate from strongswan the entire
> NAT exchange works including whatever is sent after IKE_AUTH exchange.
>
>
> I'm not seeing where this is a configuration issue, but might be missing
> something.
>
>
>
> traces from strongswan:
> Apr 4 01:55:59 blackthumb charon: 16[NET] received packet: from
> 10.10.110.204[500] to 9.5.149.53[500]
> Apr 4 01:55:59 blackthumb charon: 16[ENC] parsed IKE_SA_INIT request 0 [
> SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> Apr 4 01:55:59 blackthumb charon: 16[IKE] 10.10.110.204 is initiating an
> IKE_SA
> Apr 4 01:55:59 blackthumb charon: 16[IKE] local host is behind NAT,
> sending keep alives
> Apr 4 01:55:59 blackthumb charon: 16[IKE] sending cert request for "C=US,
> O=IBM, CN=BlackthumbCA"
> Apr 4 01:55:59 blackthumb charon: 16[ENC] generating IKE_SA_INIT response
> 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
> Apr 4 01:55:59 blackthumb charon: 16[NET] sending packet: from
> 9.5.149.53[500] to 10.10.110.204[500]
> Apr 4 01:56:01 blackthumb charon: 01[NET] received packet: from
> 10.10.110.204[4500] to 9.5.149.53[4500]
> Apr 4 01:56:01 blackthumb charon: 01[ENC] parsed IKE_AUTH request 1 [ IDi
> AUTH SA TSi TSr ]
> Apr 4 01:56:01 blackthumb charon: 01[CFG] looking for peer configs
> matching 9.5.149.53[%any]...10.10.110.204[10.10.110.204]
> Apr 4 01:56:01 blackthumb charon: 01[CFG] selected peer config
> 'strongswan-remotehost'
> Apr 4 01:56:01 blackthumb charon: 01[IKE] authentication of
> '10.10.110.204' with pre-shared key successful
> Apr 4 01:56:01 blackthumb charon: 01[IKE] authentication of '9.5.149.53'
> (myself) with pre-shared key
> Apr 4 01:56:01 blackthumb charon: 01[IKE] IKE_SA strongswan-remotehost[1]
> established between 9.5.149.53[9.5.149.53]...10.10.110.204[10.10.110.204]
> Apr 4 01:56:01 blackthumb charon: 01[IKE] scheduling reauthentication in
> 10181s
> Apr 4 01:56:01 blackthumb charon: 01[IKE] maximum IKE_SA lifetime 10721s
> Apr 4 01:56:01 blackthumb charon: 01[IKE] CHILD_SA
> strongswan-remotehost{1} established with SPIs ce28fab5_i 58db4f08_o and
> TS 9.5.149.53/32 === 10.10.110.204/32
> Apr 4 01:56:01 blackthumb charon: 01[ENC] generating IKE_AUTH response 1
> [ IDr AUTH SA TSi TSr N(AUTH_LFT) ]
> Apr 4 01:56:01 blackthumb charon: 01[NET] sending packet: from
> 9.5.149.53[4500] to 10.10.110.204[4500]
> Apr 4 01:56:12 blackthumb charon: 00[DMN] signal of type SIGINT received.
> Shutting down
> Apr 4 01:56:12 blackthumb charon: 00[IKE] deleting IKE_SA
> strongswan-remotehost[1] between
> 9.5.149.53[9.5.149.53]...10.10.110.204[10.10.110.204]
> Apr 4 01:56:12 blackthumb charon: 00[IKE] sending DELETE for IKE_SA
> strongswan-remotehost[1]
> Apr 4 01:56:12 blackthumb charon: 00[ENC] generating INFORMATIONAL
> request 0 [ D ]
> Apr 4 01:56:12 blackthumb charon: 00[NET] sending packet: from
> 9.5.149.53[4500] to 10.10.110.204[500]
>
>
>
> Dennis Frett
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.strongswan.org/pipermail/users/attachments/20110404/6f66fa49/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
> End of Users Digest, Vol 15, Issue 2
> ************************************
More information about the Users
mailing list