IPSEC Woes
Well, this was a long weekend for me. In the same weekend that I found a killer bug in some borrowed code, I lost my router. It was a decent router, Cyber Guard sg360. Ran on a linux kernel with PPTP and IPSEC support. The ipsec we used to connect remote extensions to our asterisk phone system across the internet. Great system when it worked (voice quality is still unbelievably good).
But one day, my router decided it had routed it's last packet. Of course, there are not many good places around here to buy a new router at midnight, and I prefer to work at nights, so I started a journey. I already had a good router to replace the old one with, but of course this new piece of equipment didn't support ipsec. There is only 1 nic in my asterisk server, so to me, putting it directly on the internet was a bad idea. In comes Kernel 2.6 to save the day. I decided to setup the new router to use asterisk box as a dmz host ( which means all traffic is routed directly to it on a specific public ip ). That worked well, and I was receiving calls again within minutes. Then came time to get my remote extensions setup. Honestly, I had not worked with the new ipsec tools built into the 2.6 linux kernels until now, so the experience was a bit intimidating. But I started anyway.
My remote end router was a Cyber Guard sg560. That end was not on NAT, though I was, which means only 1 thing. NAT-T. Using setkey, I established my setkey.conf with an appropriate set of rules for routing. ( After my problem, I also ended up with a lot of rules that are entirely unnecessary ). So I move to racoon. Racoon is an open source product that establishes the vpn connection using ike to negotiate the keys. Its a very friendly system with an understandable config file. In it's entirety, for 1 point to point tunnel connection, I used maybe 10 commands. It seemed very easy to do, until it didn't work.
Anyway, I finished editing the files, saved, started racoon, then started a ping to the remote end. NOTHING. I checked syslog, and to my dismay, there were errors:
Feb 8 00:00:21 phone1 racoon: 2009-02-08 00:00:21: INFO: initiate new phase 2 negotiation: my.internal.ip[4500]<=>other.external[4500]
Feb 8 00:00:21 phone1 racoon: 2009-02-08 00:00:21: WARNING: remote address mismatched. db=my.internal.ip1[4500], act=other.external[500]
This seemed to be very easily a NAT problem, so I verified that my linux box had the option : nat_traversal on;
All was good there, but still no connection. Until it dawned on my that the OTHER end needed to be aware of it as well. So, I login to my neighbor sg560, and suddenly notice, there is no option to enable nat. Frenzy time! I search the internet, I search the mfg site, I search my soul. Definitely no luck there. Until I once again notice an obscure reference to the fact that cyber guard is actually using FreeSwan for its ipsec. Life just got a lot easier. A quick visit to free swan docs tell me that I need the following option set :
nat_traversal = yes
So, I re-visit my sg560, click on advanced in the menu, click on configuration files tab. Scroll down to ipsec.conf and click the button to edit. Add my line to config setup, ping, and finally I can sleep. My weekend night mare is done -- until I noticed a leak coming from the bathroom. Another story for another day.