Hi there. Installed openswan, and followed the instructions :) . It
looks like tunnel is estabilished now:
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: initiating Main Mode
May 24 14:19:33 fbctestvpn pluto[7063]: | no IKE algorithms for this
connection ---> is this bad....
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: transition from
state STATE_MAIN_I1 to state STATE_MAIN_I2
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: received Vendor ID
payload [XAUTH]
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: received Vendor ID
payload [Dead Peer Detection]
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: received Vendor ID
payload [Cisco-Unity]
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: ignoring unknown
Vendor ID payload [xxxxxxxxxxxxxxxxxxxxxxx]
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: I did not send a
certificate because I do not have one.
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: transition from
state STATE_MAIN_I2 to state STATE_MAIN_I3
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: Main mode peer ID is
ID_IPV4_ADDR: 'xxx.xxx.xxx.130' --> this being the external ip of the
cisco pix 525
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: transition from
state STATE_MAIN_I3 to state STATE_MAIN_I4
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: ISAKMP SA
established
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #2: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1}
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: ignoring
informational payload, type IPSEC_INITIAL_CONTACT
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #1: received and ignored
informational message
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #2: ignoring
informational payload, type IPSEC_RESPONDER_LIFETIME
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #2: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2
May 24 14:19:33 fbctestvpn pluto[7063]: "milan" #2: sent QI2, IPsec SA
established {ESP=>0x6xxx23f <0x07xxxx7}
000 "milan":
192.168.10.0/24===xxx.xxx.xxx.90---xxx.xxx.xxx.65...xxx.xxx.xxx.129---xxx.xxx.xxx.130===192.168.100.0/24; unrouted; eroute owner: #0
192.168.10.3 internal linux box ip (and default gateway for the natted
workstations)
192.168.100.2 internal cisco pix ip (and default gateway for the natted
workstations)
conn milan
left=xxx.xxx.xxx.90 public ip linux box
leftnexthop=xxx.xxx.xxx.65 default gateway linux
leftsubnet=192.168.10.0/24
right=xxx.xxx.xxx.130 public ip cisco
rightsubnet=192.168.100.0/24 network behind cisco
rightnexthop=xxx.xxx.xxx.129 default gateway cisco
authby=secret
pfs=no
auto=add
esp=3des-md5-96
The firewall on the linuxbox is natting the 192.168.10.x network and
accepting anything coming from 192.168.100.x, I added udp port 500 to
INPUT and OUTPUT chains in iptables, but still cannot ping (even from
other workstations) or reach a web page on the other network. Anything
else I am missing or should be looking for?
>Remember you will need to allow the ipsec interface in your firewall
How do I do this?
Thanks for all your help, really appreciate this.
Simone
On Tue, 2005-05-24 at 01:35, Peter Farrow wrote:
> Hi there, yes it was with a Nortel contivity on a few occassions and
> the other times with a Cisco pix. interstingly enough the Cisco VPNs
> often required updates to the IOS to make them 3Des compliant,
>
> As its late here in the UK (past midnight GMT+1) here is a very quick
> and dirty freeswan guide.
>
> Needless to say the things that cause the biggest headache for most
> users is the use of RSA keys and opportunistic encryption. Since this
> is NOT what 99.9% of the masses need or want then there is a quick and
> simple and just as secure alternative setup, but its not that well
> documented. Opportunistic encryption came in versions 2 and above of
> freeswan by default, this has the effect of clobbering the network
> default route and replacing it down the ipsec interface (what you want
> if you want to encrypt everything, but not really any great use in the
> real world). Most people want to do site <-> site vpns and these are
> best achieved without opportunistic encryption and by the use of
> preshared keys.
>
> 1)Make sure you get a version of freeswan suitable for your kernel, if
> you can't find one go to somewhere like rpms.pbone.net and find a
> kernel for which there is a freeswan version. Many people try and
> hunt a freeswan version to match their kernel, I do it the otherway
> round, find the latest freeswan compatible kernel you can for your
> architecture, you can always compile it from source but why my life
> harder for yourself.
> 2)get the freeswan module for the kernel you found, and the same
> freeswan-userland version as well. then proceed as follows: after you
> have installed the [from rpm]
>
>
> Typically to kill opportunistic encryption add these lines to your
> ipsec.conf file: after the config setup section near the top,
>
> conn block
> auto=ignore
>
> conn private
> auto=ignore
>
> conn private-or-clear
> auto=ignore
>
> conn clear-or-private
> auto=ignore
>
> conn clear
> auto=ignore
>
> conn packetdefault
> auto=ignore
>
> Doing this stops all the crap you get when ipsec starts and then kicks
> you off the system about 60 seconds later if you're connected remotely
> as this kills the opportunistic setup feature. Do the same at the
> other end as well.
> Then start the service.
>
> Then add a section for each tunnel you want to set up. if you have
> multiple subnets at each site which can't be encapsulated in a single
> subnet declaration, you will need to add a new tunnel defintion for
> each. Here is an example :
>
> conn site1-site2 #this is the connection name
> [tunnel] identifier
> left=21.21.100.10 #This is the ip address of the
> first linux box
> leftnexthop=21.21.100.9 #This is usually set to the
> defualt gateway for the first linux box
> leftsubnet=10.11.2.0/24 #This is the LAN subnet behind
> the first linux box
> right=21.21.100.178 #This is the IP address of the
> second linux box at the other end of the tunnel
> rightsubnet=10.11.4.0/24 #This is the LAN subnet behind
> the second linux box
> rightnexthop=21.21.100.177 #This is the IP address of the
> default gateway setting of the other linux box
> authby=secret #We are going to use a
> "password" or secret to encrypt/auth the link
> pfs=no #Turn off perfect forward
> security, this makes it faster and easier but less secure
> auto=add #Authorise but don't start
> esp=3des-md5-96 #encapsulating security payload
> setting, encryption used for auth and data
>
>
> Now cut and paste this and add it to the ipsec.conf file on the second
> machine completely as is, unmodified.
>
> Then in you /etc/ipsec.secrets file on each machine you will need to
> add a password [secret] for each each of the tunnels you have
> specified, in the above example we would have:
>
> 21.21.100.10 21.21.100.178 : PSK "a-passwordin-here-with-the-quotes"
>
> Add this to the very top of the ipsec secrets file, one entry for each
> pair of machines in this format
>
> leftmachineip rightmachineip : PSK "password"
>
> Then do a service ipsec restart on each machine, bring the link up
> with this command, it only needs to be invoked from either one of the
> ends
>
> ipsec auto --up site1-site2
>
> You should get output like this if you did it right:
> ipsec auto --up site1-site2
> 104 "site1-site2" #2086: STATE_MAIN_I1: initiate
> 106 "site1-site2" #2086: STATE_MAIN_I2: sent MI2, expecting MR2
> 108 "site1-site2" #2086: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "site1-site2" #2086: STATE_MAIN_I4: ISAKMP SA established
> 112 "site1-site2" #2087: STATE_QUICK_I1: initiate
> 004 "site1-site2" #2087: STATE_QUICK_I2: sent QI2, IPsec SA
> established
>
> Remember you will need to allow the ipsec interface in your firewall
> and you will need to add lines like this:
>
> # Accept udp connections to port 500 for ipsec
> $IPTABLES -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
> $IPTABLES -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
>
> This is just about the quickest way to set up a VPN tunnel with
> Freeswan, it takes minutes. If you want to make if more secure, you
> can tune the config once you get it running this way!
>
> Remember the only machines that can't see the full extent of the other
> LAN network are the linux boxes creating the tunnel. So the left
> linux box will not be able to ping stuff on 10.11.4.0/24 network and
> the right linux box will not be able to ping stuff on 10.11.2.0/24
> network - don't forget this.... its commonly mistaken by some to mean
> the tunnel isn't working, to truly test it end to end you need hosts
> on the LANs at each end to ping each other.
>
> If you want to make it work through NATing gateways you will need to
> port forward the udp 500 setting above on your firewall.
>
> Enjoy!
>
> Pete
>
>
>
>
>
>
>
>
>
>
>
>
> Kennedy Clark wrote:
> > Any chance of getting a quick HOW-TO posted to the group for that?
> > ;-) Sounds interesting.
> >
> > I saw your post about using it with Cisco & Nortel equipment -- I work
> > with both a lot at my current customer. What types of equipment have
> > you used it with from both vendors (e.g., Cisco: IOS, PIX, VPN3K;
> > Nortel = Contivity)?
> >
> > Thanks!!
> > Kennedy
> >
>
>
> ______________________________________________________________________
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Bisogno di liquidità? Non devi spiegare per cosa. Fino a 4.000 € a casa tua
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2291&d=24-5