Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: ldkeen on March 28, 2006, 01:55:08 PM
-
I'm trying to setup an IPsec tunnel between two smeservers, both running 7.0rc1 with static IP's on the external interface. The tunnel seems to come up fine and I'm fairly sure everything is setup as it should be however the packets seem to be disappearing into thin air. I suspect it's a firewall issue but it's a bit over my head. Anyone have any ideas??? Here's where I'm at:
Install ipsec-tools on both machines.
Edit /etc/sysconfig/network-scripts/ifcfg-ipsec0 (smeserverA) and enter the following:
TYPE=IPSEC
ONBOOT=YES
IKE_METHOD=PSK
SRCGW=192.168.10.1
DSTGW=192.168.70.1
SRCNET=192.168.10.0/24
DSTNET=192.168.70.0/24
DST=203.219.48.26
And add the preshared key into /etc/sysconfig/network-scripts/keys-ipsec0
Then on smeserverB into /etc/sysconfig/network-scripts/ifcfg-ipsec1
TYPE=IPSEC
ONBOOT=YES
IKE_METHOD=PSK
SRCGW=192.168.70.1
DSTGW=192.168.10.1
SRCNET=192.168.70.0/24
DSTNET=192.168.10.0/24
DST=218.214.56.123
And add the preshared key into /etc/sysconfig/network-scripts/keys-ipsec1
Last but not least open port UDP 500 using port-opening contrib at both ends (required for phase 1 negotiation).
Bring up the interface both ends and the tunnel appears to come up without any problems:
ifup ipsec0 (smeserverA)
ifup ipsec1 (smeserverB)
Mar 28 10:21:02 guru racoon: INFO: respond new phase 1 negotiation: 218.214.56.123[500]<=>203.219.48.26[500]
Mar 28 10:21:02 guru racoon: INFO: begin Aggressive mode.
Mar 28 10:21:02 guru racoon: NOTIFY: couldn't find the proper pskey, try to get one by the peer's address.
Mar 28 10:21:02 guru racoon: INFO: ISAKMP-SA established 218.214.56.123[500]-203.219.48.26[500] spi:4bc6c596e2b74550:a15d4f9bc2fd7ef8
Mar 28 10:21:02 guru racoon: INFO: respond new phase 2 negotiation: 218.214.56.123[0]<=>203.219.48.26[0]
Mar 28 10:21:02 guru racoon: INFO: IPsec-SA established: AH/Tunnel 203.219.48.26->218.214.56.123 spi=214744820(0xcccbef4)
Mar 28 10:21:02 guru racoon: INFO: IPsec-SA established: ESP/Tunnel 203.219.48.26->218.214.56.123 spi=224127991(0xd5bebf7)
Mar 28 10:21:02 guru racoon: INFO: IPsec-SA established: AH/Tunnel 218.214.56.123->203.219.48.26 spi=125222310(0x776bda6)
Mar 28 10:21:02 guru racoon: INFO: IPsec-SA established: ESP/Tunnel 218.214.56.123->203.219.48.26 spi=73703572(0x464a094)
Checking the SAD and SPD entries gives the following:
#/sbin/setkey -D
203.219.48.26 218.214.56.123
esp mode=tunnel spi=93978020(0x0599fda4) reqid=0(0x00000000)
E: 3des-cbc 657c3a63 fab5a617 8c5f2d55 60ddd28a 320289e3 eeacbb05
A: hmac-sha1 58932557 451929bb 88756644 f2afda4a fc65bf08
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Mar 28 21:49:00 2006 current: Mar 28 22:05:39 2006
diff: 999(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=3 pid=409 refcnt=0
203.219.48.26 218.214.56.123
ah mode=tunnel spi=267330573(0x0fef240d) reqid=0(0x00000000)
A: hmac-sha1 75f108cf 2b8f9767 af626fa7 c097717d 13e9a719
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Mar 28 21:49:00 2006 current: Mar 28 22:05:39 2006
diff: 999(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=2 pid=409 refcnt=0
218.214.56.123 203.219.48.26
esp mode=tunnel spi=136560287(0x0823be9f) reqid=0(0x00000000)
E: 3des-cbc 01d088a9 213c367d 479408ea 0f75a820 be01f367 08bf1733
A: hmac-sha1 bf6f442d fdc5c4c7 d6ca8e82 b5e0de00 a4b12d7e
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Mar 28 21:49:00 2006 current: Mar 28 22:05:39 2006
diff: 999(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=409 refcnt=0
218.214.56.123 203.219.48.26
ah mode=tunnel spi=133572129(0x07f62621) reqid=0(0x00000000)
A: hmac-sha1 c44cc4ab 3325e339 7c944af4 59142fac 43f9f1b2
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Mar 28 21:49:00 2006 current: Mar 28 22:05:39 2006
diff: 999(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=0 pid=409 refcnt=0
#/sbin/setkey -DP
192.168.70.0/24[any] 192.168.10.0/24[any] any
in ipsec
esp/tunnel/203.219.48.26-218.214.56.123/require
ah/tunnel/203.219.48.26-218.214.56.123/require
created: Mar 28 11:29:53 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=352 seq=11 pid=412
refcnt=1
192.168.10.0/24[any] 192.168.70.0/24[any] any
out ipsec
esp/tunnel/218.214.56.123-203.219.48.26/require
ah/tunnel/218.214.56.123-203.219.48.26/require
created: Mar 28 11:29:53 2006 lastused: Mar 28 21:24:32 2006
lifetime: 0(s) validtime: 0(s)
spid=345 seq=9 pid=412
refcnt=1
192.168.70.0/24[any] 192.168.10.0/24[any] any
fwd ipsec
esp/tunnel/203.219.48.26-218.214.56.123/require
ah/tunnel/203.219.48.26-218.214.56.123/require
created: Mar 28 11:29:53 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=362 seq=7 pid=412
refcnt=1
At this stage everything looks ok - seems to be running in tunnel mode :-D. But when I ping from either the gateway or any client from smeserverA it times out. Looking at tcpdump -i eth1 on smeserverB I can see that the encrypted packets are actually getting there.
12:55:08.572718 IP adsl-56-123.swiftdsl.com.au > server.clbengineering.com: AH(spi=0x06c54d80,seq=0x11): IP adsl-56-123.swiftdsl.com.au > server.clbengineering.com: ESP(spi=0x045ceaf0,seq=0x11) (ipip-proto-4)
And checking /var/log/iptables/current confirms the packets are being dropped. This is the stage where it gets a bit over our head. Tried adding the following (one by one) into /etc/init.d/masq near the top (at both ends).
/sbin/iptables -A INPUT -i eth1 -p 50 -j ACCEPT
/sbin/iptables -A OUTPUT -i eth1 -p 50 -j ACCEPT
/sbin/iptables -A INPUT -i eth1 -p 51 -j ACCEPT
/sbin/iptables -A OUTPUT -i eth1 -p 51 -j ACCEPT
followed by:
/service masq restart
Checking /iptables-save confirms that the rules were loaded but the packets are still disappearing into oblivion :cry:. Tried to add the following:
/sbin/iptables -t mangle -A PREROUTING -p 50 -j MARK --set-mark 1
/sbin/iptables -A INPUT -m mark --mark 1 -j ACCEPT
/sbin/iptables -A FORWARD -m mark --mark 1 -j ACCEPT
Still cannot get a response between the networks. Is there anyone who has some more experience with firewalls able to help out. BTW We were able to setup a tunnel between a CentOS4.3 host and the smeserver (both on the internal lan) and were able to send encrypted traffic between the two hosts which leads us to believe this is a firewall issue. Any help would be greatly appreciated.
Regards Lloyd
-
Looks like we managed to sort out the firewall issue:
#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/
#touch 15AllowIPsec
#mcedit 15AllowIPsec
and add the following:
/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 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
But for some reason the routing table entry was stuffed up. Have to have a look at this later, but a quick hack to fix it is:
ip route delete remote_lan/24 dev $INTERNALIF src your_local_gw
ip route add remote_lan/24 dev $OUTERIF src your_local_gw
(Replace $INTERNALIF with your Internal Interface and $OUTERIF with your External interface)
Example:
ip route delete 192.168.70.0/24 dev eth0 src 192.168.10.1
ip route add 192.168.70.0/24 dev ppp0 src 192.168.10.1
And now the tunnel is working. However checking tcpdump seems to indicate that the traffic is only encrypted from the remote lan to the external interface on the local server - it is then sent unencrypted to the local workstation. Will need to do a bit more reading. After we have sorted out the routing issue we'll post a full howto.
Lloyd