From: Phillip H. <ss...@gm...> - 2006-10-21 17:58:43
|
I'm trying to connect to a Sonicwall TZ170, and I haven't determined if something is wrong with the sonicwall or if I just don't understand ipsec and my racoon.conf and spd entries are not set up right. Phase 1 succeeds no problem. But during phase 2 the sonicwall responds with no proposal chosen if I use a.b.c.d/32 as my local ID (a.b.c.d. is my public IP). All the other stuff (encryption=3des, authentication=hmac_sha1, pfs=none) match just fine. If I change my local ID to 0.0.0.0/0, then phase 2 works! But it's no good because then the sonicwall sends me all this traffic that's not even destined for me, and I'm not talking about just broadcast packets either. That's great if I want to spy on what everyone at work is doing, but it slows my Internet down significantly, so it's not a good long-term solution. So what am I missing here? Am I supposed to be using 0.0.0.0/0 as my local ID, and the sonicwall is just dumb for sending me extra traffic. Or am I supposed to use a.b.c.d/32 and the sonicwall is dumb for rejecting me? I was thinking, oh, well it's obvious because the sonicwall probably doesn't have a policy for a.b.c.d/32. But I can't really ask the sonicwall administrator to create a policy just for me. How does it work fine for everyone else like road-warriors and such? Everyone else that uses windows can connect with sonicwall's vpn client no problem. I wish I knew what the sonicwall vpn client was putting as the local ID, then I would get a clue. Actually, I hacked their client and found out. It puts 0.0.0.0/0[68] UDP as the local ID and 192.168.0.0/16[67] UDP as the remote ID. I believe that creates a policy that lasts just long enough to get a "virtual IP address". I don't even know if ipsec on linux can do the whole "virtual IP address" thing, but I don't believe I need it since I have a public IP. What negotiations happens after that I don't know. I already posted on the sonicwall forums and no one answered. I think it's because no one there is smart enough to know what I'm talking about. Heck, I hardly know what I'm talking about. But you guys might :) Thanks, Phillip |
From: Kimmo K. <ko...@gm...> - 2006-10-22 16:20:52
|
Phillip Hellewell wrote: > I'm trying to connect to a Sonicwall TZ170, and I haven't determined if > something is wrong with the sonicwall or if I just don't understand ipsec > and my racoon.conf and spd entries are not set up right. > > Phase 1 succeeds no problem. But during phase 2 the sonicwall responds > with no proposal chosen if I use a.b.c.d/32 as my local ID (a.b.c.d. is my > public IP). All the other stuff (encryption=3des, > authentication=hmac_sha1, pfs=none) match just fine. > > If I change my local ID to 0.0.0.0/0, then phase 2 works! But it's no good > because then the sonicwall sends me all this traffic that's not even > destined for me, and I'm not talking about just broadcast packets either. > That's great if I want to spy on what everyone at work is doing, but it > slows my Internet down significantly, so it's not a good long-term > solution. > > So what am I missing here? Am I supposed to be using 0.0.0.0/0 as my local > ID, and the sonicwall is just dumb for sending me extra traffic. Or am I > supposed to use a.b.c.d/32 and the sonicwall is dumb for rejecting me? Sonicwall is not dumb when it sends all traffic to you, if 0.0.0.0/0 is in IPsec SA. But it is dumb if it negotiates such SA's with you. If I remember correctly, you can also IP address without mask as your local id, but that is probably not the correct answer. > Actually, I hacked their client and found out. It puts 0.0.0.0/0[68] UDP > as the local ID and 192.168.0.0/16[67] UDP as the remote ID. I believe > that creates a policy that lasts just long enough to get a "virtual IP > address". I don't even know if ipsec on linux can do the whole "virtual IP > address" thing, but I don't believe I need it since I have a public IP. > What negotiations happens after that I don't know. Well, one way is to use virtual IP's and mode config (see mode_cfg in racoon.conf). Mode config is "phase 1.5" and it is not dhcp, it does use IKE ports and not dhcp ports as in your example id's. So your example is not mode_cfg. There also is draft that specifies dhcp-over-ike (so that dhcp exchange is carried over IKE exchange). Your setup seems not to be dhcp-over-ike either. To me it seems that: 1. client and sonicwall "server" negotiates IKE SA and the IPsec SA for dhcp 2. get's the virtual IP using dhcp, using standard dhcp exchange (not to broadcast address but to the real dhcp server address) 3. negotiates new IPsec SA for that virtual IP I think ipsec-tools does not directly support this kind of setup. You having public IP address does not mean that you don't need virtual IP. Administrator of the other peer has defined that virtual IP's are used, that is usually because of routing. With that setup, administrator can route your plain text traffic back to the sonicwall so that it can be encrypted and sent to you. Without virtual IP's (or NAT that is done by IPsec) your plain text traffic could route directly back to you without encryption. If virtual IP's are not used, remote IPsec can do old fashioned NAT to the traffic, but other processes cannot do that NAT because IPsec-process is the only one that knows the mapping between local ID and IPsec SA. So, using virtual IP's helps administrator to do routing and using "IPsec based NAT" is done to do routing and to help return right traffic to the right IPsec SA. > I already posted on the sonicwall forums and no one answered. I think it's > because no one there is smart enough to know what I'm talking about. Heck, > I hardly know what I'm talking about. But you guys might :) Well, it is not easy to give right answer, maybe you should ask from your admin that is that setup some kind of dhcp-over-ike. Best Regards Kimmo Koivisto |
From: Phillip H. <ss...@gm...> - 2006-10-22 23:31:23
|
I forgot to forward this to the whole list. ---------- Forwarded message ---------- From: Phillip Hellewell <ss...@gm...> Date: Oct 22, 2006 5:28 PM Subject: Re: [Ipsec-tools-devel] Phase 2 fails (no proposal chosen) To: Kimmo Koivisto <ko...@gm...> On 10/22/06, Kimmo Koivisto <ko...@gm...> wrote: > > > Sonicwall is not dumb when it sends all traffic to you, if 0.0.0.0/0 is in > IPsec SA. But it is dumb if it negotiates such SA's with you. That explains a lot. I agree 100%. It's funny though; you'd think if it was lax enough to let you negotiate as 0.0.0.0/0, then it would also let you negotiate as a.b.c.d/32. I also really, really, can't believe the security is so screwed up that it will accept 0.0.0.0/0 and then send you everyone's traffic. If I remember correctly, you can also IP address without mask as your local > id, but that is probably not the correct answer. While I was debugging, I noticed that it was sending the ID as an ipv4_address not an ipv4_subnet. So I temporarily hacked the ipsec code to force it to use ipv4_subnet. Unfortunately, the sonicwall still did not accept it. Well, one way is to use virtual IP's and mode config (see mode_cfg in > racoon.conf ). Mode config is "phase 1.5" and it is not dhcp, it does use > IKE > ports and not dhcp ports as in your example id's. So your example is not > mode_cfg. There also is draft that specifies dhcp-over-ike (so that dhcp > exchange is carried over IKE exchange). Your setup seems not to be > dhcp-over-ike either. Hmm, I think sonicwall's client actually is doing mode_config, but not for getting a virtual IP. In wireshark I can see a few messages back and forth called "ISAKMP Transaction (Config Mode)". Those get sent after ISAKMP Agressive (phase 1) and before ISAKMP QUICK (phase 2). So maybe it is doing mode config, but I think its only purpose is for the server to hint to the client what encryption, etc. to use with phase 2. I don't think this part has anything to do with the virtual IP. Yeah, I think the virtual IP thing happens afterwar phase 2. My guess was that it uses normal DHCP somehow. To me it seems that: > > 1. client and sonicwall "server" negotiates IKE SA and the IPsec SA for > dhcp > 2. get's the virtual IP using dhcp, using standard dhcp exchange (not to > broadcast address but to the real dhcp server address) > 3. negotiates new IPsec SA for that virtual IP Yes yes! I bet that is what's happening. So does step 3 mean like redoing phase 2 again? See I never knew that was allowed, but I guess there's no reason why not. That would explain how they are able to do everything. I think ipsec-tools does not directly support this kind of setup. Yeah, I was just going to ask that. I didn't think so either. One thing I don't understand though is, how can they claim interoperability with other routers and software implementations if they don't support anything except their own crazy 3-step process that only works with their proprietary client? I guess the answer is that they do support interoperating if you create a specific policy for it. But they don't really support interoperability for road warriors and other setups that are more dynamic, _unless_ you use their proprietary client :( The sad thing is, before my work upgraded the sonicwall firmware, I could connect from Linux just fine! I used a.b.c.d/32 as my ID and it liked me. It's so funny to me that now it will accept 0.0.0.0/0, but it won't accept a.b.c.d/32. So I can still connect from linux, but only if I want to slow my Internet down. It's so crazy! You having public IP address does not mean that you don't need virtual IP. > Administrator of the other peer has defined that virtual IP's are used, > that > is usually because of routing. > With that setup, administrator can route your plain text traffic back to > the > sonicwall so that it can be encrypted and sent to you. Without virtual > IP's > (or NAT that is done by IPsec) your plain text traffic could route > directly > back to you without encryption. I understand how not having a virtual IP can make things harder, especially when you throw NAT into the mix. For instance, if you try to ping my public IP from a computer inside the sonicwall network, how does the sonicwall know whether to encrypt and send it through the VPN or to just send it directly? I don't know the answer to that exactly, but it didn't cause (too much) of a problem for me before. I think it did cause a few weird quirks, but I had things working pretty good actually. There aren't many things that require them to be able to connect to my linux server. Usually I am the one initiating the connections, and then everything seems to work fine. But you are right, it did cause a few weird problems. If virtual IP's are not used, remote IPsec can do old fashioned NAT to the > traffic, but other processes cannot do that NAT because IPsec-process is > the > only one that knows the mapping between local ID and IPsec SA. > > So, using virtual IP's helps administrator to do routing and using "IPsec > based NAT" is done to do routing and to help return right traffic to the > right IPsec SA. Yeah. I guess it would be helpful if we could figure out some way to do virtual IP's with Linux and ipsec-tools, but for now I would be content if I could just get it to work without them. > I already posted on the sonicwall forums and no one answered. I think > it's > > because no one there is smart enough to know what I'm talking > about. Heck, > > I hardly know what I'm talking about. But you guys might :) > > Well, it is not easy to give right answer, maybe you should ask from your > admin that is that setup some kind of dhcp-over-ike. > Unfortunately, I don't think he really knows what it's doing either. It's just the sonicwall default way of doing things. However, I doubt it uses that method for router-to-router kind of setup. If I can talk my administrator into adding a policy specifically for my public IP, I think that would do it. But why should he have to do this for anyone running linux and not windows users? Not to mention the fact that when comcast issues me a new IP address (it's not static), I'll have to have him setup that policy again. He's not going to want to do that. Bummer :( Thanks, Phillip |