Koozali.org: home of the SME Server

IPSEC v5.6 Hell

Walter Padgett

IPSEC v5.6 Hell
« on: September 09, 2003, 06:42:13 AM »
Good Evening,

I'm having hell with IPSEC/VPN on a 5.6 box. I've used Mr. May's, Lord Shad's, and e-smith.dyndns.org's freeswan contribs with no luck. I've reinstalled so many times I'm out of fingers. I run across a new error the other day with it saying something about KLIPS not being installed. I had more success with v5.1.2 and an IPSEC/VPN tunnel than I've ever had with 5.6. What's the consensus out there concerning which contrib is the best?

Lately after installing one of the various contribs, I don't even show an IPSEC interface.

Anyone have a Remington 870 Express 12-guage shotgun?

Later

Wally

Randall Perry

Re: IPSEC v5.6 Hell
« Reply #1 on: September 09, 2003, 06:36:21 PM »
You would be better off to use a dedicated IPCop box.
a 486 is the practical minumum, but with IPSec tunnel you want at least a P166 with 32 MB RAM.

Maggard

Re: IPSEC v5.6 Hell
« Reply #2 on: September 09, 2003, 08:12:33 PM »
Randall Perry wrote:
 
> You would be better off to use a dedicated IPCop box.

Lets not get into distribution battles.

IPCop is excellent for what it does (firewall/router/web services) and e-smith at what it does (easy to manage all-in-one for small & medium sized sets of folks.)

While the both overlap in some places each distrib is different enough that folks using one aren't likely to want the other.

He'd be better off using a dedicated IPCop box if VPN'ing were the only goal. Or just go with two consumer routers that offer VPN/tunnels.But if the goal is also the things e-smith excels at then the declaration isn't particularly warranted.

Perhaps just suggesting IPCop for consideration would be better then blindly prescribing it.

Personally I've found when dealing with finicky networking stuff a second set of eyes are invaluable. Doesn't need to be someone super techy, just able to follow what is going on. Heck having to explain something step-by-step while going through it often points up where the problem is.

Thus my suggestion would be to invest in some beers and a pizza, invite a buddy over and start fresh with a pile of printouts. Write down each setting as entered, check off each step as it is completed, copy every results message. Failing that asking here for an install-buddy would probably get someone willing to walk through the procedure doing 'bout the same thing.

Steve Bush

Re: IPSEC v5.6 Hell
« Reply #3 on: September 09, 2003, 10:50:34 PM »
I would have to agree with Randall on this one.  If someone isn't going to invest in Mitel's service link, it is much simpler to use a seperate VPN device and keep SME vanilla.  There are lots of options for VPN's, IPCOP being one that I use.

Randall Perry

Re: IPSEC v5.6 Hell
« Reply #4 on: September 09, 2003, 10:50:52 PM »
I didn't mean to suggest that IPCop is better.
But now that I reread my post, it does come off that way.

For me, I use dedicated IPCop boxes for the firewalling
and will use eSmith inside of that for servers.

Yes, sometimes you just have to get some perspective on the problem and take a break for a couple of minutes.

I once tried setting up an IPSec tunnel using physical local box as (left) and the remote as (right) and then tunneled into the other box and configured its local as left again and the box at my location as right.

Ah, lack of sleep does that.

Walter Padgett

Re: IPSEC v5.6 Hell
« Reply #5 on: September 10, 2003, 01:16:42 AM »
Good Afternoon,

I've used IPCOP and SmoothWall before but I am trying to stick to one distro at this school. I've used SME since v3.x and like it very well. So back to my original post that specifically talked about SME and the various contribs, any ideas on which contrib would be the best for what I'm trying to accomplish?

Later

Wally

Walter Padgett

Re: IPSEC v5.6 Hell
« Reply #6 on: September 10, 2003, 06:39:54 AM »
Good Evening,

Ok answer this. If I were to go with IPCOP on both ends to create a tunnel, how would it route the traffic based on the following information.

Site 1
172.17.1.1 - external ip is the mail and www server address
172.17.1.5 - this is my proxy server w/ content filtering using a separate external ip address. Also the default gateway address given out by my Win2k DHCP server on the LAN
172.17.1.6 - this is just a server sitting there routing the unfiltered web traffic for administrators - this is just a straight 5.6 box straight out of the box that I've reformatted and installed all three different ipsec contribs that I mentioned.

Site 2
172.18.1.1 - the proxy server and firewall - Also the default gateway address given out by my Win2k DHCP server on the LAN.
172.18.1.3 - this is just a server sitting there routing the unfiltered web traffic for administrators - this is just a straight 5.6 box straight out of the box that I've reformatted and installed all three different ipsec contribs that I mentioned.

So with this information, how would I add an IPCOP box to this mix and be able to route traffic for the other network through it if it is not my default gateway to the LAN? Now remember that I don't want to put any of the SME boxes behind an IPCOP firewall.

Another little note, the Cisco 1601 routers are setup to route 172.16.?.? 172.17.?.? and 172.18.?.? traffic through it's own IPSEC tunnel but that would mean that I would need to plug the Cisco 1601 router directly up to the LAN if I understand it correctly. I'm about to go crazy here because I believe I need to learn more but don't have the time to stop everything and go to college. A family of five kids (4 girls, 1 boy) kind of puts a stop to that.

I appreciate all the help that this forum has provided.

Later

Wally

Randall Perry

Re: IPSEC v5.6 Hell
« Reply #7 on: September 10, 2003, 08:00:56 AM »
You _can_ use the e-smith box for a tunnel, but for me it was easier to match the other ends to IPCop boxes.  I also can toy with the e-smith without losing my valuable VPN tunnel.

