[strongSwan] IPAD via NATed firewall doesn't work (Martin Kellermann)
Uli Joergens
uli.joergens at wanadoo.fr
Tue Apr 5 22:35:06 CEST 2011
Concerning the single nated config I followed the following receipe:
http://nielspeen.com/blog/2009/04/linux-l2tpipsec-with-iphone-and-mac-osx-clients/
For the records: I forwarded the following ports
- 1701
- 4500
- 500
- 50
- 51
Basically, whenever I noticed any chatting going on on a port I opened and forwarded it. Not necessary suitable for a production environment.
From that point of view one may ask whether VPN really improves security...
... but lets cross the bridge when we get there.
Cheers
Uli
On 05.04.2011, at 16:51, Martin Kellermann <kellermann at sk-datentechnik.com> wrote:
> Am 05.04.2011 12:47, schrieb Uli Joergens:
>> Hi there
>>
>> I tried it with older iOS version and it didn't work either.
> ah... ok. it was just a thought.
>> I did manage to establish a local connection to a NATed virtual machine, so single NAT works fine.
> really? this doesn't work for me. can you show me your configs? or give some more hints...
> which side was NATed on your working connection?
>> 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.
> just for the records: udp 500 and udp 4500 ?
>> 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
>>> ************************************
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>>
More information about the Users
mailing list