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
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@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
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@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 EUR a casa tua Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2291&d=24-5 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Once again thanks. I issued the route command and I see this:
192.168.100.0 ip-pub.fastwebn 255.255.255.0 UG 0 0 0 eth0
This is either when I have interface=%defaultroute or interface="ipsec0=eth0" in my ipsec.conf. I am stuck, checked /var/log/messages and secure with no results, don't really know what to try next. Maybe step back and review the NAT iptables rules to just pass anything incoming and outgoing traffic so to be sure packets don't get dropped there. Comments, troubleshooting suggestions always welcome.
Have a nice day
On Tue, 2005-05-24 at 17:07, Peter Farrow wrote:
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Manuali.net ti REGALA decine di corsi, da Dreamweaver a Photoshop, da WindowsXP ad Office. * Non devi far altro che cliccare e... scaricare! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3415&d=24-5
Hi all, first of all I want to apologize for the very long email. This is driving me crazy and in 4 days our current VPN will be dead.
Started over, reconfigured cisco pix following cisco vpn guide and http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html (differences in no-xauth no-config-mode, lifetime 28800 and esp-md5-hmac). Modified rule in firewall, added $IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.10.0/24 -d! 192.168.100.0/24 -j MASQUERADE not to nat packets going to 192.168.100.0 (am I right?), started ipsec and connection on the linux box, public ip 162.x.x.90 private network 192.168.10.x this is the result of setkey -DP
192.168.100.0/24[any] 192.168.10.0/24[any] any in ipsec esp/tunnel/182.xxx.xxx.130-162.xxx.xxx.90/unique#16385 created: May 25 14:19:10 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=992 seq=8 pid=14415 refcnt=1 192.168.10.0/24[any] 192.168.100.0/24[any] any out ipsec esp/tunnel/162.xxx.xxx.90-182.xxx.xxx.130/unique#16385 created: May 25 14:19:10 2005 lastused: May 25 15:42:21 2005 lifetime: 0(s) validtime: 0(s) spid=1009 seq=7 pid=14415 refcnt=2 192.168.100.0/24[any] 192.168.10.0/24[any] any -----> 192.168.100.0/24 is the cisco private network, is this correct? fwd ipsec esp/tunnel/182.xxx.xxx.130-162.xxx.xxx.90/unique#16385 created: May 25 14:19:10 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=1002 seq=6 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=979 seq=5 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: May 25 15:18:31 2005 lifetime: 0(s) validtime: 0(s) spid=963 seq=4 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=947 seq=3 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=988 seq=2 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: May 25 15:18:33 2005 lifetime: 0(s) validtime: 0(s) spid=972 seq=1 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=956 seq=0 pid=14415 refcnt=1
if I issue the route command I get
192.168.100.0 * 255.255.255.0 U 0 0 0 eth0 192.168.100.0 ip-pub. 255.255.255.0 UG 0 0 0 eth0 192.168.10.0 * 255.255.255.0 U 0 0 0 eth1
where eth1 is 192.168.10.3 and eth0 is ip-pub. = 162.xxx.xxx.90.
ipsec auto status:
"milan" esp.f02a7d60@182.xxx.xxx.130 esp.f8d6586b@162.xxx.xxx.90 tun.0@182.xxx.xxx.130 tun.0@162.xxx.xxx.90
It looks to me that the vpn is estabilished, but still cannot ping from one end to the other....
ping 192.168.100.26 -l 192.168.10.3 or even ping from another linuxbox that's actually natted behind this machine (and can see the web).
Any suggestion on where to look for troubleshooting will be very appreciated, have a nice day.
Simone
On Tue, 2005-05-24 at 17:07, Peter Farrow wrote:
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Vuoi ricevere gratuitamente, ogni giorno, un trucco per imparare a smanettare con il tuo PC? * Iscriviti ad Untruccoalgiorno, è GRATIS, è per tutti! Clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3413&d=25-5
Are you sure your iptables isn't dropping the packets? VPN and other tunneled packets go through the firewall _twice_! First before unpacking they come from the physical ethernet interface and head for INPUT chain (they're going INTO the kernel). Next the kernel unpacks them. And the unpacked packet goes through the firewall again - this time incoming from the VPN virtual interface (and likely going for the FORWARD chain) - are you sure they're not being dropped here?
and in reverse incoming packets for the VPN first go through FORWARD heading for the virtual VPN interface then get packaged ang go through the OUTPUT chain (source being the kernel) heading for the physical ethernet interface...
Cheers, MaZe.
On Wed, 25 May 2005, simone wrote:
Hi all, first of all I want to apologize for the very long email. This is driving me crazy and in 4 days our current VPN will be dead.
Started over, reconfigured cisco pix following cisco vpn guide and http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html (differences in no-xauth no-config-mode, lifetime 28800 and esp-md5-hmac). Modified rule in firewall, added $IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.10.0/24 -d! 192.168.100.0/24 -j MASQUERADE not to nat packets going to 192.168.100.0 (am I right?), started ipsec and connection on the linux box, public ip 162.x.x.90 private network 192.168.10.x this is the result of setkey -DP
192.168.100.0/24[any] 192.168.10.0/24[any] any in ipsec esp/tunnel/182.xxx.xxx.130-162.xxx.xxx.90/unique#16385 created: May 25 14:19:10 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=992 seq=8 pid=14415 refcnt=1 192.168.10.0/24[any] 192.168.100.0/24[any] any out ipsec esp/tunnel/162.xxx.xxx.90-182.xxx.xxx.130/unique#16385 created: May 25 14:19:10 2005 lastused: May 25 15:42:21 2005 lifetime: 0(s) validtime: 0(s) spid=1009 seq=7 pid=14415 refcnt=2 192.168.100.0/24[any] 192.168.10.0/24[any] any -----> 192.168.100.0/24 is the cisco private network, is this correct? fwd ipsec esp/tunnel/182.xxx.xxx.130-162.xxx.xxx.90/unique#16385 created: May 25 14:19:10 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=1002 seq=6 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=979 seq=5 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: May 25 15:18:31 2005 lifetime: 0(s) validtime: 0(s) spid=963 seq=4 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=947 seq=3 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=988 seq=2 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: May 25 15:18:33 2005 lifetime: 0(s) validtime: 0(s) spid=972 seq=1 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=956 seq=0 pid=14415 refcnt=1
if I issue the route command I get
192.168.100.0 * 255.255.255.0 U 0 0 0 eth0 192.168.100.0 ip-pub. 255.255.255.0 UG 0 0 0 eth0 192.168.10.0 * 255.255.255.0 U 0 0 0 eth1
where eth1 is 192.168.10.3 and eth0 is ip-pub. = 162.xxx.xxx.90.
ipsec auto status:
"milan" esp.f02a7d60@182.xxx.xxx.130 esp.f8d6586b@162.xxx.xxx.90 tun.0@182.xxx.xxx.130 tun.0@162.xxx.xxx.90
It looks to me that the vpn is estabilished, but still cannot ping from one end to the other....
ping 192.168.100.26 -l 192.168.10.3 or even ping from another linuxbox that's actually natted behind this machine (and can see the web).
Any suggestion on where to look for troubleshooting will be very appreciated, have a nice day.
Simone
On Tue, 2005-05-24 at 17:07, Peter Farrow wrote:
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Vuoi ricevere gratuitamente, ogni giorno, un trucco per imparare a smanettare con il tuo PC?
- Iscriviti ad Untruccoalgiorno, � GRATIS, � per tutti! Clicca qui
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3413&d=25-5 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks to everyone, this is absolutely great, it finally works.
Added this rules to the firewall config (hope this is not exposing the internal network to attacks....) and now packets are not dropped.
#packets hitting eth0 coming from remote network directed to #internal network accepted $IPTABLES -A INPUT -i $EXTIF -s ${remotenetwork} -d $INTNET -j ACCEPT # $IPTABLES -A INPUT -p 51 -j ACCEPT $IPTABLES -A INPUT -p 50 -j ACCEPT $IPTABLES -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
#anything directed to remote network accepted #perhaps there's a safer way of writing this rule $IPTABLES -A OUTPUT -d ${remotenetwork} -j ACCEPT # $IPTABLES -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT $IPTABLES -A OUTPUT -p 51 -j ACCEPT $IPTABLES -A OUTPUT -p 50 -j ACCEPT
#enable forward from and to remote network $IPTABLES -A FORWARD -s $INTNET -d ${remotenetwork} -j ACCEPT $IPTABLES -A FORWARD -s ${remotenetwork} -d $INTNET -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -d! 192.168.100.0/24 -j SNAT --to $EXTIP
Think this is going to harm the firewall?
Thanks again, this list is amazing!
Have a nice day Simone
On Wed, 2005-05-25 at 16:04, Maciej Żenczykowski wrote:
Are you sure your iptables isn't dropping the packets? VPN and other tunneled packets go through the firewall _twice_! First before unpacking they come from the physical ethernet interface and head for INPUT chain (they're going INTO the kernel). Next the kernel unpacks them. And the unpacked packet goes through the firewall again - this time incoming from the VPN virtual interface (and likely going for the FORWARD chain) - are you sure they're not being dropped here? and in reverse incoming packets for the VPN first go through FORWARD heading for the virtual VPN interface then get packaged ang go through the OUTPUT chain (source being the kernel) heading for the physical ethernet interface...
Cheers, MaZe.
On Wed, 25 May 2005, simone wrote:
Hi all, first of all I want to apologize for the very long email. This is driving me crazy and in 4 days our current VPN will be dead.
Started over, reconfigured cisco pix following cisco vpn guide and http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html (differences in no-xauth no-config-mode, lifetime 28800 and esp-md5-hmac). Modified rule in firewall, added $IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.10.0/24 -d! 192.168.100.0/24 -j MASQUERADE not to nat packets going to 192.168.100.0 (am I right?), started ipsec and connection on the linux box, public ip 162.x.x.90 private network 192.168.10.x this is the result of setkey -DP
192.168.100.0/24[any] 192.168.10.0/24[any] any in ipsec esp/tunnel/182.xxx.xxx.130-162.xxx.xxx.90/unique#16385 created: May 25 14:19:10 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=992 seq=8 pid=14415 refcnt=1 192.168.10.0/24[any] 192.168.100.0/24[any] any out ipsec esp/tunnel/162.xxx.xxx.90-182.xxx.xxx.130/unique#16385 created: May 25 14:19:10 2005 lastused: May 25 15:42:21 2005 lifetime: 0(s) validtime: 0(s) spid=1009 seq=7 pid=14415 refcnt=2 192.168.100.0/24[any] 192.168.10.0/24[any] any -----> 192.168.100.0/24 is the cisco private network, is this correct? fwd ipsec esp/tunnel/182.xxx.xxx.130-162.xxx.xxx.90/unique#16385 created: May 25 14:19:10 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=1002 seq=6 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=979 seq=5 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: May 25 15:18:31 2005 lifetime: 0(s) validtime: 0(s) spid=963 seq=4 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=947 seq=3 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=988 seq=2 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: May 25 15:18:33 2005 lifetime: 0(s) validtime: 0(s) spid=972 seq=1 pid=14415 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created: May 25 14:18:40 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=956 seq=0 pid=14415 refcnt=1
if I issue the route command I get
192.168.100.0 * 255.255.255.0 U 0 0 0 eth0 192.168.100.0 ip-pub. 255.255.255.0 UG 0 0 0 eth0 192.168.10.0 * 255.255.255.0 U 0 0 0 eth1
where eth1 is 192.168.10.3 and eth0 is ip-pub. = 162.xxx.xxx.90.
ipsec auto status:
"milan" esp.f02a7d60@182.xxx.xxx.130 esp.f8d6586b@162.xxx.xxx.90 tun.0@182.xxx.xxx.130 tun.0@162.xxx.xxx.90
It looks to me that the vpn is estabilished, but still cannot ping from one end to the other....
ping 192.168.100.26 -l 192.168.10.3 or even ping from another linuxbox that's actually natted behind this machine (and can see the web).
Any suggestion on where to look for troubleshooting will be very appreciated, have a nice day.
Simone
On Tue, 2005-05-24 at 17:07, Peter Farrow wrote:
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Vuoi ricevere gratuitamente, ogni giorno, un trucco per imparare a smanettare con il tuo PC?
- Iscriviti ad Untruccoalgiorno, GRATIS, per tutti! Clicca qui
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3413&d=25-5 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Audio, Video, HI-FI...oltre 2.000 prodotti di alta qualità a prezzi da sogno solo su Visualdream.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2954&d=25-5
I'd suggest dropping (or commenting out) the -p 50 and -p 51 rules if you're not using ipv6 and I'd suggest adding -i dev and -o dev to any rules where possible (-i in INPUT and FORWARD being input device and -o in FORWARD and OUTPUT being output device)
this seems _very_ dangerous, what is this supposed to achieve? is this needed?
$IPTABLES -A INPUT -i $EXTIF -s ${remotenetwork} -d $INTNET -j ACCEPT
drop these two:
$IPTABLES -A INPUT -p 51 -j ACCEPT $IPTABLES -A INPUT -p 50 -j ACCEPT
this should have probably also have "-i $EXTIF" and "-s $OTHER-VPN-GLOBAL-IP"
$IPTABLES -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
OUTPUT is usually safe :)
you should add -i and -o here (using INTERNAL NET DEVICE and virtual proxy device as the parameters)
$IPTABLES -A FORWARD -s $INTNET -d ${remotenetwork} -j ACCEPT $IPTABLES -A FORWARD -s ${remotenetwork} -d $INTNET -j ACCEPT
not sure about this...
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -d! 192.168.100.0/24 -j SNAT --to $EXTIP
anyways, cheers, MaZe.
Hi, did some testing and refined iptables conf following your suggestions :)
On Wed, 2005-05-25 at 18:34, Maciej Żenczykowski wrote:
I'd suggest dropping (or commenting out) the -p 50 and -p 51 rules if you're not using ipv6 and I'd suggest adding -i dev and -o dev to any rules where possible (-i in INPUT and FORWARD being input device and -o in FORWARD and OUTPUT being output device)
this seems _very_ dangerous, what is this supposed to achieve? is this needed?
$IPTABLES -A INPUT -i $EXTIF -s ${remotenetwork} -d $INTNET -j ACCEPT
Right, good for me it's a testing environment. In fact it is not needed.
drop these two:
$IPTABLES -A INPUT -p 51 -j ACCEPT $IPTABLES -A INPUT -p 50 -j ACCEPT
Looks like if I drop these it won't work. So I changed it to just catch packets coming from the cisco pix public IP at the other end:
$IPTABLES -A INPUT -i $EXTIF -s $PIX -p 51 -j ACCEPT $IPTABLES -A INPUT -i $EXTIF -s $PIX -p 50 -j ACCEPT $IPTABLES -A INPUT -i $EXTIF -s $PIX -p udp --sport 500 --dport 500 -j ACCEPT $IPTABLES -A OUTPUT -o $EXTIF -d $PIX -p 51 -j ACCEPT $IPTABLES -A OUTPUT -o $EXTIF -d $PIX -p 50 -j ACCEPT $IPTABLES -A OUTPUT -o $EXTIF -d $PIX -p udp --sport 500 --dport 500 -j ACCEPT
this should have probably also have "-i $EXTIF" and "-s $OTHER-VPN-GLOBAL-IP"
$IPTABLES -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
OUTPUT is usually safe :)
you should add -i and -o here (using INTERNAL NET DEVICE and virtual proxy device as the parameters)
$IPTABLES -A FORWARD -s $INTNET -d ${remotenetwork} -j ACCEPT $IPTABLES -A FORWARD -s ${remotenetwork} -d $INTNET -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -s $INTNET -o $EXTIF -d ${remotenetwork} -j ACCEPT $IPTABLES -A FORWARD -i $EXTIF -s ${remotenetwork} -o $INTIF -d $INTNET -j ACCEPT
not sure about this...
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -d! 192.168.100.0/24 -j SNAT --to $EXTIP
Well, I added this not to Nat packets from INTNET to remotenet (there a needed rule on the pix on the other side), but it was not written right. I had to split this in two since I couldn't fine a one line way to do it, but it works now $IPTABLES -t nat -A POSTROUTING -s $INTNET -d $FBCMEDIA -j ACCEPT $IPTABLES -t nat -A POSTROUTING -s $INTNET -o $EXTIF -j SNAT --to $EXTIP
First line accepting packets to remotenet without natting, second line natting all the rest.
anyways, cheers, MaZe.
Well, soon going to set this up on the remote linuxbox. This has been a really nice experience, I learned a lot thanks to everyone that partecipated in this topic.
Have a nice day Simone
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Telefona con Email.it Phone Card, tanti minuti di conversazione con il massimo del risparmio, clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2687&d=26-5
This seems very decent now!
Looks like if I drop these it won't work. So I changed it to just catch packets coming from the cisco pix public IP at the other end:
weird protocol 50 and 51 are theoretically ipv6 related, oh well
this next one could probably also contain a "-o $VIRTUALVPNINTERFACE"
$IPTABLES -t nat -A POSTROUTING -s $INTNET -d $FBCMEDIA -j ACCEPT
and that's about it - seems real nice now.
(now to get my own centos4-centos4 VPN working...)
Cheers, MaZe.
Maciej Żenczykowski wrote:
This seems very decent now!
Thanks :)
Looks like if I drop these it won't work. So I changed it to just catch packets coming from the cisco pix public IP at the other end:
weird protocol 50 and 51 are theoretically ipv6 related, oh well
Found that port 50 is for IPSEC ESP and 51 AH - http://openskills.info/infobox.php?ID=1291 good to know
this next one could probably also contain a "-o $VIRTUALVPNINTERFACE"
I did try to use -o ipsec0 and it works, but where is this ipsec0 device? Is this set in the ipsec.conf - interface="ipsec0=eth0"? nevermind
$IPTABLES -t nat -A POSTROUTING -s $INTNET -d $FBCMEDIA -j ACCEPT
and that's about it - seems real nice now.
Yes, the two networks can talk, only the vpn server itself is not reacheable from the remote network. I red somewhere about this (too much googling :) ) so hopefully I'll fix it.
(now to get my own centos4-centos4 VPN working...) Cheers, MaZe.
Have a nice day
This might be useful too:
http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html
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@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 EUR a casa tua Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2291&d=24-5 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos