[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
Wed Nov 17 17:31:55 EST 2010
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
More information about the Users
mailing list