[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 11:30:32 EST 2010
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?
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
The nodes can communicate but phase 1 cannot be established and I get
NO_PROPOSAL_CHOSEN on DC host.
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
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
----------------
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
---------------
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
---------------------
--------------------
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?
Thanks
Alex
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
>
More information about the Users
mailing list