Koozali.org: home of the SME Server
Obsolete Releases => SME 7.x Contribs => Topic started by: ldkeen on March 07, 2007, 10:49:01 AM
-
IPSec Network-to-Network VPN SME Server 7.1 HOWTO
Author(s): Lloyd Keen, David Biczo
Revised: 7th March 2007
Summary: The purpose of this howto is to guide you through the procedure to connect two private subnets, both behind servers running SME Server version 7.1 in server/gateway mode via an encrypted tunnel using IPsec (sometimes referred to as NETKEY or Kernel IPsec). Both servers have static IP’s on the external interface using PPPoE or bridged Ethernet. NETKEY under linux 2.6 works a bit different to Ipsec under linux 2.4, the most obvious difference being that there is no visible ipsecx device as such. This document serves as a guide only, it worked for us but YMMV. As usual “all care but no responsibility taken”. Comments and suggestions are welcome. If you don’t feel comfortable following the procedure described below, then I have written a script which will prompt you for the required settings and automate the process for you. You can download the script here. This script is written for my personal use - if you can get any benefit from it - great, but if it doesn't work then you're on your own. You can download the script from here: http://www.comnetel.com/sme7_ipsec/ipsec_install.sh
SECTION A:
Procedure smeserverA:
#mcedit /etc/sysconfig/network-scripts/ifcfg-ipsec0
and enter the following information:
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK
SRCNET=192.168.aa.0/24 (smeserverA’s LAN address)
DSTNET=192.168.bb.0/24 (smeserverB’s LAN address)
SRCGW=xxx.xxx.xxx.xxx (smeserverA’s Gateway address)
DST=xxx.xxx.xxx.xxx (replace xxx’s with smeserverB’s external static IP)Now add the preshared key into /etc/sysconfig/network-scripts/keys-ipsec0
#mcedit /etc/sysconfig/network-scripts/keys-ipsec0
and add the following line:
IKE_PSK=my_shared_secret
Procedure smeserverB:
#mcedit /etc/sysconfig/network-scripts/ifcfg-ipsec0
and enter the following information:
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK
SRCNET=192.168.bb.0/24 (smeserverB’s LAN address)
DSTNET=192.168.aa.0/24 (smeserverA’s LAN address)
SRCGW=xxx.xxx.xxx.xxx (smeserverB’s Gateway address)
DST=xxx.xxx.xxx.xxx (replace xxx’s with smeserverA’s external static IP)
Then add the preshared key into etc/sysconfig/network-scripts/keys-ipsec0
#mcedit /etc/sysconfig/network-scripts/keys-ipsec0
and add the following line:
IKE_PSK=my_shared_secret
NOTE: If you have a PPPoE connection you don't want the interface to come up at boot time (ONBOOT=no). You need IPSec to come up AFTER the ppp interface. You can address this issue by modifying /etc/ppp/ip-up.local and /etc/ppp/ip-down.local scripts as described later in this document. If you have a bridged Ethernet connection then you can set this option to ONBOOT=yes.
Now open up the server-manager on both servers and add the appropriate network settings into the "Local Networks" panel.
For example on smeserverA you would enter the following values:
Network Address: 192.168.bb.1
Subnet Mask: 255.255.255.0
Router 192.168.aa.1
And on smeserverB you would enter the following:
Network Address: 192.168.aa.1
Subnet Mask: 255.255.255.0
Router 192.168.bb.1
SECTION B:
This section contains information on modifying the firewall and installing modified scripts to fix routing issues.
#mkdir -p /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/
#cd /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/
#mcedit 15AllowIPsec
and add the following:
/sbin/iptables -A INPUT -i $OUTERIF -p udp --sport 500 --dport 500 -j ACCEPT
/sbin/iptables -t mangle -A PREROUTING -i $OUTERIF -p 50 -j MARK --set-mark 1
/sbin/iptables -A INPUT -i $OUTERIF -m mark --mark 1 -j ACCEPT
/sbin/iptables -A FORWARD -i $OUTERIF -m mark --mark 1 -j ACCEPT
/sbin/iptables -t mangle -A PREROUTING -i $OUTERIF -p 51 -j MARK --set-mark 2
/sbin/iptables -A INPUT -i $OUTERIF -m mark --mark 2 -j ACCEPT
/sbin/iptables -A FORWARD -i $OUTERIF -m mark --mark 2 -j ACCEPT
Make sure to leave a blank line at the top of the file and a carriage return at the end of the file, then do:
#/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
#/etc/init.d/masq restart
There appears to be a bug in the way ifup-ipsec and ifdown-ipsec sets up the routing so you will need to install modified versions of these scripts from here www.comnetel.com/sme7_ipsec. For more information about this bug see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146169. There is some minor code duplication in the scripts, but it works. If you have any comments or suggestions we’d be glad to hear them. Any changes made in the scripts have been documented where applicable.
#cd /etc/sysconfig/network-scripts
#mv ifup-ipsec ifup-ipsec.old
#mv ifdown-ipsec ifdown-ipsec.old
#wget http://www.comnetel.com/sme7_ipsec/ifup-ipsec
#wget http://www.comnetel.com/sme7_ipsec/ifdown-ipsec
If you have a bridged Ethernet connection you can skip the next section
and either reboot or bring up the tunnel with the following command:
#/sbin/ifup ipsec0
SECTION C:
Only complete this section if you have a PPPoE connection on the external interface. And finally as mentioned previously in this document, we need to add a command to bring up the tunnel automatically at boot time.
Modify /etc/ppp/ip-up.local
#mkdir –p /etc/e-smith/templates-custom/etc/ppp/ip-up.local
#cd /etc/e-smith/templates-custom/etc/ppp/ip-up.local
#mcedit 40ipup15ipsec
and add the following code to the file:
case $IPPARAM in
pppoe)
/sbin/ifdown ipsec0
sleep 5
/sbin/ifup ipsec0
;;
*)
esac
Then expand the template
#expand-template /etc/ppp/ip-up.local
Modify /etc/ppp/ip-down.local
#mkdir –p /etc/e-smith/templates-custom/etc/ppp/ip-down.local
#cd /etc/e-smith/templates-custom/etc/ppp/ip-down.local
#mcedit 40ipdown15ipsec
and add the following code into this file:
IPPARAM=$6
case $IPPARAM in
pppoe)
/sbin/ifdown ipsec0
;;
*)
esac
Then expand the template
#expand-template /etc/ppp/ip-down.local
Reboot or bring up the tunnel with the following command:
#/sbin/ifup ipsec0
This completes the setup of the IPSec tunnel and you should now be able to ping between PC’s on the different subnets. This has been working great for us but any feedback would be appreciated.
Regards, Lloyd & David
-
hi together!
i encounterd the following problem:
VPN connection with 2 SME Server
192.168.1.202<---->192.168.1.251<----->xxx.xxx.xxx.xxx<------>xxx.xxx.xxx.xxx<----->192.168.0.254<---->192.168.0.75
internal IP external ip external ip internal ip
SME A SME B
Now:
ping from 192.168.1.251 to 192.168.0.254 OK
ping from 192.168.0.251 to 192.168.1.251 OK
ping from 192.168.1.52 to 192.168.0.75 OK
Ping from 192.168.0.75 to 192.168.1.52 not ok
It seems like that only ip 192.168.0.254 can see the 192.168.1.0/24 network
but not the whole 192.168.0.0/24 network
Network 192.168.1.0/24 can see 192.168.0.0/24
any ideas whats maybe wrong?
could it be possible, that a cable modem blocks something?
and what i also saw:
one of the files which should be downloaded (15AllowIPsec) is missing on the server
regards
Karl
-
SOLVED
i forgot to set SME A as default gateway on the 192.168.1.0/24 network machines, cause this network has 2 gateways
best regards
Karl
-
one of the files which should be downloaded (15AllowIPsec) is missing on the server
Thanks Karl, I've put it back up now.
Lloyd
-
now that the networks know and see each other i encountered another problem:
if i try to reach a http-server on the other network there is no response:
192.168.0.24->192.168.1.102
the machines are pingable each other
is http protocol not possible?
best regards
Karl
-
Karl,
I don't think that IPsec has anything to do with this. I think the firewall on 192.168.1.1 is blocking the request. On 192.168.1.1 try forwarding port 80 to 192.168.1.102 then try again.
Regards, Lloyd
-
deleted
-
Hi All,
Thanks, Lloyd, very much for your howto!
I'm trying to implement it, and I'm having some problems.
I wanted to point out what I think may be a small error in your install script (not the howto, exactly). It does not enter the "IKE_METHOD=PSK" bit in the /etc/sysconfig/network-scripts/ifcfg-ipsec0 file, so I just added it by hand.
After I went through the howto manually, the tunnel came up and I was able to ping from a host on Net A to a host on Net B. But after a reboot, I cannot ping (or anything else) across the VPN.
I am at a loss to troubleshoot this as I'm not familiar with the new (kernel) IPsec. I think it was easier to troubleshoot open/freeswan. I'm also a little hesitant to change things because a) it looks right to me and b) it worked once.
I do know that the tunnels come up if I ping from a host on Net A to Net B, but the ping fails. I see this in /var/log/messages:
Mar 17 16:38:55 sol racoon: INFO: IPsec-SA request for 207.182.36.206 queued due to no phase1 found.
Mar 17 16:38:55 sol racoon: INFO: initiate new phase 1 negotiation: 24.255.24.230[500]<=>207.182.36.206[500]
Mar 17 16:38:55 sol racoon: INFO: begin Aggressive mode.
Mar 17 16:38:55 sol racoon: NOTIFY: couldn't find the proper pskey, try to get one by the peer's address.
Mar 17 16:38:55 sol racoon: INFO: ISAKMP-SA established 24.255.24.230[500]-207.182.36.206[500] spi:79b911d73d80e49d:d75f2a5d13318d91
Mar 17 16:38:56 sol racoon: INFO: initiate new phase 2 negotiation: 24.255.24.230[0]<=>207.182.36.206[0]
Mar 17 16:38:56 sol racoon: INFO: IPsec-SA established: AH/Tunnel 207.182.36.206->24.255.24.230 spi=128242889(0x7a4d4c9)
Mar 17 16:38:56 sol racoon: INFO: IPsec-SA established: ESP/Tunnel 207.182.36.206->24.255.24.230 spi=261946672(0xf9cfd30)
Mar 17 16:38:56 sol racoon: INFO: IPsec-SA established: AH/Tunnel 24.255.24.230->207.182.36.206 spi=69429640(0x4236988)
Mar 17 16:38:56 sol racoon: INFO: IPsec-SA established: ESP/Tunnel 24.255.24.230->207.182.36.206 spi=268012479(0xff98bbf)
The same is not true if I try to bring up the connection by pinging from a host on Net B to Net A. Might this indicate I have an issue on Server B?
If I look in /var/logs/iptables/current, it doesn't show any dropped packets on either server.
I have tried manually 'ifup' and 'ifdown' as well as 'masq restart'.
Both my servers are 7.1.2 and are in server-gateway mode.
Does anyone have any troubleshooting tips or suggestions for me?
Has anyone ever heard of an ISP doing anything to break IPsec? One of these connections is on Cox Cable...and they block certain ports...like SMTP and HTTP.
Thanks,
G
-
It does not enter the "IKE_METHOD=PSK" bit in the /etc/sysconfig/network-scripts/ifcfg-ipsec0 file, so I just added it by hand.
Thanks for that, I'll check it out. As you probably noticed it was my first attempt at scripting something :-)
Are you using Wondershaper (QoS) at all? We have found some problems with the Wondershaper script causing problems with IPsec which we are going to look at next week. Also found a nasty bug that dropped the tunnel after a succesful VPN connection which we fixed about 2 weeks ago. Maybe compare "route -n" at both ends. Do you have PPPoE at both ends?
Lloyd
-
Check both /etc/ppp/ip-up.local and /etc/ppp/ip-down.local and make sure that the ipsec device mentioned there matches your ipsec device.
Lloyd
-
Thanks again, Lloyd.
The /etc/ppp/ip-up.local and /etc/ppp/ip-down.local scripts don't mention IPsec and I suspect they don't apply to me as I'm not using PPPoE.
I compared the routing (again) at your suggestion. I did notice a bit of funkiness concerning the gateway setting of the route to the remote subnet, so I experimented some by editing /etc/sysconfig/network-scripts/ifcfg-ipsec0 without success.
In your howto, you enter the gateway address like this:
SRCGW=xxx.xxx.xxx.xxx (smeserverA’s Gateway address)
Is this really supposed to be the server's gateway address (which is probably the default gateway on the server)? Or should it be the external interface on the server? In any case, I could get the tunnel to come up, but I had no success passing data.
Yes, in answer to your question about WonderShaper. Both of these boxes are SAIL/Asterisk boxes. However I already tried turning it off to see if that made a difference:
/etc/init.d/qosd stop
/etc/init.d/qosd start
I am beginning to think I need to build a couple of vanilla test boxes... ;-)
Anyway, thanks again for your help so far!
G
-
Is this really supposed to be the server's gateway address
Yes, don't get this confused with the server's external IP. You need to enter the gateway IP for the routing to work correctly.
If you've been running qos I don't think turning it off is sufficient, you need to recheck the masq script to make sure that it contains all the IPsec stuff in there (mentioned in the howto). You can check using /sbin/iptables-save. Maybe expand the masq script again and restart. QoS looks like it marks the packets as well and this seems to cause some problems with IPsec, we're going to have a look at this later in the week. It would be good to be able to use both QoS and IPsec.
Lloyd
-
Hello,
Is it possible to use this contribs between a SME 7.1 and a SME 6.0.1 ?
Thank you
Regards
Denis
-
Denis,
Theoretically, you should be able to connect a sme6 and sme7 via IPSec but not using these instructions. From memory I think sme6 was running a 2.4 kernel which used a different veriosn of IPsec.
Lloyd
-
Hello world,
When I look at the ifcfg-ipsec0 file, there is one line for the destination network (DSTNET).
If I want to install an other server (SERVER C) in the VPN net, how to insert it in ifcfg-ipsec0 file?
May be that isn't possible ? Could you confirm that ? thank
Regards
Denis
-
Caveat: I've never set up an IPSEC vpn on SME...
I think you need to create an entirely new 'ifcfg-ipsec1' file for the "second" ipsec connection to your 3rd site...
-
This is just great!
I think this might be the answer to my needs, explained a bit in http://forums.contribs.org/index.php?topic=33043.msg182097#msg182097
Before I get those new servers delivered (early this coming week), could I just ask a few questions?
1. Is this contrib verified working with a freshly installed Smeserver 7.3?
2. If I set this up om BOTH servers, - would the other traffic (ie internet access) function as usual from the two different locations?
3. Would this contrib in any way interfere with the built-in VPN (users connecting from remote using PPTP)?
-
1. Is this contrib verified working with a freshly installed Smeserver 7.3?
I haven't tried it on a freshly installed box, but I have just yum updated 2 boxes to 7.3 and the tunnel didn't miss a beat.
2. If I set this up om BOTH servers, - would the other traffic (ie internet access) function as usual from the two different locations?
Yes, the internet traffic goes out through it's own gateway at each site. Only the LAN2LAN specific traffic such as RDC uses the IPSEC tunnel.
3. Would this contrib in any way interfere with the built-in VPN (users connecting from remote using PPTP)?
No it doesn't interfere with the VPN for remote users at all. We use both IPSEC and PPTP all the time without any problems.
The only small problem that I've run into using IPSEC is that on the odd occasion the tunnel might go down but is easily fixed by issuing an "ifdown ipsec0" followed by an "ifup ipsec0" and every thing is sweet again. This might occur maybe once a month at the most.
Best Regards,
Lloyd
-
Thank you very much for your quick response!
Your answers were extactly what I was hoping for :D
I've just unpacked the servers, and will perform the installation during the day.
Unfortunately, it's a bit hard to "test" a VPN-tunnel like this in my office, - the servers are to be delivered to two locations with something like 250 km between them :-? :-? :-?
Therefore, it's more than important for me that the PPTP-VPN works...
Again: Thanks a lot, I will of course report back how things proceed!!!
-
Hi again!
Well, things might not be 100 % crystal clear to me...
I've tried your script now on two different servers (both with 7.3).
None of them use PPPoE, so I close the script after the first part.
When trying to execute the command
#/sbin/ifup ipsec0
I get the following error messages:
[root@server2 ~]# /sbin/ifup ipsec0
mktemp: cannot create temp file /etc/racoon/psk.V21438: No such file or directory
/etc/sysconfig/network-scripts/ifup-ipsec: line 227: $tmpfile: ambiguous redirect
/etc/sysconfig/network-scripts/ifup-ipsec: line 228: $tmpfile: ambiguous redirect
mv: missing file argument
Try `mv --help' for more information.
/etc/sysconfig/network-scripts/ifup-ipsec: line 232: /etc/racoon/[IP-of remote-SMESERVER].conf: No such file or directory
/etc/sysconfig/network-scripts/ifup-ipsec: line 239: /etc/racoon/[IP-of remote-SMESERVER].conf: No such file or directory
mktemp: cannot create temp file /etc/racoon/racoon.p21443: No such file or directory
/etc/sysconfig/network-scripts/ifup-ipsec: line 286: $racoontmp: ambiguous redirect
/etc/sysconfig/network-scripts/ifup-ipsec: line 287: $racoontmp: ambiguous redirect
mv: missing file argument
Try `mv --help' for more information.
/etc/sysconfig/network-scripts/ifup-ipsec: line 292: /usr/sbin/racoon: No such file or directory
[root@server2 ~]# ll /etc/racoon
ls: /etc/racoon: No such file or directory
I really feel confused with this racoon stuff, since Smeserver 7.3 doesn't seem to have racoon installed, and I cannot find anywhere in the script where racoon is supposed to be installed.
Did I miss some part somewhere, or am I supposed to install racoon manually before doing this???
By the way, just to survive this, I wrote down the steps needed to "uninstall" the changes made by the script ipsec_install.sh:
REM First delete some files...
rm /etc/sysconfig/network-scripts/ifcfg-ipsec0
rm /etc/sysconfig/network-scripts/ifdown-ipsec
rm /etc/sysconfig/network-scripts/ifup-ipsec
REM ...and restore from backup-files:
mv /etc/sysconfig/network-scripts/ifdown-ipsec.bak /etc/sysconfig/network-scripts/ifdown-ipsec
mv /etc/sysconfig/network-scripts/ifup-ipsec.bak /etc/sysconfig/network-scripts/ifup-ipsec
REM ...time to delete some more files:
rm /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/*
REM ...and remove some directories:
rmdir /etc/e-smith/templates-custom/etc/rc.d/init.d/masq
rmdir /etc/e-smith/templates-custom/etc/rc.d/init.d
rmdir /etc/e-smith/templates-custom/etc/rc.d
rmdir /etc/e-smith/templates-custom/etc
REM Expand template:
/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
REM Restart masq
/etc/init.d/masq restart
Please, I'm close, but quite obviously not close enough :-x :-x :-x
-
Hi again!
A short update:
I decided to manually create the directory /etc/racoon just in order to see what happens, and this is the output:
]# /sbin/ifup ipsec0
RTNETLINK answers: File exists
grep: /etc/racoon/psk.txt: No such file or directory
grep: /etc/racoon/racoon.conf: No such file or directory
/etc/sysconfig/network-scripts/ifup-ipsec: line 292: /usr/sbin/racoon: No such file or directory
If I understand the line /etc/sysconfig/network-scripts/ifup-ipsec: line 292: /usr/sbin/racoon: No such file or directory correctly, this indicates that some racoon executables seems to be missing in a 7.3 system in order to use this solution.
Am I on the right track?
Updated question:
Could someone with a system working with this howto/contrib installed please share the output from the following command:
yum provides racoonThat would be of enormous help to me, thanks!
-
Another update of "progress":
After doing some more research, I tried
yum --enablerepo=base --enablerepo=updates install ipsec-tools
Obviously, ipsec-tools provides racoon.
Am I on the right track now, somebody????
Later:
OK, I'm almost home now:
After installing ipsec-tools, this is what I get:
#/sbin/ifup ipsec0
RTNETLINK answers: Invalid argument
...so a check in the messages log gives me:
# tail /var/log/messages
Jan 27 14:14:45 server2 racoon: INFO: @(#)ipsec-tools 0.3.3 (http://ipsec-tools.sourceforge.net)
Jan 27 14:14:45 server2 racoon: INFO: @(#)This product linked OpenSSL 0.9.7a Feb 19 2003 (http://www.openssl.org/)
Jan 27 14:14:45 server2 racoon: INFO: 192.168.103.1[500] used as isakmp port (fd=8)
Jan 27 14:14:45 server2 racoon: INFO: 81.230.149.198[500] used as isakmp port (fd=9)
Jan 27 14:14:45 server2 racoon: ERROR: failed to bind to address 192.168.103.1[500] (Address already in use).
Jan 27 14:14:45 server2 racoon: INFO: 1.1.1.1[500] used as isakmp port (fd=10)
Jan 27 14:14:45 server2 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=11)
What exactly does the line
ERROR: failed to bind to address 192.168.103.1[500] (Address already in use) mean???
The address 192.168.103.1 is the internal (LAN) interface of this server.
Should I do some configuration elsewhere as well?
Please, someone! I really need this up & running :-o
By the way, Ldkeen, why don't you start a new bug in bugzilla about this?
That would probably help in speeding things up even further?
...Just my recommendation...
-
Help!
(I won't give up on this, so I'll continue this strange monologue until someone out there respond :-?)
What's wrong with this (extract from messages log):
The machine trying to establish connection is using 192.168.103.1 on the LAN-port, and 81.230.149.198 is the WAN-port.
Jan 28 20:03:52 server2 racoon: INFO: 192.168.103.1[500] used as isakmp port (fd=8)
Jan 28 20:03:52 server2 racoon: INFO: 81.230.149.198[500] used as isakmp port (fd=9)
Jan 28 20:03:52 server2 racoon: ERROR: failed to bind to address 192.168.103.1[500] (Address already in use).
Jan 28 20:03:52 server2 racoon: INFO: 1.1.1.1[500] used as isakmp port (fd=10)
Jan 28 20:03:52 server2 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=11)
Why does the machine use 1.1.1.1 and 127.0.0.1 as isakmp ports?
This just has to be wrong, but how do I fix it?
Someone out there obviosly keeps some secrets I need to know, so please, please share your knowledge with me a bit...
-
Eventhough this thread is surprisingly quiet, I earlier promised to report what happens, so here we go:
After a week or so I checked the servers again today.
To my big surprise, the VPN was established! I guess this "delay" has been caused by a very bad ADSL connection at one of the actual sites.
No one is happier than me!
-
Hi Jumba,
Since you were crying out for help in vain at one time and then it seems you have worked through it, I'm hoping you can now help me...
I'm right at this point (quoting your post below):
I've got three identical sme 7.3 boxes setup in the lab and so far - no joy! Can you (or someone) point me in the right direction? I followed the how to EXACTLY and now I'm getting the "racoon" errors.
Hi again!
Well, things might not be 100 % crystal clear to me...
I've tried your script now on two different servers (both with 7.3).
None of them use PPPoE, so I close the script after the first part.
When trying to execute the command
#/sbin/ifup ipsec0
I get the following error messages:
[root@server2 ~]# /sbin/ifup ipsec0
mktemp: cannot create temp file /etc/racoon/psk.V21438: No such file or directory
/etc/sysconfig/network-scripts/ifup-ipsec: line 227: $tmpfile: ambiguous redirect
/etc/sysconfig/network-scripts/ifup-ipsec: line 228: $tmpfile: ambiguous redirect
mv: missing file argument
Try `mv --help' for more information.
/etc/sysconfig/network-scripts/ifup-ipsec: line 232: /etc/racoon/[IP-of remote-SMESERVER].conf: No such file or directory
/etc/sysconfig/network-scripts/ifup-ipsec: line 239: /etc/racoon/[IP-of remote-SMESERVER].conf: No such file or directory
mktemp: cannot create temp file /etc/racoon/racoon.p21443: No such file or directory
/etc/sysconfig/network-scripts/ifup-ipsec: line 286: $racoontmp: ambiguous redirect
/etc/sysconfig/network-scripts/ifup-ipsec: line 287: $racoontmp: ambiguous redirect
mv: missing file argument
Try `mv --help' for more information.
/etc/sysconfig/network-scripts/ifup-ipsec: line 292: /usr/sbin/racoon: No such file or directory
[root@server2 ~]# ll /etc/racoon
ls: /etc/racoon: No such file or directory
I really feel confused with this racoon stuff, since Smeserver 7.3 doesn't seem to have racoon installed, and I cannot find anywhere in the script where racoon is supposed to be installed.
Did I miss some part somewhere, or am I supposed to install racoon manually before doing this???
By the way, just to survive this, I wrote down the steps needed to "uninstall" the changes made by the script ipsec_install.sh:
Please, I'm close, but quite obviously not close enough :-x :-x :-x
-
Please read my "« Reply #21 on: 2008-01-27, 13:40:10 »" above again.
There I describe that ipsec-tools provides racoon, and I also show how to install it.
Good luck!
-
Success!
ipsec-tools 'eh, ......yep, seems that package is an important part of it I would say!
Just out of curiosity, ...why the doggFunk doesn't ipsec-tools come with it in the first place? .....or ever so curious, ...why is there nothing about it in the main how-to? Perhaps this came with 7.1?
-
Just out of curiosity, ...why the doggFunk doesn't ipsec-tools come with it in the first place? .....or ever so curious, ...why is there nothing about it in the main how-to? Perhaps this came with 7.1?
I even tried to make a test install of 7.1 on a Vmware server just to find out, - and the answer is:
7.1 did NOT come with ipsec-tools :shock:
Maybe someone (you, or maybe me if I find the time and inspiration?) should try to re-write the install script and include the installation of ipsec-tools as well?
(I'n still curious why all other people in this thread suddenly became stone dead and quiet.....)
-
I made an even more surprising finding:
Setting up a ipsec tunnel between serverA and serverB, where serverA is hooked up to a goof T1 line and serverB is connected with a not so good ADSL, the following situation showed up:
Making an external VPN (using the built-in VPN in Smeserver) to serverA is of course no problem at all.
Making an external VPN (using the built-in VPN in Smeserver) to serverB is very much of a problem, have to try maybe up to 10 times before it works, and if it works even typing into the terminal is slow like a joke.
BUT: Making an external VPN (using the built-in VPN in Smeserver) to serverA, and afterwards doing a SSH connection from here over to serverB works surprisingly good and fast!
Something is very strange here, and I wouldn't be surprised if the ipsec vpn actually "disturbs" the external VPN connectivity or something...
-
ya, ...i have it connected in my "lab" but I'm not liking the results I'm getting. ---seems buggie. Do you have it rolled out as production machines? I've been using FreeSWAN on sem 6.x boxes for years - solid as a rock.
-
Please explain more about what "seems buggie"...
I'm using this on two production machines right now, and AFAIK it's not too "buggie"
-
I want to implement some VPN's between our office and our client's offices for remote monitoring or servers / devices & client PC support, but I'm not 100% sure if will work, so I have some questions for those who use this setup.
We have SME 7.3 in the office, and our network is 192.168.10.0/24 in the LAN side, and 192.168.1.0/24 on the WAN side (it's really just the SME external interface & ADSL router at this stage). .
From my understanding, I would need to configure each LAN on the VPN on a different subnet, righ? So, clientA would be 192.168.20/24, clientB would be 192.168.21/24, clientC = 192.168.22/24, etc. is this right? Would I then be able to acces for example bob.clienta (if bob is the machine name, and clienta is the network name) or router.clientb (where router is the ADSL router on clientb's network)?
What happens to internet traffic at any of those locations? I have read in a few posts further up that it should go through the local ADSL modem, so clientA should use their own bandwidth, and clientB their own bandwidth, is that so? But what if I have a wireless 10KM link between 2 sites, and I want that network (clientD, 192.168.10.23/24) to use our internet bandwidth as well?
How well will this setup work if a client's network has OpenSuse 10.0 instead of SME?
Would a normal Windows PC with direct internet connectivity (like a laptop @ a Wifi hotspot in another town / state / country) be able to access the SME server, and ultimately the LAN as well?
-
From my understanding, I would need to configure each LAN on the VPN on a different subnet, righ? So, clientA would be 192.168.20/24, clientB would be 192.168.21/24, clientC = 192.168.22/24, etc. is this right? Would I then be able to acces for example bob.clienta (if bob is the machine name, and clienta is the network name) or router.clientb (where router is the ADSL router on clientb's network)?
More correctly: lanA would be 192.168.20.0/24 and lanB would be 192.168.21.0/24. Please don't confuse yourself with "clientA" or "clientB", - you connect lanA with lanB (of course including any client in those lan)
What happens to internet traffic at any of those locations? I have read in a few posts further up that it should go through the local ADSL modem, so clientA should use their own bandwidth, and clientB their own bandwidth, is that so? But what if I have a wireless 10KM link between 2 sites, and I want that network (clientD, 192.168.10.23/24) to use our internet bandwidth as well?
Well, no.
ALL traffic, to the internet as well as to the other office, goes through the ADSL modem of course.
If you set up the SME server/gateway as in the instructions, the routing function will take care of the rest
How well will this setup work if a client's network has OpenSuse 10.0 instead of SME?
No difference. As long as the client (Win, Max, Linux or whatever) belongs to lanA and uses serverA as primary DNS, it just works!
Would a normal Windows PC with direct internet connectivity (like a laptop @ a Wifi hotspot in another town / state / country) be able to access the SME server, and ultimately the LAN as well?
Hopefully not :shock:
If you allow external IP's to act as local clients, you really don't need to worry about any VPN at all...
(It's of course possible to add every IP in the world under "local networks", but please please don't do that...)
If you make a connection with VPN (the built-in VPN in Smeserver) from the roadwarrior laptop to lanA it would be the same as actually being right there in lanA and you'll of course be able to contact resources even in lanB.
Hope this helps!
-
More correctly: lanA would be 192.168.20.0/24 and lanB would be 192.168.21.0/24. Please don't confuse yourself with "clientA" or "clientB", - you connect lanA with lanB (of course including any client in those lan)
That's what I meant. With clientA, I mean a slient / office (whether there's 1 PC or 10). So clientA could have 5 user PC's, clientB 3 & clientC 1 user / PC.
Well, no.
ALL traffic, to the internet as well as to the other office, goes through the ADSL modem of course.
If you set up the SME server/gateway as in the instructions, the routing function will take care of the rest
No difference. As long as the client (Win, Max, Linux or whatever) belongs to lanA and uses serverA as primary DNS, it just works!
Ok, differently put, if I download a 600MB Linux ISO from our LAN, will it use our internet, our route via the VPN, and use a client's bandwidth? I can't have this.
Hopefully not :shock:
If you allow external IP's to act as local clients, you really don't need to worry about any VPN at all...
(It's of course possible to add every IP in the world under "local networks", but please please don't do that...)
If you make a connection with VPN (the built-in VPN in Smeserver) from the roadwarrior laptop to lanA it would be the same as actually being right there in lanA and you'll of course be able to contact resources even in lanB.
Hope this helps!
I hear what you're saying from a security point of view, but how would I allow a field technician or sales rep (whether in town, or on a trip overseas) to connect to the LAN to retrieve documents from the server, or his office PC?
-
I hear what you're saying from a security point of view, but how would I allow a field technician or sales rep (whether in town, or on a trip overseas) to connect to the LAN to retrieve documents from the server, or his office PC?
I told you:
Use VPN (PPTP).
It's in SME by default, and available in Windooze, Mac and Linux as well.
Do you see any problem with that, or why do you ask?
-
sorry, I'm asking from a technical point of view. The mobile PC will travel, and thus won't have a fixed IP. Doe SME need to know about this PC, or not?
-
sorry, I'm asking from a technical point of view. The mobile PC will travel, and thus won't have a fixed IP. Doe SME need to know about this PC, or not?
Not.
You don't even have to carry around any particular PC at all, it works with any PC out there as long as you can set up a VPN on it (even if it's better of course to use a virus free machine :))
Please, start reading the manual, for example http://wiki.contribs.org/SME_Server:Documentation:User_Manual:Chapter1 (http://wiki.contribs.org/SME_Server:Documentation:User_Manual:Chapter1)
You have to note that we're talking about two quite different "VPN" here:
- The IPSEC VPN to connect two networks
- The PPTP VPN to connect a single machine out there in the World Wild Internet with your internal lan
-
Hi!
First of all, thanks for the great HOWTO! My setup is as follows:
192.168.1.0/24 [Home Network] <---> 192.168.1.2 [SME Server Internal IP] <---> x.x.x.23/24 [SME Server External IP] <---> x.x.x.1 [Cable Modem/Router Address] <---> y.y.y.178 [Office Linux Box Running FreeSwan] <---> 172.18.0.0/21 [Office Network]
Now, my problem is that when I try and ping any IP address in my office network [172.18.0.0/21], SME server tries to send it out from the external interface NATed to the IP address of the external interface [x.x.x.23] instead of routing it over the tunnel.
My "ip route show" on my home SME box is:
172.18.0.0/21 via x.x.x.1 dev eth1 src 192.168.1.2
Which seems to correct as per the bug report referred to in the article.
I have followed it exactly and the tunnel is coming - I can see it from the logs of the two servers involved.
No PPPoE - just a bridged Ethernet connection at both ends. Any help would be appreciated!
Regards,
-Varun
-
Hi!
First of all, thanks for the great HOWTO! My setup is as follows:
192.168.1.0/24 [Home Network] <---> 192.168.1.2 [SME Server Internal IP] <---> x.x.x.23/24 [SME Server External IP] <---> x.x.x.1 [Cable Modem/Router Address] <---> y.y.y.178 [Office Linux Box Running FreeSwan] <---> 172.18.0.0/21 [Office Network]
That looks like a very complicated setup!
I that was my stuff, firstly I would get rid of the router so I get:
192.168.1.0/24 [Home Network] <---> 192.168.1.2 [SME Server Internal IP] <---> x.x.x.1 [SME Server External IP] <---> y.y.y.178 [Office Linux Box Running FreeSwan] <---> 172.18.0.0/21 [Office Network]
Secondly, I would like to replace that Office FreeSwan box with a SME Server....
If second step isn't possible, at least please try to set your cable modem in "bridge mode" and remove the routing functions in it...
-
That looks like a very complicated setup!
I that was my stuff, firstly I would get rid of the router so I get:
192.168.1.0/24 [Home Network] <---> 192.168.1.2 [SME Server Internal IP] <---> x.x.x.1 [SME Server External IP] <---> y.y.y.178 [Office Linux Box Running FreeSwan] <---> 172.18.0.0/21 [Office Network]
My setup does look like this only - I agree that showing the Cable Modem was redundant and confusing since it is in bridge mode.
Secondly, I would like to replace that Office FreeSwan box with a SME Server....
Unfortunately, that won't be possible at this time - the office box is a firewall/router doing many unholy things including dynamic routing and fancy NAC. We are considering moving it to (Vyatta) http://www.vyatta.com (http://www.vyatta.com) though, but that's a whole different story.
If second step isn't possible, at least please try to set your cable modem in "bridge mode" and remove the routing functions in it...
My bad - the cable modem is in bridge mode only - I should not have mentioned the word router. So, in effect the network looks exactly like you have mentioned
-
OK, if thatäs the case I simply don't know how to help you :sad:
All my experiences in this field are between two Sme servers, - I don't know what might be wrongly set in that FreeSwan box.
-
OK, if thatäs the case I simply don't know how to help you :sad:
All my experiences in this field are between two Sme servers, - I don't know what might be wrongly set in that FreeSwan box.
Hey Jumba! Thanks for taking an interest in my case and please don't give up on me yet! :-P
The problem is definitely on the SME server side. What happens is that when I ping say, 172.18.0.1, the outgoing packets are generated with the a source IP of my external interface (x.x.x.23). Good ol' tcpdump shows something like:
16:58:30.161681 IP 192.168.1.77 > 172.18.0.1: icmp 64: echo request seq 3
16:58:30.161681 IP x.x.x.23 > 172.18.0.1: icmp 64: echo request seq 3
Which means that SME server receives the packets from my laptop (192.168.1.77) and decides to masquerade (NAT) them to x.x.x.23 and send them out of the external interface rather than route them over the IPSec tunnel.
My problem is that I have exactly zero experience with racoon and don't even know where to start looking. Will turn on more debugging in racoon and see if I get anything. Does anyone know the equivalent of FreeSwan's "ipsec show eroute" in racoon?
Regards,
-Varun
-
OK, I just can't stay away, obviously :-P
Well, to start with, are you SURE that the ipsec tunnel is established correctly?
What does the command
less /var/log/messages | grep racoon
in the SME box give you???
-
OK, I just can't stay away, obviously :-P
Thaks! Much appreciated!
Well, to start with, are you SURE that the ipsec tunnel is established correctly?
What does the command
less /var/log/messages | grep racoon
in the SME box give you???
On the SME server side:
Feb 26 17:12:26 homestack racoon: INFO: IPsec-SA established: AH/Tunnel x.x.x.23->y.y.y.y.178 spi=1486974989(0x58a1700d)
Feb 26 17:12:26 homestack racoon: INFO: IPsec-SA established: ESP/Tunnel x.x.x.23->y.y.y.178 spi=1486974990(0x58a1700e)
On the FreeSwan side:
Feb 26 17:12:24 shiva pluto[1189]: "eod-noida-sify" #516: responding to Main Mode
Feb 26 17:12:24 shiva pluto[1189]: "eod-noida-sify" #516: Peer ID is ID_IPV4_ADDR: 'x.x.x.23'
Feb 26 17:12:24 shiva pluto[1189]: "eod-noida-sify" #516: sent MR3, ISAKMP SA established
Feb 26 17:12:24 shiva pluto[1189]: "eod-noida-sify" #516: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Feb 26 17:12:24 shiva pluto[1189]: "eod-noida-sify" #516: received and ignored informational message
Feb 26 17:12:25 shiva pluto[1189]: "eod-noida-sify" #518: responding to Quick Mode
Feb 26 17:12:25 shiva pluto[1189]: "eod-noida-sify" #518: IPsec SA established
-
Hi Varun,
You say that your cable modem is running in a bridge mode but "ip route show" at home displays the following
172.18.0.0/21 via x.x.x.1 dev eth1 src 192.168.1.2
Does the Linux box (running FreeSwan) have a public IP? If so I would have thought that "ip route show" (from home) should show the following:
172.18.0.0/21 via y.y.y.178 dev eth1 src 192.168.1.2Something must be wrong in the routing or setup. I would set it up again, but leave all references to the cable modem out the configuration.
Can you ping home from work?
Lloyd
-
....are there any new packages that make an IPSec VPN "easier" on 7.3?
- NSH