In using the IPCop box, think of it as just a router.  No, it does not have to be the default gateway, but just be pointed to when routing to for the 192.168.1.x network (or whatever the other segment is).

I don't know how your Cisco routers plug into this (or why you don't continue to use them).  If your Ciscos aren't plugged into the network now, then what network segments are they connecting?

If you could, draw up a network diagram (Dia, Actrix, Visio..) and then email it to me.   I would like to have a better understanding of what you have and what you want to do.

Terry

Re: IPSEC v5.6 Hell
« Reply #8 on: September 10, 2003, 08:09:41 AM »
Wouldn't it be better for someone who knows what they are doing to be mucking with an active network instead of yourself?
Or is this just a hypethetical situation?

I know this sounds bad, but geez it sounds like this user has been comprimised by this.

I guess if it's all been for testing an In Work solution all is still OK...

Boris

Re: IPSEC v5.6 Hell
« Reply #9 on: September 10, 2003, 09:35:18 AM »
If you want to use site to site VPN, networks on both sides mast be different, otherwise you router wouldn't know that it has to pass traffic to the other side of the VPN tunnel.
In you example both sites have subnets 192.168.1.x , then it should be 192.168.1.x on one side and lets say 192.168.2.x (255.255.255.0) on the other.

This is true the for any VPN (SME, IpCop or any other VPN capable router).

Start with planning your network, confirm your drawings with network profesional, then start configuring.

Walter Padgett

Re: IPSEC v5.6 Hell
« Reply #10 on: September 10, 2003, 05:49:20 PM »
Good Morning,

I only threw in the Cisco routers as an after thought. The networks are protected completely from the outside world. My problem last year was that folks weren't checking their email and clogging up the SME server that I had setup. This year I wanted to separate the functions.

1. Proxy Server
2. Web/Email Server
3. VPN Server

The Cisco routers are not managed by myself but by the ISP that provides Internet to the school.

Oh well, I'll figure it out.

Later,

Wally

Walter Padgett

Re: IPSEC v5.6 Hell
« Reply #11 on: September 29, 2003, 04:43:01 AM »
Good Afternoon,

I'm still in hell I guess. I've tried about everything I can think of. Here's my network layout simply:

Note: All these boxes have separate inside addresses as well as separate external addresses.

Site 1 - Main Site

171.17.1.1 << Mail/web server with external ip address matching the domain name. SME 5.6 plain with nothing installed but portforwarding and oneorzero helpdesk. That's it nothing more.

172.17.1.5 << Proxy server and default gateway to local network. Port forwarding installed, content filtering, and netprobe. I have put in a route add statement that redirects all traffic to the other site's network (172.18.*) to go to 172.17.1.6. I installed Shad Lord's freeswan contrib as well as followed his how-to with no success. Ifconfig doesn't even show an ipsec0 but in the server-manger, it shows the IPSEC VPN panel and gives me a secret.

172.17.1.6 << IPCOP v1.3.0 -- stock install, changed squid.conf to make the port for the proxy be 3128 instead of 800. Created a VPN and used a key that I had saved from a previously working SME 5.1.2 VPN as the secret. Exported the vpn information so I could import it on the other side.

When I do a tracert from the Win2k server on the inside of the network to the remote side's server, it will hop through the ipcop box then to the local cisco router and then finally to the remote cisco router. It dies here.

I get on the IPCOP box and ping the internal address of the remote IPCOP and it doesn't do anything.

Site 2 - Remote Site

172.18.1.1 << SME 5.6 stock install with only port forwarding installed. A route add directs all traffic bound for 172.17.* to route through 172.18.1.3.

172.18.1.3 << IPCOP 1.3.0 stock install and nothing changed. Imported the vpnconfig.dat file from the main site's IPCOP box. Both sides opened up and showed to be running. I got on the IPCOP box and was not able to ping the internal IP address of the main site's IPCOP box. I got on the Win2k server at the remote site and was able to ping the internal address of the main site's IPCOP box. I was also able to putty to the main site's IPCOP box using the internal IP address of the main site's IPCOP box.

Both sides show some traffic. The only thing I really need to do right now is to allow the MS Outlook clients to attach to the mail server on the main site using the internal IP address (172.17.1.1).

Would I be better served going back to 5.1.2? I've heard and read both sides of this argument. On one side folks say that everything with Shad Lord's contrib on 5.6 works and others say it doesn't and they are going back to <5.5 as fast as they can. I'm cornfused!!!

On another note that I've briefly touched on earlier in this thread was that the two Cisco 1601 routers that I have at both locations will route 172.16.* traffic from one site to the other site through an IPSEC tunnel. I have been trying to figure out how I would setup a box that could utilize this tunnel without jeapordizing(?) the local networks at both sides.

A penny for your thoughts, and yes, this is truly Walter Padgett not some anonymous person,

Walter "Wally" Padgett

Walter Padgett

Re: IPSEC v5.6 Hell
« Reply #12 on: September 30, 2003, 07:31:44 AM »
Good Evening,

I guess IPCOP isn't the answer because everyone that jumped in and said that it was the best solution are strangely silent.

I'm going to go ahead and downgrade the servers that host the VPN to v5.1.2. The VPN contribs worked beautifully with that version.

Later

Wally

Steve Bush

Re: IPSEC v5.6 Hell
« Reply #13 on: September 30, 2003, 11:19:08 AM »
I wouldn't recommend using SME5.1.2, as it is no longer supported by Mitel.
SME6.0b3 is the best choice, but without Mitel's servicelink, it may not be the easiest choice for VPN's at the moment.
The second easiest choice other than servicelink is to seperate out the VPN service from your SME server and use a dedicated firewall/vpn device.
I have used IPCOP and it is simple to setup and easy to update, I'm sure there are other choices as well.