[Openswan Users] NO_PROPOSAL_CHOSEN then one ipsec endpoint is behind 1-to-1 nat (no prob without nat)
Piavlo
piavka at cs.bgu.ac.il
Thu Nov 18 09:13:48 EST 2010
Hi Bob,
I managed to solve the problem:
1) I needed leftid=PUBLIC_IP instead of leftnexthop=PUBLIC_IP
and also set leftnexthop=%defaultroute
2) I had bad secrets config
on EC2 -> 10.227.37.62 1.1.1.1: PSK ...
on DC -> 2.2.2.2 1.1.1.1: PSK ...
It should have been only public ips - instead of real local nated ips
2.2.2.2 1.1.1.1: PSK ...
on both ends
I think that it might have worked with 2) only and previous config - did
not verify.
Below you can find my config on the ec2 instance there are two connections
one EC2-to-DC and second EC2-to-EC2 - where the two ec2 instances are in
different regions and thus can communicate
only through public ip - this 1-1 net situation on both ends.
----------------
version 2.0
config setup
plutodebug="control controlmore emitting"
plutoopts="--perpeerlog --perpeerlogbase /var/log/pluto"
nat_traversal=yes
virtual_private=%v4:192.168.0.0/16,%v4:!192.168.1.0/24
oe=off
protostack=netkey
conn EC2-to-EC2
connaddrfamily=ipv4
type=tunnel
authby=secret
ike=3des-sha1
phase2=esp
phase2alg=3des-sha1
forceencaps=yes
pfs=yes
left=10.227.37.62
leftid=2.2.2.2
leftnexthop=%defaultroute
leftsubnet=192.168.1.0/24
leftsourceip=192.168.1.1
right=3.3.3.3
rightsubnet=192.168.3.0/24
rightsourceip=192.168.3.1
auto=add
conn EC2-to-DC
connaddrfamily=ipv4
type=tunnel
authby=secret
ike=3des-sha1
phase2=esp
phase2alg=3des-sha1
forceencaps=yes
pfs=yes
left=10.227.37.62
leftid=2.2.2.2
leftnexthop=%defaultroute
leftsubnet=192.168.1.0/24
leftsourceip=192.168.1.1
right=1.1.1.1
rightsubnet=192.168.186.0/24
rightsourceip=192.168.186.34
auto=add
---------------------
PS. each time the ec2 instance is rebooted it can get different private
ip - the public ip are elastic so they do not change.
Since the other end connects not to the ec2 private ip - but to the
static ip 192.168.1.1 (the 192.168.1.1) on tap device - there is no need
to reconfigure the right side then ec2 instance reboots - while the
left=PRIVATE_IP can be automatically substituted once ec2 instance boots
before the ipsec is started.
Thank a lot for you help
Alex
On 11/18/2010 07:00 AM, Bob Miller wrote:
> Hi Alex,
> hmm... I am not sure what to suggest next. unfortunately, I don't have
> any situations that mirror yours exactly, so I don't have a working
> model to compare with. The situation I have the most closely resembles
> yours does have only one physical interface where I use a real and a
> virtual interface (eht0 and eth0:1), but neither end of that connection
> is nat'd.
> In fact, I dont' have any servers that are nat'd, but I think such a
> situation should be the same as a linux roadwarrior, it just has a
> network behind it is all that is different. I also do not see how
> 1-to-1 nat would be different than 1-to-many nat. 1-to-many nat would
> be better described as many 1-to 1 nats.
> In looking through the history of this conversation, I can't see any
> problems. The only other thing I can think of is right/leftid. I don't
> have any instances of that in my configs, but with nat situations it
> might help.
> Maybe it is time to start thinking outside of the openswan box. Are you
> running current kernels and versions of openswan? Are they the same
> versions of openswan on each machine? Do you have your ipsec.secrets
> file set up correctly?
> Not sure what else to suggest, Alex. On the bright side, in my
> experience, you can solve the problem every time if you don't give up ;)
>
>
>
>
> On Thu, 2010-11-18 at 00:31 +0200, Piavlo wrote:
>
>> Hi bob,
>>
>> Thank you so much for the detailed reply.
>>
>> If I understood you correctly - you suggest adding
>> leftnexthop=2.2.2.2=NAT-PUBLIC-IP on the EC2 host config only?
>>
>> I've tried this (also with virtual_private modified on each host - as
>> you suggested) - but this did not change anything - I see exactly the
>> same picture.
>>
>> Any other Ideas?
>>
>> BTW I managed to make the two EC2 instances to use NAT traversal by
>> adding forceencaps=yes and now everything works - but this is a testing
>> only purpose setup - for production use I need to solve the 1-1 nat problem.
>>
>> Thanks
>> Alex
>>
>> Bob Miller wrote:
>>
>>> Hi Alex,
>>> Before I get going here, let me just say that while I have quite a bit
>>> of practise playing with openswan (15-20 production servers, mostly for
>>> small businesses using roadwarriors), I am far from the expert that a
>>> lot of other people on the list are. Every bit of knowledge and
>>> intuition I have with this program was hard fought for, and I still find
>>> it very challenging and I still get stumped regularly. Therefor, take
>>> these suggestion as just that, and I apologize in advance if you spend
>>> time on the wrong path due to my suggestions...
>>> comments are inline:
>>>
>>> On Wed, 2010-11-17 at 18:30 +0200, Piavlo wrote:
>>>
>>>> Hi again ,
>>>>
>>>> Bob thanks for your suggestion to force a NAT usage.
>>>>
>>>> What I'm trying to do now is connect an amazon ec2 instance with a
>>>> physical host in datacenter (DC) - this is what I actually need to achieve
>>>> in the end (connecting tow ec2 instances was just for initial test).
>>>> The DC host has public IP. While ec2 instance have a public which is a
>>>> one-to-one nat to private ip - so then I'm logged on to ec2 instance I
>>>> see the private IP.
>>>>
>>>> The one-to-one is not really one-to-many nat - so i'm not sure if NAT
>>>> traversal should be triggered here?
>>>>
>>> I think that regardless of how many, there is still NAT going on here.
>>> That is because your real interface IP address is not the address that
>>> the other end sees. So when the other sends to you, DNAT must occur for
>>> the real IP address to deliver to the LAN address, and when your side
>>> sends out SNAT must occur in order to receive replies.
>>>
>>>
>>>> But in any case AFAIU at least the ISAKMP and IPsec SAs should be
>>>> established - which does not happen with 1-to-1 nat
>>>> While without any nat SAs are established - between the two ec2
>>>> instances with same configuration
>>>>
>>> Okay, I would consider this expected behaviour. If you think of your
>>> conn stanzas in your config as a description of the network situation,
>>> then when you change your network situation, you should expect to have
>>> to change your conn stanza to reflect that. In this case, if you conn
>>> works while one end is not nat'd, the conn accurately describes your
>>> network situation. If you then change that end to be not nat'd, then
>>> your network situation has changed, and the conn will no longer reflect
>>> it.
>>>
>>>
>>>>
>>>> The nodes can communicate but phase 1 cannot be established and I get
>>>> NO_PROPOSAL_CHOSEN on DC host.
>>>>
>>> In your logs, you will probably find just above this something like
>>> "peer proposed blah", where blah will be a network description. If so,
>>> then the peer has proposed a network description that openswan cannot
>>> find a matching conn for in its own config file.
>>> Since one end is behind nat, you will almost certainly not be able to
>>> use symmetrical config files on both servers. Both ends are going to
>>> see the network situation differently, and each conn will have to
>>> reflect that situation from each point of view.
>>>
>>>
>>>> Both nodes have same cipher & hash for phase 1 & 2 configured.
>>>> And NO iptables on both hosts.
>>>>
>>>> Below are the exact configuration details
>>>>
>>>> DC host ip is 1.1.1.1 = right side
>>>> EC2 public ip is 2.2.2.2 = left side
>>>> EC2 private ip is 10.227.37.62
>>>>
>>>> The DC and ec2 ipsec.conf has different right= value - due to the 1-to-1
>>>> nat.
>>>>
>>>> On DC host I've the following config:
>>>> ---------------
>>>> config setup
>>>> nat_traversal=yes
>>>> virtual_private=%v4:192.168.0.0/16
>>>>
>>> I am suspicious of this, but not sure if it really is a problem. This
>>> subnet encompasses both sides without excluding it's own side. I would
>>> try on the left (EC):
>>> virtual_private=%v4:192.168.0.0/16,%v4:!192.168.1.0/24
>>> and on the right (DC):
>>> virtual_private=%v4:192.168.0.0/16,%v4:!192.168.186.0/24
>>>
>>>
>>>> oe=off
>>>> protostack=netkey
>>>>
>>>> conn linux-to-linux
>>>> connaddrfamily=ipv4
>>>> type=tunnel
>>>> authby=secret
>>>> ike=3des-sha1
>>>> phase2=esp
>>>> phase2alg=3des-sha1
>>>> left=2.2.2.2
>>>> leftsubnet=192.168.1.0/24
>>>> right=1.1.1.1
>>>> rightsubnet=192.168.186.0/24
>>>> auto=add
>>>>
>>> I haven't got a set of my own personal troubleshooting rules for this
>>> yet, but on the servers where I have set up net-to-net vpns, I have the
>>> setting lef/righttnexthop in those conns. I would think where nat is
>>> involved, it would be helpful to have.
>>>
>>>
>>>> ----------------
>>>>
>>>> And on EC2
>>>> ---------------
>>>> config setup
>>>> nat_traversal=yes
>>>> virtual_private=%v4:192.168.0.0/16
>>>> oe=off
>>>> protostack=netkey
>>>>
>>>> conn linux-to-linux
>>>> connaddrfamily=ipv4
>>>> type=tunnel
>>>> authby=secret
>>>> ike=3des-sha1
>>>> phase2=esp
>>>> phase2alg=3des-sha1
>>>> left=10.227.37.62
>>>> leftsubnet=192.168.1.0/24
>>>> right=1.1.1.1
>>>> rightsubnet=192.168.186.0/24
>>>> auto=add
>>>>
>>> I think leftnexthop is required here in order to get the public address
>>> into the mix somehow. As is, when this end proposes a connection, it
>>> cannot include its real IP, which probably confuses the other end, and
>>> when the other end proposes a connection to the real IP, this end isn't
>>> going to know what the other end is referring too.
>>>
>>>
>>>> ---------------
>>>>
>>>> On DC host running 'ipsec auto --up linux-to-linux' i get:
>>>> ---------------------
>>>> shell> ipsec auto --up linux-to-linux
>>>> 104 "linux-to-linux" #1: STATE_MAIN_I1: initiate
>>>> 003 "linux-to-linux" #1: ignoring informational payload, type
>>>> NO_PROPOSAL_CHOSEN msgid=00000000
>>>> 003 "linux-to-linux" #1: received and ignored informational message
>>>> 010 "linux-to-linux" #1: STATE_MAIN_I1: retransmission; will wait 20s
>>>> for response
>>>> 003 "linux-to-linux" #1: ignoring informational payload, type
>>>> NO_PROPOSAL_CHOSEN msgid=00000000
>>>> 003 "linux-to-linux" #1: received and ignored informational message
>>>> 010 "linux-to-linux" #1: STATE_MAIN_I1: retransmission; will wait 40s
>>>> for response
>>>> 003 "linux-to-linux" #1: ignoring informational payload, type
>>>> NO_PROPOSAL_CHOSEN msgid=00000000
>>>> 003 "linux-to-linux" #1: received and ignored informational message
>>>>
>>> This is the other end sending us a message that it did not choose a
>>> proposal. So this end proposed a network description to build the
>>> connection with, the other end rejected it and sent us notification of
>>> that rejection, which this end is now ignoring because it can't use that
>>> information to proceed.
>>>
>>>
>>>> ---------------------
>>>>
>>>> --------------------
>>>>
>>>> tcpdump on DC host:
>>>> -------------------
>>>> 08:44:00.314670 IP 1.1.1.1.isakmp > 2.2.2.2.isakmp: isakmp: phase 1 I ident
>>>> 08:44:00.439113 IP 2.2.2.2.isakmp > 1.1.1.1.isakmp: isakmp: phase 1 R inf
>>>> 08:44:03.602432 IP 2.2.2.2.isakmp > 1.1.1.1.isakmp: isakmp: phase 1 I ident
>>>> 08:44:03.603094 IP 1.1.1.1.isakmp > 2.2.2.2.isakmp: isakmp: phase 1 R ident
>>>> 08:44:03.730943 IP 2.2.2.2.isakmp > 1.1.1.1.isakmp: isakmp: phase 1 I inf
>>>> 08:44:10.730586 IP 1.1.1.1.isakmp > 2.2.2.2.isakmp: isakmp: phase 1 I ident
>>>> 08:44:10.857515 IP 2.2.2.2.isakmp > 1.1.1.1.isakmp: isakmp: phase 1 R inf
>>>> 08:44:13.857519 IP 1.1.1.1.isakmp > 2.2.2.2.isakmp: isakmp: phase 1 R ident
>>>> 08:44:13.983463 IP 2.2.2.2.isakmp > 1.1.1.1.isakmp: isakmp: phase 1 I inf
>>>> 08:44:30.983243 IP 1.1.1.1.isakmp > 2.2.2.2.isakmp: isakmp: phase 1 I ident
>>>> 08:44:31.112161 IP 2.2.2.2.isakmp > 1.1.1.1.isakmp: isakmp: phase 1 R inf
>>>> 08:44:33.112188 IP 1.1.1.1.isakmp > 2.2.2.2.isakmp: isakmp: phase 1 R ident
>>>> 08:44:33.239124 IP 2.2.2.2.isakmp > 1.1.1.1.isakmp: isakmp: phase 1 I inf
>>>> 08:45:10.238574 IP 1.1.1.1.isakmp > 2.2.2.2.isakmp: isakmp: phase 1 I ident
>>>> ---------------------
>>>>
>>>> status info on DC:
>>>> ---------------------
>>>> 000 "linux-to-linux":
>>>> 192.168.186.0/24===1.1.1.1<1.1.1.1>[+S=C]...2.2.2.2<2.2.2.2>[+S=C]===192.168.1.0/24;
>>>> unrouted; eroute owner: #0
>>>> 000 "linux-to-linux": myip=unset; hisip=unset;
>>>> 000 "linux-to-linux": ike_life: 3600s; ipsec_life: 28800s;
>>>> rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
>>>> 000 "linux-to-linux": policy:
>>>> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+lKOD+rKOD; prio: 24,24; interface:
>>>> eth0;
>>>> 000 "linux-to-linux": newest ISAKMP SA: #0; newest IPsec SA: #0;
>>>> 000 "linux-to-linux": IKE algorithms wanted:
>>>> 3DES_CBC(5)_000-SHA1(2)-MODP1536(5),
>>>> 3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=-strict
>>>> 000 "linux-to-linux": IKE algorithms found:
>>>> 3DES_CBC(5)_192-SHA1(2)_160-5, 3DES_CBC(5)_192-SHA1(2)_160-2,
>>>> 000 "linux-to-linux": ESP algorithms wanted: 3DES(3)_000-SHA1(2);
>>>> flags=-strict
>>>> 000 "linux-to-linux": ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
>>>> 000
>>>> 000 #2: "linux-to-linux":500 STATE_MAIN_R1 (sent MR1, expecting MI2);
>>>> EVENT_RETRANSMIT in 22s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
>>>> 000 #1: "linux-to-linux":500 STATE_MAIN_I1 (sent MI1, expecting MR1);
>>>> EVENT_RETRANSMIT in 21s; nodpd; idle; import:admin initiate
>>>> 000 #1: pending Phase 2 for "linux-to-linux" replacing #0
>>>> ---------------------
>>>>
>>>> Status on ec2 instance:
>>>> ---------------------
>>>> 000 "linux-to-linux":
>>>> 192.168.1.0/24===10.227.37.62<10.227.37.62>[+S=C]...1.1.1.1<1.1.1.1>[+S=C]===192.168.186.0/24;
>>>> unrouted; eroute owner: #0
>>>> 000 "linux-to-linux": myip=unset; hisip=unset;
>>>> 000 "linux-to-linux": ike_life: 3600s; ipsec_life: 28800s;
>>>> rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
>>>> 000 "linux-to-linux": policy:
>>>> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+lKOD+rKOD; prio: 24,24; interface:
>>>> eth0;
>>>> 000 "linux-to-linux": newest ISAKMP SA: #0; newest IPsec SA: #0;
>>>> 000 "linux-to-linux": IKE algorithms wanted:
>>>> 3DES_CBC(5)_000-SHA1(2)_000-MODP1536(5),
>>>> 3DES_CBC(5)_000-SHA1(2)_000-MODP1024(2); flags=-strict
>>>> 000 "linux-to-linux": IKE algorithms found:
>>>> 3DES_CBC(5)_192-SHA1(2)_160-MODP1536(5),
>>>> 3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)
>>>> 000 "linux-to-linux": ESP algorithms wanted: 3DES(3)_000-SHA1(2)_000;
>>>> flags=-strict
>>>> 000 "linux-to-linux": ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
>>>> 000
>>>> 000 #2: "linux-to-linux":500 STATE_MAIN_I1 (sent MI1, expecting MR1);
>>>> none in -1s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
>>>> 000 #2: pending Phase 2 for "linux-to-linux" replacing #0
>>>> --------------------
>>>>
>>>> Any clues/suggestions on what is wrong here?
>>>>
>>> One last thing, though you probably have already looked after it, is to
>>> make sure ip_forwarding is enabled in your sysctl.conf file (or in your
>>> proc directory as you see fit). Without that, regardless of not having
>>> iptables, packets will not forward from one end to the other. But that
>>> is for after you get your tunnel established.
>>>
>>>
>>>> Thanks
>>>> Alex
>>>>
>>> I am curious to know how things work out, please let me know...
>>>
>>>
>>>> On 11/16/2010 05:14 AM, Bob Miller wrote:
>>>>
>>>>>
>>>>>
>>>>>> The good news is that I can see that now the ping to 192.168.2.1 goes
>>>>>> over eth0 as esp packet (with "tcpdump -n -i eth0 esp") previosluly
>>>>>> they were sent as-is over eth0 (as I could see them with "tcpdump -n -i
>>>>>> eth0 icmp")
>>>>>>
>>>>>>
>>>>> We like good news :)
>>>>>
>>>>>
>>>>>
>>>>>> The bad news is that the esp packets go out from vpn01a but never reach
>>>>>> vpn01b. Now that I think about it again those vpn hosts are Amazon ec2
>>>>>> could instances - and I can use only icmp/tcp/udp protocols to
>>>>>> communicate within amazon could. Oh shi.... how I could have forgotten
>>>>>> that - I guess I was misguided by the fact that the ISAKMP and IPsec SAs
>>>>>> were successfully established - but UDP is used for this establishment.
>>>>>>
>>>>>>
>>>>> Hmm.. this is causing an itch in my brain somewhere. You will want to
>>>>> check documentation on this, but it seems to me that when both servers
>>>>> are on a public IP (ie no nat), then they will only use port 500 and the
>>>>> esp protocol. However, when one server is behind a nat'd connection, it
>>>>> then creates an esp over udp connection on port 4500.
>>>>> If this is correct, then on one server you could theoretically make two
>>>>> virtual interfaces, one for the subnet, one for the vpn server, and a
>>>>> real one with a real ip. then make that server do all the ipsec
>>>>> initiating and masq all the vpn interface traffic with the real
>>>>> interface. This would force all traffic to be udp instead of esp.
>>>>> However, it also occurs to me that the tunnel should not be able to get
>>>>> established without esp. I would have to go through the docs again and
>>>>> find the part about how it establishes its tunnels, which protocol on
>>>>> which port when, but that isn't going to happen any time soon, sorry.
>>>>> Other thoughts: If your pings are leaving encrypted, try traceroute.
>>>>> Probably it won't show you anything interesting, it hardly ever does,
>>>>> but it might add another clue. Double check iptables, I know you said
>>>>> it was off, but I have been stumped by iptables so many times I never
>>>>> discount it now. Clear any routing tables you added - openswan will
>>>>> create its own routes. Especially if you are using netkey, adding your
>>>>> own routes can cause problems. When you are sending from vpn01a to
>>>>> vpn01b, you say the esp packets are not showing up, is any traffic
>>>>> showing up? if regular pings from external address to external address
>>>>> are working while encapsulated packets are not, then that supports the
>>>>> theory that something is blocking it. Again, check your iptables, it'll
>>>>> get you every time....
>>>>> Hope something in there helps :)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I guess SSL based VPN (like openVPN) is currently the only way to go in
>>>>>> the amazon cloud or just use Amazon VPC.
>>>>>>
>>>>>>
>>>>> A colleague of mine and I were talking about cloud computing today.
>>>>> Both of us are extremely skeptical when it comes to reliability,
>>>>> security, downtime, etc. How are you finding it so far?
>>>>>
>>>>>
>>>>>> Thanks
>>>>>> Alex
>>>>>>
>>>>>>
>>>>> Bob Miller
>>>>> 334-7117/660-5315
>>>>> http://computerisms.ca
>>>>> bob at computerisms.ca
>>>>> Network, Internet, Server,
>>>>> and Open Source Solutions
>>>>>
>>>>>
>>> Bob Miller
>>> 334-7117/660-5315
>>> http://computerisms.ca
>>> bob at computerisms.ca
>>> Network, Internet, Server,
>>> and Open Source Solutions
>>>
>>
> Bob Miller
> 334-7117/660-5315
> http://computerisms.ca
> bob at computerisms.ca
> Network, Internet, Server,
> and Open Source Solutions
>
More information about the Users
mailing list