From: Sam Sgro (sam_at_freeswan.org)
Date: Tue Jan 14 2003 - 06:47:43 CET
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 13 Jan 2003 bdushok_at_luzerne.edu wrote:
> I've been reading docs and attempting to configure Freeswan for a VPN
> between two of our locations for a couple of days. I think I'm REALLY
> close, but I can't communicate between my two VPNed networks.
>
> It appears my VPNs are starting as I'm seeing the following in my logs:
> Jan 11 15:11:20 bgw ipsec_setup: ...FreeS/WAN IPsec started
> Jan 11 15:11:22 bgw ipsec__plutorun: 104 "bw-lccc" #1: STATE_MAIN_I1:
> initiate
> Jan 11 15:11:22 bgw ipsec__plutorun: 106 "bw-lccc" #1: STATE_MAIN_I2: sent
> MI2, expecting MR2
> Jan 11 15:11:22 bgw ipsec__plutorun: 108 "bw-lccc" #1: STATE_MAIN_I3: sent
> MI3, expecting MR3
> Jan 11 15:11:22 bgw ipsec__plutorun: 004 "bw-lccc" #1: STATE_MAIN_I4:
> ISAKMP SA established
> Jan 11 15:11:22 bgw ipsec__plutorun: 112 "bw-lccc" #2: STATE_QUICK_I1:
> initiate
> Jan 11 15:11:22 bgw ipsec__plutorun: 004 "bw-lccc" #2: STATE_QUICK_I2:
> sent QI2, IPsec SA established
> Do the IPsec SA and ISAKMP SA messages indicate that my VPN is running?
> These messages appear in the logs for both systems.
You've successfully negotated both the SAs required for an encrypted tunnel.
> My VPN should connect net 10.1.0.0/24 and 10.12.0.0/24. Each of the two
> Freeswan systems are running Red Hat 8.0 and have multiple nics (only two
> being used for the VPN). My ipsec.conf files are identical on both
> systems and appear as follows:
*snip*
> To test the connection I'm attempting to telnet from 10.12.0.2 to 10.1.2.1
> without any success.
That ping test might not work for two reasons:
1) 10.1.2.1 is not within the subnet "10.1.0.0/24".
2) If 10.1.2.1 was a typo, and you really meant 10.1.0.1, I'll bet that refers
to the security gateway itself. You've negotatied a "net-to-net" tunnel; that
doesn't cover the gateways themselves. Though the IPs you mention may be the
private IPs of the gateways, they'll respond using their public IPs, and the
packets will be discarded. Read this:
http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/interop.html#multitunnel
In short, test the tunnel using machines solely lying on either authorized
'net, or create additional tunnels.
3) NAT can do strange things to IPSec packets; packets travelling between
non-routeable subnets should be exempted from NAT. Have you read this FAQ?
http://lists.freeswan.org/pipermail/users/2002-August/012918.html
> #!/bin/sh
> IPT=/sbin/iptables
> IP=(eth0/public IP used here)
> LAN=10.12.0.0/16 (local net placed here)
> $IPT -F FORWARD
> $IPT -F INPUT
> $IPT -F OUTPUT
> $IPT -P FORWARD DROP
> $IPT -P INPUT DROP
> $IPT -P OUTPUT DROP
> $IPT -A INPUT -i lp -j ACCEPT
> $IPT -A INPUT -p udp -d $IP --dport 500 -j ACCEPT
> $IPT -A INPUT -p 50 -d $IP -j ACCEPT
> $IPT -A INPUT -p 51 -d $IP -j ACCEPT
> $IPT -A OUTPUT -o lo -j ACCEPT
> $IPT -A OUTPUT -p udp -s $IP --dport 500 -j ACCEPT
> $IPT -A OUTPUT -p 50 -s $IP -j ACCEPT
> $IPT -A OUTPUT -p 51 -s $IP -j ACCEPT
> $IPT -A FORWARD -s $LAN -d $LAN -j ACCEPT
I must admit, I don't see much wrong with this setup. You can simply exclude
a firewall problem by diff'ing the output of "iptables -L -n -v" during an
attempt to communicate. It will flag the rules applied to each packet, and can
let you know if any are being dropped.
- --
Sam Sgro
sam_at_freeswan.org
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBPiOkgUOSC4btEQUtAQH9CwP/cAzznVmp2zPkVjBHOJEAts4X5tYcnjuA
WMDcB1YWxOievH0Tyz/uNOg7pGVeQcufngmoD1z5+pfLmHoF8i4bp4d5XMa7qbLI
4W7pLNE7owWpcUXkgD4x5ZApuuMHMSzfJyMVyK9jT7UZBdiKdzCSoQ2TDjZgQjTR
pluUL/uNhEQ=
=VrYb
-----END PGP SIGNATURE-----
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Wed Jan 15 2003 - 20:11:39 CET