Hi there,
the "RESTRICT..." is one of my own iptables rules, which is called from
the INPUT and FORWARD chains which provides a nice convenient point to
add it all in in one go.
You should see routes like this if your tunnels are up
192.168.12.0 ch-rtr.farrows. 255.255.255.0 UG 0 0 0
ipsec0
issue the route command and see what you get
Don't worry about having long conversations about this: its tricky if
you have not done it before and I will help as long as it takes
Pete
Simone wrote:
> Here again, I don't think I understand what
> "RESTRICT_EXTERNAL_CONNECTIONS" means. I think I enabled the firewall
> to accept anything that comes from the external pix IP, the pix
> gateway IP and the cisco internal lan, so to be sure it is not dropped
> (not really a iptables guru so I could be wrong). Some strange
> behaviour include tha fact I can ping from linux to cisco on the
> public IP but not vice versa, while from another site I can ping the
> public linux box ip (so it looks like it is not dropped by the
> firewall config).
> I am sorry if this is going far too long. Something that's not clear
> to me is if a device called ipsec0 or whatever I call the connection,
> should show up somewhere and if a route should be provided to reach
> the cisco internal network from the linux internal network. Anything
> could help to figure this out? Firewall rules?
>
> Thanks, have a nice day
>
> Peter Farrow wrote:
>
>> If your seeing the communication like this its not being dumped or
>> dropped by your firewall, you could add an accept rule for all
>> protocols from the far end Ips at each site, just for debugging
>> purposes and to rule out the firewall itself..
>>
>> This is almost there now, make sure that you have lines like this in
>> your firewall:
>>
>> $IPTABLES -A RESTRICT_EXTERNAL_CONNECTIONS -m state --state
>> ESTABLISHED,RELATED -j ACCEPT
>> $IPTABLES -A RESTRICT_EXTERNAL_CONNECTIONS -m state --state NEW
>> --in-interface ! $EXT_IFACE -j ACCEPT
>>
>> $IPTABLES -A INPUT -j RESTRICT_EXTERNAL_CONNECTIONS
>> $IPTABLES -A FORWARD -j RESTRICT_EXTERNAL_CONNECTIONS
>>
>> Notice I accept all new interfaces on anything that's not the
>> external network card, this automatically includes lo, internet
>> ethernet and all ipsec interfaces you will of course need to change
>> these to suit your firewall config....
>>
>> Becareful (dont use it unmodified) using a rule like this if you have
>> more than one external [untrusted] interface....
>>
>>
>> P.
>>
>>
>> simone wrote:
>>
>>> 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
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS at centos.org
>>> http://lists.centos.org/mailman/listinfo/centos
>>>
>>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS at centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos