Re: [pfSense Support] ipsec
All my vpn's are working fine. On 7/29/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > This IPSEC tunnel used to work on an earlyier versionand now it doesn't > > Is there stillissues with ipsec stuff??? > > > > > > Server1 > > > > This pfsense box is being coonected to > > > > > racoon: INFO: ISAKMP-SA established 192.168.3.101[500]-80.242.37.134[500] > spi:3bd28a84bb4e8865:0a2d5d0284a5ea3f > > > Jul 30 01:45:27 > > racoon: INFO: respond new phase 2 negotiation: > 192.168.3.101[0]<=>80.242.37.134[0] > > > Jul 30 01:45:27 > > racoon: INFO: no policy found, try to generate the policy : > 10.4.230.10/32[0] 10.4.237.0/24[0] proto=any dir=in > > > Jul 30 01:45:30 > > kernel: WARNING: pseudo-random number generator used for IPsec processing > > > Jul 30 01:45:30 > > kernel: WARNING: pseudo-random number generator used for IPsec processing > > > Jul 30 01:45:30 > > racoon: INFO: IPsec-SA established: ESP/Tunnel > xxx.xxx.xxx.xx1[0]->xxx.xxx.xxx.xx2[0] spi=161785307(0x9a4a5db) > > > Jul 30 01:45:30 > > racoon: INFO: IPsec-SA established: ESP/Tunnel > xxx.xxx.xxx.xx2[0]->xxx.xxx.xxx.xx1[0] spi=56018201(0x356c519) > > > Jul 30 01:45:30 > > racoon: ERROR: such policy does not already exist: xxx.xxx.xxx.local1/32[0] > xxx.xxx.local2.0/24[0] proto=any dir=in > > > Jul 30 01:45:30 > > racoon: ERROR: such policy does not already exist: xxx.xxx.local2.0/24[0] > xxx.xxx.xxx.local1/32[0] proto=any dir=out > > > > > > > > > Sever2 > > > > This pfsense box is connecting to the other > > > > > > Jul 30 01:45:24 > > racoon: INFO: begin Aggressive mode. > > > Jul 30 01:45:26 > > racoon: WARNING: No ID match. > > > Jul 30 01:45:26 > > racoon: INFO: ISAKMP-SA established > xxx.xxx.xxx.xx2[500]-xxx.xxx.xxx.xx1[500] > spi:3bd28a84bb4e8865:0a2d5d0284a5ea3f > > > Jul 30 01:45:27 > > racoon: INFO: initiate new phase 2 negotiation: > xxx.xxx.xxx.xx1[0]<=>xxx.xxx.xxx.xx2[0] > > > Jul 30 01:45:30 > > racoon: INFO: IPsec-SA established: ESP/Tunnel > xxx.xxx.xxx.xx2[0]->xxx.xxx.xxx.xx1[0] spi=56018201(0x356c519) > > > Jul 30 01:45:30 > > racoon: INFO: IPsec-SA established: ESP/Tunnel > xxx.xxx.xxx.xx1[0]->xxx.xxx.xxx.xx2[0] spi=161785307(0x9a4a5db) > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec
This must have got overwritten when we sync'd to m0n0wall for their certificate support. Do a update_file.sh /usr/local/www/vpn_ipsec_edit.php and all should be well again (I hope). Scott On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 subnets. I > upgraded to 0.86.4 and again to 0.88.0 > > Neither seem to support the following configuration in gui any more. > > > > The will not work: > > > > Localnet192.168.1.1/24 remotegateway: public > address > > Remotenet0.0.0.0/0 > > > > But this works : > > > > Localnet0.0.0.0/0 remotegateway: public > address > > Remotenet192.168.1.1/24 > > > > Regards. > > > > Hope you can help me with this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec
thanks > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 21 October 2005 21:40 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec > > This must have got overwritten when we sync'd to m0n0wall for their > certificate support. Do a update_file.sh > /usr/local/www/vpn_ipsec_edit.php and all should be well again (I > hope). > > Scott > > > On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 subnets. > I > > upgraded to 0.86.4 and again to 0.88.0 > > > > Neither seem to support the following configuration in gui any more. > > > > > > > > The will not work: > > > > > > > > Localnet192.168.1.1/24 remotegateway: public > > address > > > > Remotenet0.0.0.0/0 > > > > > > > > But this works : > > > > > > > > Localnet0.0.0.0/0 remotegateway: > public > > address > > > > Remotenet192.168.1.1/24 > > > > > > > > Regards. > > > > > > > > Hope you can help me with this. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec
> > This must have got overwritten when we sync'd to m0n0wall for their > certificate support. Do a update_file.sh > /usr/local/www/vpn_ipsec_edit.php and all should be well again (I > hope). > > Scott [alan walters] I copyed that file from the releng branch of the cvs but stillthe same. The box is isolated from the internet so no way to update it apart from manually. This still produced the same error. Remote subnet bits cannot be zero. > > > On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 subnets. > I > > upgraded to 0.86.4 and again to 0.88.0 > > > > Neither seem to support the following configuration in gui any more. > > > > > > > > The will not work: > > > > > > > > Localnet192.168.1.1/24 remotegateway: public > > address > > > > Remotenet0.0.0.0/0 > > > > > > > > But this works : > > > > > > > > Localnet0.0.0.0/0 remotegateway: > public > > address > > > > Remotenet192.168.1.1/24 > > > > > > > > Regards. > > > > > > > > Hope you can help me with this. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec
Hi guys, i know that this question may seem to be silly but, if what you want is to establish an ipsec tunnel in a roadwarrior-fashion why don't you use any other type of CN? i mean, use a dyndns name, an email address, etc... In contrary case you can use OpenVPN, that is not ipsec but will enable you easily achieve what i think you need. Just to finnish, 0.0.0.0 is not a good idea because you use ipsec to setup net-to-net tunnel... Using 0.0.0.0 you likely be a vpn hub that is something 'weird' from the security point of view. That's my 0.02€ ;) Regards, jonathan alan walters wrote: This must have got overwritten when we sync'd to m0n0wall for their certificate support. Do a update_file.sh /usr/local/www/vpn_ipsec_edit.php and all should be well again (I hope). Scott [alan walters] I copyed that file from the releng branch of the cvs but stillthe same. The box is isolated from the internet so no way to update it apart from manually. This still produced the same error. Remote subnet bits cannot be zero. On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 subnets. I upgraded to 0.86.4 and again to 0.88.0 Neither seem to support the following configuration in gui any more. The will not work: Localnet192.168.1.1/24 remotegateway: public address Remotenet0.0.0.0/0 But this works : Localnet0.0.0.0/0 remotegateway: public address Remotenet192.168.1.1/24 Regards. Hope you can help me with this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec
Yep I use an email address as the cn. Open vpn would be great but this seems to still not be available. Even a gre tunnel would do what I require but again not built into pfsense. So I persevere this way. The only security concern that I can see is the the vpn hub. This is a concern but pfsense seems to be reasonably well locked down. The whole point of the hub is to be able to get a central public block to a large number of remote sites that I cannot route blocks to. I might take you advise though and try with openvpn if I can get the devel options to work and enable it. > -Original Message- > From: jonathan gonzalez [mailto:[EMAIL PROTECTED] > Sent: 22 October 2005 17:57 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec > > Hi guys, > > i know that this question may seem to be silly but, if what you want is > to establish an ipsec tunnel in a roadwarrior-fashion why don't you use > any other type of CN? > > i mean, use a dyndns name, an email address, etc... > > In contrary case you can use OpenVPN, that is not ipsec but will enable > you easily achieve what i think you need. > > Just to finnish, 0.0.0.0 is not a good idea because you use ipsec to > setup net-to-net tunnel... Using 0.0.0.0 you likely be a vpn hub that is > something 'weird' from the security point of view. > > That's my 0.02€ ;) > > Regards, > > jonathan > > > > > > alan walters wrote: > >>This must have got overwritten when we sync'd to m0n0wall for their > >>certificate support. Do a update_file.sh > >>/usr/local/www/vpn_ipsec_edit.php and all should be well again (I > >>hope). > >> > >>Scott > > > > > > [alan walters] > > > > I copyed that file from the releng branch of the cvs but stillthe same. > > The box is isolated from the internet so no way to update it apart from > > manually. This still produced the same error. Remote subnet bits cannot > > be zero. > > > > > >> > >>On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: > >> > >>> > >>> > >>>I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 > > > > subnets. > > > >>I > >> > >>>upgraded to 0.86.4 and again to 0.88.0 > >>> > >>>Neither seem to support the following configuration in gui any more. > >>> > >>> > >>> > >>>The will not work: > >>> > >>> > >>> > >>>Localnet192.168.1.1/24 remotegateway: > > > > public > > > >>>address > >>> > >>>Remotenet0.0.0.0/0 > >>> > >>> > >>> > >>>But this works : > >>> > >>> > >>> > >>>Localnet0.0.0.0/0 remotegateway: > >> > >>public > >> > >>>address > >>> > >>>Remotenet192.168.1.1/24 > >>> > >>> > >>> > >>>Regards. > >>> > >>> > >>> > >>>Hope you can help me with this. > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec
i'm working also in the openvpn implementation in my box so if either each one obtain good result would be grateful to post the good news in the list, don't you think? ;) Regards, jonathan alan walters wrote: Yep I use an email address as the cn. Open vpn would be great but this seems to still not be available. Even a gre tunnel would do what I require but again not built into pfsense. So I persevere this way. The only security concern that I can see is the the vpn hub. This is a concern but pfsense seems to be reasonably well locked down. The whole point of the hub is to be able to get a central public block to a large number of remote sites that I cannot route blocks to. I might take you advise though and try with openvpn if I can get the devel options to work and enable it. -Original Message- From: jonathan gonzalez [mailto:[EMAIL PROTECTED] Sent: 22 October 2005 17:57 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec Hi guys, i know that this question may seem to be silly but, if what you want is to establish an ipsec tunnel in a roadwarrior-fashion why don't you use any other type of CN? i mean, use a dyndns name, an email address, etc... In contrary case you can use OpenVPN, that is not ipsec but will enable you easily achieve what i think you need. Just to finnish, 0.0.0.0 is not a good idea because you use ipsec to setup net-to-net tunnel... Using 0.0.0.0 you likely be a vpn hub that is something 'weird' from the security point of view. That's my 0.02€ ;) Regards, jonathan alan walters wrote: This must have got overwritten when we sync'd to m0n0wall for their certificate support. Do a update_file.sh /usr/local/www/vpn_ipsec_edit.php and all should be well again (I hope). Scott [alan walters] I copyed that file from the releng branch of the cvs but stillthe same. The box is isolated from the internet so no way to update it apart from manually. This still produced the same error. Remote subnet bits cannot be zero. On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 subnets. I upgraded to 0.86.4 and again to 0.88.0 Neither seem to support the following configuration in gui any more. The will not work: Localnet192.168.1.1/24 remotegateway: public address Remotenet0.0.0.0/0 But this works : Localnet0.0.0.0/0 remotegateway: public address Remotenet192.168.1.1/24 Regards. Hope you can help me with this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec
Great idea. You got me to look at it anyway, and I would not have before. It looks possible to achieve the idea with openvpn. I have a test setup At the moent for ipsec I will try it out with openvpn tunnels and see if it works. Will post performance tests of results in a few days. Any configurations that you or anyone has of working openvpn configs would be helpfull > -Original Message- > From: jonathan gonzalez [mailto:[EMAIL PROTECTED] > Sent: 22 October 2005 18:54 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec > > i'm working also in the openvpn implementation in my box so if either > each one obtain good result would be grateful to post the good news in > the list, don't you think? ;) > > Regards, > > jonathan > > > > alan walters wrote: > > Yep I use an email address as the cn. > > Open vpn would be great but this seems to still not be available. > > Even a gre tunnel would do what I require but again not built into > pfsense. > > > > So I persevere this way. The only security concern that I can see is the > the vpn hub. This is a concern but pfsense seems to be reasonably well > locked down. > > > > The whole point of the hub is to be able to get a central public block > to a large number of remote sites that I cannot route blocks to. > > > > I might take you advise though and try with openvpn if I can get the > devel options to work and enable it. > > > > > >>-----Original Message----- > >>From: jonathan gonzalez [mailto:[EMAIL PROTECTED] > >>Sent: 22 October 2005 17:57 > >>To: support@pfsense.com > >>Subject: Re: [pfSense Support] ipsec > >> > >>Hi guys, > >> > >>i know that this question may seem to be silly but, if what you want is > >>to establish an ipsec tunnel in a roadwarrior-fashion why don't you use > >>any other type of CN? > >> > >>i mean, use a dyndns name, an email address, etc... > >> > >>In contrary case you can use OpenVPN, that is not ipsec but will enable > >>you easily achieve what i think you need. > >> > >>Just to finnish, 0.0.0.0 is not a good idea because you use ipsec to > >>setup net-to-net tunnel... Using 0.0.0.0 you likely be a vpn hub that is > >>something 'weird' from the security point of view. > >> > >>That's my 0.02€ ;) > >> > >>Regards, > >> > >>jonathan > >> > >> > >> > >> > >> > >>alan walters wrote: > >> > >>>>This must have got overwritten when we sync'd to m0n0wall for their > >>>>certificate support. Do a update_file.sh > >>>>/usr/local/www/vpn_ipsec_edit.php and all should be well again (I > >>>>hope). > >>>> > >>>>Scott > >>> > >>> > >>>[alan walters] > >>> > >>>I copyed that file from the releng branch of the cvs but stillthe same. > >>>The box is isolated from the internet so no way to update it apart from > >>>manually. This still produced the same error. Remote subnet bits cannot > >>>be zero. > >>> > >>> > >>> > >>>>On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> > >>>>>I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 > >>> > >>>subnets. > >>> > >>> > >>>>I > >>>> > >>>> > >>>>>upgraded to 0.86.4 and again to 0.88.0 > >>>>> > >>>>>Neither seem to support the following configuration in gui any more. > >>>>> > >>>>> > >>>>> > >>>>>The will not work: > >>>>> > >>>>> > >>>>> > >>>>>Localnet192.168.1.1/24 remotegateway: > >>> > >>>public > >>> > >>> > >>>>>address > >>>>> > >>>>>Remotenet0.0.0.0/0 > >>>>> > >>>>> > >>>>> > >>>>>But this works : > >>>>> > >>>>> > >>>>> > >>>>>Localnet0.0.0.0/0 remotegateway: > >>>> > >>>>public > >>>> > >>>> > >>>>>address > >>>>> > >>>>>Remotenet192.168.1.1/24 > >>>>> > >>>>> > >>>>> > >>>>>Regards. > >>>>> > >>>>> > >>>>> > >>>>>Hope you can help me with this. > >>>> > >>>>- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>>- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec
Try it again. I made a boo-boo. Scott On 10/22/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > This must have got overwritten when we sync'd to m0n0wall for their > > certificate support. Do a update_file.sh > > /usr/local/www/vpn_ipsec_edit.php and all should be well again (I > > hope). > > > > Scott > > [alan walters] > > I copyed that file from the releng branch of the cvs but stillthe same. > The box is isolated from the internet so no way to update it apart from > manually. This still produced the same error. Remote subnet bits cannot > be zero. > > > > > > > On 10/21/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I know some time ago we looked at ipsec tunnels with 0.0.0.0/0 > subnets. > > I > > > upgraded to 0.86.4 and again to 0.88.0 > > > > > > Neither seem to support the following configuration in gui any more. > > > > > > > > > > > > The will not work: > > > > > > > > > > > > Localnet192.168.1.1/24 remotegateway: > public > > > address > > > > > > Remotenet0.0.0.0/0 > > > > > > > > > > > > But this works : > > > > > > > > > > > > Localnet0.0.0.0/0 remotegateway: > > public > > > address > > > > > > Remotenet192.168.1.1/24 > > > > > > > > > > > > Regards. > > > > > > > > > > > > Hope you can help me with this. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC
Von: Anil Garg [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 28. Februar 2008 04:51 An: support@pfsense.com Betreff: [pfSense Support] IPSEC ... Have looked at all documents and spent many hours without avail... Will some of you learned people suggest a way out.. I can only get a Public IP address at one location and I am happy to do pay > for that. But the second location being a AT&T DSL in San Jose, CA - this > is not an option,. Much appreciate your help and guidance. Anil, To answer your question with respect to IPsec in general, the solution to your problem depends on a lot of different factors. Having one IPsec peer using a non-public address pre-supposes that the address will be translated to a public address by a NAT device. So the question could have been stated as "can one IPsec peer operate behind a NAT device?". The answer is yes, but the question is still complicated. Who controls the NAT device and how sophisticated is the NAT logic? The IKE protocol, which based on UDP, is typically used to establish IPsec connectivity. The source address of UDP traffic is easily NATd on the outbound path. With this in mind, if the peer behind the NAT device always initiates negotiations then you shouldn't have too much of a problem. Where an issue will occur is when the peer that has the public address attempts to initiate an exchange to the peer behind the NAT device. If you control the NAT process and the NAT device is somewhat sophisticated, you can teach it to perform a static NAT which will translate the destination address of a packet sourced from the public peer to the private peer address. This is typically referred to as port forwarding. If traffic always originates from the peer behind the NAT, you can typically turn contact off for the publicly addressed peer and avoid this situation all together. So that addresses IKE traffic which provides negotiation and key setup, but there are other protocols that make up IPsec. To provide protection and message authentication, the ESP protocol is typically used to encapsulate and encrypt protected traffic. ESP is an IP protocol, like TCP or UDP, but its header contains no port values. This makes it difficult to pass transparently through a NAT device because you don't have ports to translate and build state information with. For NAT devices that hide many privately addressed hosts behind a single public address, valid state information is an essential key to translating a public destination address to the appropriate private destination address when processing inbound packets. The only data a NAT device has to work with to correlate state to an inbound ESP packet is the source and destination addresses. However, this should be adequate if there is only one IPsec peer behind the NAT device communicating with the publicly addressed peer and traffic is bidirectional. Once again, if you control of the NAT device it should be possible to always translate the destination address of all ESP traffic sourced from a specific peer to the private destination address of the NATd peer. Why do I feel like I need my dry erase board? :) What if you don't have control over the NAT device or its too primitive? Your probably out of luck unless both ends of the connection support NAT-T or Nat Traversal which is an extension to the IKE/IPsec protocol family. What it does is multiplex both IKE and encapsulated ESP traffic onto a single UDP port which passes more easily through NAT devices. It also defines ways of keeping Firewall/NAT states from expiring by constantly sending traffic between the two hosts. This allows rekey attempts to be initiated by either IPsec peer. As far as I know, NAT-T is not currently supported by pfsense but I have high hopes that it will be introduced into the mainline FreeBSD sources soon. Probably more info than you wanted but I hope it helps, -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC
Mathew - Wow. Thank you so much for taking time to write such detailed thoughts. I will fully use this and write again . Best Regards Anil Garg Matthew Grooms <[EMAIL PROTECTED]> wrote: > Von: Anil Garg [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 28. Februar 2008 04:51 > An: support@pfsense.com > Betreff: [pfSense Support] IPSEC > ... > Have looked at all documents and spent many hours without avail... > Will some of you learned people suggest a way out.. I can only > get a Public IP address at one location and I am happy to do pay > for that. > > But the second location being a AT&T DSL in San Jose, CA - this > is not an option,. > > Much appreciate your help and guidance. > Anil, To answer your question with respect to IPsec in general, the solution to your problem depends on a lot of different factors. Having one IPsec peer using a non-public address pre-supposes that the address will be translated to a public address by a NAT device. So the question could have been stated as "can one IPsec peer operate behind a NAT device?". The answer is yes, but the question is still complicated. Who controls the NAT device and how sophisticated is the NAT logic? The IKE protocol, which based on UDP, is typically used to establish IPsec connectivity. The source address of UDP traffic is easily NATd on the outbound path. With this in mind, if the peer behind the NAT device always initiates negotiations then you shouldn't have too much of a problem. Where an issue will occur is when the peer that has the public address attempts to initiate an exchange to the peer behind the NAT device. If you control the NAT process and the NAT device is somewhat sophisticated, you can teach it to perform a static NAT which will translate the destination address of a packet sourced from the public peer to the private peer address. This is typically referred to as port forwarding. If traffic always originates from the peer behind the NAT, you can typically turn contact off for the publicly addressed peer and avoid this situation all together. So that addresses IKE traffic which provides negotiation and key setup, but there are other protocols that make up IPsec. To provide protection and message authentication, the ESP protocol is typically used to encapsulate and encrypt protected traffic. ESP is an IP protocol, like TCP or UDP, but its header contains no port values. This makes it difficult to pass transparently through a NAT device because you don't have ports to translate and build state information with. For NAT devices that hide many privately addressed hosts behind a single public address, valid state information is an essential key to translating a public destination address to the appropriate private destination address when processing inbound packets. The only data a NAT device has to work with to correlate state to an inbound ESP packet is the source and destination addresses. However, this should be adequate if there is only one IPsec peer behind the NAT device communicating with the publicly addressed peer and traffic is bidirectional. Once again, if you control of the NAT device it should be possible to always translate the destination address of all ESP traffic sourced from a specific peer to the private destination address of the NATd peer. Why do I feel like I need my dry erase board? :) What if you don't have control over the NAT device or its too primitive? Your probably out of luck unless both ends of the connection support NAT-T or Nat Traversal which is an extension to the IKE/IPsec protocol family. What it does is multiplex both IKE and encapsulated ESP traffic onto a single UDP port which passes more easily through NAT devices. It also defines ways of keeping Firewall/NAT states from expiring by constantly sending traffic between the two hosts. This allows rekey attempts to be initiated by either IPsec peer. As far as I know, NAT-T is not currently supported by pfsense but I have high hopes that it will be introduced into the mainline FreeBSD sources soon. Probably more info than you wanted but I hope it helps, -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC
Re: --- |It looks like that it needs a public ip address to create a tunnel. I |could try and get public IP address at one place but it looks like it |still will not work because I need public IP address on both sides. --- We use pfSense 1.2 to support a VPN between 2 offices. In our case, one site has a static IP and one has a dynamic IP but the dynamic IP doesn't change very often. Originally I didn't have time to look into the "Mobile Clients" setup (and still wouldn't want to use it because of the reduced security when using aggressive mode). I decided to use the dynamic IP of the other office (i.e., as 'though it was static) and auto-update it, as required. Since we use DynDNS for the other/remote office, I wrote a shell script that checks to determine whether the remote-office's IP has changed and, if it has, updates pfSense's VPN IPSec setup to reflect that change. In our case, the script is run via cron every few minutes and that's sufficient, for us. The shell script uses fairly common UNIX tools (curl, sed, etc.) to interact with pfSense via its web pages. While it might have been nicer to do this on the router, it wasn't obvious how to do so (I'm not fluent in php) and I didn't have much time to play. In case anyone else might find this useful, a PDF of the (sanitized) VPN IPSec setup and the (commented) shell script can be downloaded via http://www.derman.com/Download/Special/UpdateRemoteGateway.zip It'll be nicer when pfSense 1.3 makes this obsolete. #;-) __ Original message from Anil Garg on 2008-02-27 at 7:51 PM -0800 -- |Hey guys - I am a happy camper with pfsense and recently upgraded to 1.2 |and have no issues to report so far. | |I am trying to hook up two pfsense boxes with IPSEC site to site | |It looks like that it needs a public ip address to create a tunnel. I |could try and get public IP address at one place but it looks like it |still will not work because I need public IP address on both sides. | |Have looked at all documents and spent many hours without avail... | |Will some of you learned people suggest a way out.. I can only get a |Public IP address at one location and I am happy to do pay for that. |But the second location being a AT&T DSL in San Jose, CA - this is not |an option,. | |Much appreciate your help and guidance. | |Best Regards |Anil Garg
Re: [pfSense Support] IPSEC
Mathew - I read your write up many times and this thing is clear like day and night. Since both sides need to have a matching rule and the side that has static IP can not write a dynamic address in its remote gateway is the main difficulty. I have an old Linksys and that accepts static IP for its wan. It also accepts dynamic IP for ipsec and so it connected wih my pfsense 1.2rc4 within seconds. See the picture attached... It worked... You should be a teacher. You are so good in conveying the fundamentals & concepts. Thanks a ton. Best Regards Anil Garg Matthew Grooms <[EMAIL PROTECTED]> wrote: > Von: Anil Garg [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 28. Februar 2008 04:51 > An: support@pfsense.com > Betreff: [pfSense Support] IPSEC > ... > Have looked at all documents and spent many hours without avail... > Will some of you learned people suggest a way out.. I can only > get a Public IP address at one location and I am happy to do pay > for that. > > But the second location being a AT&T DSL in San Jose, CA - this > is not an option,. > > Much appreciate your help and guidance. > Anil, To answer your question with respect to IPsec in general, the solution to your problem depends on a lot of different factors. Having one IPsec peer using a non-public address pre-supposes that the address will be translated to a public address by a NAT device. So the question could have been stated as "can one IPsec peer operate behind a NAT device?". The answer is yes, but the question is still complicated. Who controls the NAT device and how sophisticated is the NAT logic? The IKE protocol, which based on UDP, is typically used to establish IPsec connectivity. The source address of UDP traffic is easily NATd on the outbound path. With this in mind, if the peer behind the NAT device always initiates negotiations then you shouldn't have too much of a problem. Where an issue will occur is when the peer that has the public address attempts to initiate an exchange to the peer behind the NAT device. If you control the NAT process and the NAT device is somewhat sophisticated, you can teach it to perform a static NAT which will translate the destination address of a packet sourced from the public peer to the private peer address. This is typically referred to as port forwarding. If traffic always originates from the peer behind the NAT, you can typically turn contact off for the publicly addressed peer and avoid this situation all together. So that addresses IKE traffic which provides negotiation and key setup, but there are other protocols that make up IPsec. To provide protection and message authentication, the ESP protocol is typically used to encapsulate and encrypt protected traffic. ESP is an IP protocol, like TCP or UDP, but its header contains no port values. This makes it difficult to pass transparently through a NAT device because you don't have ports to translate and build state information with. For NAT devices that hide many privately addressed hosts behind a single public address, valid state information is an essential key to translating a public destination address to the appropriate private destination address when processing inbound packets. The only data a NAT device has to work with to correlate state to an inbound ESP packet is the source and destination addresses. However, this should be adequate if there is only one IPsec peer behind the NAT device communicating with the publicly addressed peer and traffic is bidirectional. Once again, if you control of the NAT device it should be possible to always translate the destination address of all ESP traffic sourced from a specific peer to the private destination address of the NATd peer. Why do I feel like I need my dry erase board? :) What if you don't have control over the NAT device or its too primitive? Your probably out of luck unless both ends of the connection support NAT-T or Nat Traversal which is an extension to the IKE/IPsec protocol family. What it does is multiplex both IKE and encapsulated ESP traffic onto a single UDP port which passes more easily through NAT devices. It also defines ways of keeping Firewall/NAT states from expiring by constantly sending traffic between the two hosts. This allows rekey attempts to be initiated by either IPsec peer. As far as I know, NAT-T is not currently supported by pfsense but I have high hopes that it will be introduced into the mainline FreeBSD sources soon. Probably more info than you wanted but I hope it helps, -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <>- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC
Bryan - This is ingenious. Awesome. Why can this not run on the pfsense router itself as a scheduled task/ cron job. and update the ip address. Sounds like that would be a simple ping to .dyndns.org. Even if the ping fails the first line provides the last known IP address for the dyndns. Which can then be used... I will try and study this more but I am sure the greatest and the best on the forum can solve this in minutes!!! Thanks again for the utility. Best Regards Bryan Derman <[EMAIL PROTECTED]> wrote: Re: [pfSense Support] IPSEC Re: --- It looks like that it needs a public ip address to create a tunnel. I could try and get public IP address at one place but it looks like it still will not work because I need public IP address on both sides. --- We use pfSense 1.2 to support a VPN between 2 offices. In our case, one site has a static IP and one has a dynamic IP but the dynamic IP doesn't change very often. Originally I didn't have time to look into the "Mobile Clients" setup (and still wouldn't want to use it because of the reduced security when using aggressive mode). I decided to use the dynamic IP of the other office (i.e., as 'though it was static) and auto-update it, as required. Since we use DynDNS for the other/remote office, I wrote a shell script that checks to determine whether the remote-office's IP has changed and, if it has, updates pfSense's VPN IPSec setup to reflect that change. In our case, the script is run via cron every few minutes and that's sufficient, for us. The shell script uses fairly common UNIX tools (curl, sed, etc.) to interact with pfSense via its web pages. While it might have been nicer to do this on the router, it wasn't obvious how to do so (I'm not fluent in php) and I didn't have much time to play. In case anyone else might find this useful, a PDF of the (sanitized) VPN IPSec setup and the (commented) shell script can be downloaded via http://www.derman.com/Download/Special/UpdateRemoteGateway.zip It'll be nicer when pfSense 1.3 makes this obsolete. #;-) __ Original message from Anil Garg on 2008-02-27 at 7:51 PM -0800 -- Hey guys - I am a happy camper with pfsense and recently upgraded to 1.2 and have no issues to report so far. I am trying to hook up two pfsense boxes with IPSEC site to site It looks like that it needs a public ip address to create a tunnel. I could try and get public IP address at one place but it looks like it still will not work because I need public IP address on both sides. Have looked at all documents and spent many hours without avail... Will some of you learned people suggest a way out.. I can only get a Public IP address at one location and I am happy to do pay for that. But the second location being a AT&T DSL in San Jose, CA - this is not an option,. Much appreciate your help and guidance. Best Regards Anil Garg
Re: [pfSense Support] IPSEC
Re: Why can this not run on the pfsense router itself... --- It could. In fact, that's where I started. However, since the production version of pfSense 1.2 (RC4 at the time) doesn't have curl and since I already have a system that runs various monitoring and log-reporting tasks and since I was in a hurry (excuses, excuses), I opted to do it in a way that'd be the quickest for me, at that time. If curl is available on the development disk (or somewhere) and was installed on the production version, the script could easily be modified (if required) to run on FreeBSD (OS X's roots are FreeBSD + a Mach micro-kernel, IIRC). It's also quite possible that there's an alternative utility that could be used -- I'm not that familiar with FreeBSD. Even better, for someone who's fluent in php, presumably the web-based "API" could be bypassed completely. I had a quick look at doing just that, but it was clear that understanding the flow was going to take me much too long (as much as I would have liked to do so). Another strategy would be to watch the log, detect a failure, then determine whether the remote WAN IP's changed. That would avoid the delay due to the polling interval. FYI, on our network (and in addition to the interval between script runs), the time between the cron-initiated script being run and the VPN being updated with the new IP is about 12 seconds, with the VPN tunnel coming back up only seconds after that. Later ... __ Previous message from Anil Garg on 2008-03-03 at 3:55 PM -0800 -- |Bryan - This is ingenious. Awesome. Why can this not run on the pfsense |router itself as a scheduled task/ cron job. and update the ip address. |Sounds like that would be a simple ping to .dyndns.org. Even if the |ping fails the first line provides the last known IP address for the |dyndns. Which can then be used... | |I will try and study this more but I am sure the greatest and the best |on the forum can solve this in minutes!!! | |Thanks again for the utility. Best Regards -- --- Bryan DermanDerman Enterprises Incorporated http://www.derman.com/
Re: [pfSense Support] IPSEC
Anil Garg wrote: Mathew - I read your write up many times and this thing is clear like day and night. Since both sides need to have a matching rule and the side that has static IP can not write a dynamic address in its remote gateway is the main difficulty. I have an old Linksys and that accepts static IP for its wan. It also accepts dynamic IP for ipsec and so it connected wih my pfsense 1.2rc4 within seconds. See the picture attached... It worked... You should be a teacher. You are so good in conveying the fundamentals & concepts. Thanks a ton. No problem, I'm glad it worked out for you :) -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC
Bryan Derman wrote: > If curl is available on the development disk (or somewhere) and was > installed on the production version, the script could easily be modified login as root and install it thus? # curl curl: Command not found. # pkg_add -r curl Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/curl.tbz... Done. # rehash # curl -I www.google.com HTTP/1.1 302 Found Location: http://www.google.co.uk/ Cache-Control: private Set-Cookie: PREF=ID=3edd03dd328b5c04:TM=1204632103:LM=1204632103:S=YYPAA8zXB5IAp1wM; expires=Thu, 04-Mar-2010 12:01:43 GMT; path=/; domain=.google.com Content-Type: text/html Server: gws Content-Length: 221 Date: Tue, 04 Mar 2008 12:01:43 GMT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
You simply upgraded and did not reinstall? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > I know I have seen a few reports of ipsec issues recently I can confirm that > this problem does seem real to me. > > Working configuration > > > > 0.95.4 tunnel initiator. > > 0.89 something client > > 0.94.12 client > > > > All worked here > > > > As soon as we upgraded a client into 0.95 series ipsec stopped working. > Clients are a mix of pc and embedded platform - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
yep -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 15:53 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues You simply upgraded and did not reinstall? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > I know I have seen a few reports of ipsec issues recently I can > confirm that this problem does seem real to me. > > Working configuration > > > > 0.95.4 tunnel initiator. > > 0.89 something client > > 0.94.12 client > > > > All worked here > > > > As soon as we upgraded a client into 0.95 series ipsec stopped working. > Clients are a mix of pc and embedded platform - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
Actually now that you say that the one box that I did reinstall is fine. This is the issue yes -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 15:53 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues You simply upgraded and did not reinstall? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > I know I have seen a few reports of ipsec issues recently I can > confirm that this problem does seem real to me. > > Working configuration > > > > 0.95.4 tunnel initiator. > > 0.89 something client > > 0.94.12 client > > > > All worked here > > > > As soon as we upgraded a client into 0.95 series ipsec stopped working. > Clients are a mix of pc and embedded platform - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
For me all my tests were with a reflash. I did no upgrades. Thanks John -Original Message- From: alan walters [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 11:13 AM To: support@pfsense.com Subject: RE: [pfSense Support] ipsec issues Actually now that you say that the one box that I did reinstall is fine. This is the issue yes -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 15:53 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues You simply upgraded and did not reinstall? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > I know I have seen a few reports of ipsec issues recently I can > confirm that this problem does seem real to me. > > Working configuration > > > > 0.95.4 tunnel initiator. > > 0.89 something client > > 0.94.12 client > > > > All worked here > > > > As soon as we upgraded a client into 0.95 series ipsec stopped working. > Clients are a mix of pc and embedded platform - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
As an additional note on this wraps(embedded) boxes where reflashed The pc versions where upgraded -Original Message- From: alan walters Sent: 15 December 2005 16:13 To: support@pfsense.com Subject: RE: [pfSense Support] ipsec issues Actually now that you say that the one box that I did reinstall is fine. This is the issue yes -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 15:53 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues You simply upgraded and did not reinstall? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > I know I have seen a few reports of ipsec issues recently I can > confirm that this problem does seem real to me. > > Working configuration > > > > 0.95.4 tunnel initiator. > > 0.89 something client > > 0.94.12 client > > > > All worked here > > > > As soon as we upgraded a client into 0.95 series ipsec stopped working. > Clients are a mix of pc and embedded platform - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
Reflasing fixes it!? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > As an additional note on this wraps(embedded) boxes where reflashed > The pc versions where upgraded > > -Original Message- > From: alan walters > Sent: 15 December 2005 16:13 > To: support@pfsense.com > Subject: RE: [pfSense Support] ipsec issues > > Actually now that you say that the one box that I did reinstall is fine. > This is the issue yes > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 15:53 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > You simply upgraded and did not reinstall? > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > I know I have seen a few reports of ipsec issues recently I can > > confirm that this problem does seem real to me. > > > > Working configuration > > > > > > > > 0.95.4 tunnel initiator. > > > > 0.89 something client > > > > 0.94.12 client > > > > > > > > All worked here > > > > > > > > As soon as we upgraded a client into 0.95 series ipsec stopped > working. > > Clients are a mix of pc and embedded platform > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
Well when I flashed a box clean it is ok. The other ones I have not done anything with yet. It Seems a like a bit of extranious problem. I am having trouble locking it down. It looks like the server is not sending back a correct reply for phase two Still not sure though -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 17:40 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues Reflasing fixes it!? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > As an additional note on this wraps(embedded) boxes where reflashed > The pc versions where upgraded > > -Original Message- > From: alan walters > Sent: 15 December 2005 16:13 > To: support@pfsense.com > Subject: RE: [pfSense Support] ipsec issues > > Actually now that you say that the one box that I did reinstall is fine. > This is the issue yes > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 15:53 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > You simply upgraded and did not reinstall? > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > I know I have seen a few reports of ipsec issues recently I can > > confirm that this problem does seem real to me. > > > > Working configuration > > > > > > > > 0.95.4 tunnel initiator. > > > > 0.89 something client > > > > 0.94.12 client > > > > > > > > All worked here > > > > > > > > As soon as we upgraded a client into 0.95 series ipsec stopped > working. > > Clients are a mix of pc and embedded platform > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
Can you tell me if racoon is listening on * or on the correct ip? Do a sockstat from the shell prompt. I really don't understand why my firmware upgrades went without a hitch and yours required a reinstall. On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > Well when I flashed a box clean it is ok. > > The other ones I have not done anything with yet. It > Seems a like a bit of extranious problem. I am having trouble locking it > down. It looks like the server is not sending back a correct reply for > phase two > > Still not sure though > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 17:40 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Reflasing fixes it!? > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > As an additional note on this wraps(embedded) boxes where reflashed > > The pc versions where upgraded > > > > -Original Message- > > From: alan walters > > Sent: 15 December 2005 16:13 > > To: support@pfsense.com > > Subject: RE: [pfSense Support] ipsec issues > > > > Actually now that you say that the one box that I did reinstall is > fine. > > This is the issue yes > > > > -----Original Message- > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > Sent: 15 December 2005 15:53 > > To: support@pfsense.com > > Subject: Re: [pfSense Support] ipsec issues > > > > You simply upgraded and did not reinstall? > > > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I know I have seen a few reports of ipsec issues recently I can > > > confirm that this problem does seem real to me. > > > > > > Working configuration > > > > > > > > > > > > 0.95.4 tunnel initiator. > > > > > > 0.89 something client > > > > > > 0.94.12 client > > > > > > > > > > > > All worked here > > > > > > > > > > > > As soon as we upgraded a client into 0.95 series ipsec stopped > > working. > > > Clients are a mix of pc and embedded platform > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
Yep it is listening correctly. The boxes in question can still make tunnels to 0.94.12 boxes Only a problem starting at 0.95.4 I will look again tonight and see if anything else looks Odd. I might try and upgrade my Initiation side to the latest version as well and see if this fixes it. -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 17:50 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues Can you tell me if racoon is listening on * or on the correct ip? Do a sockstat from the shell prompt. I really don't understand why my firmware upgrades went without a hitch and yours required a reinstall. On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > Well when I flashed a box clean it is ok. > > The other ones I have not done anything with yet. It Seems a like a > bit of extranious problem. I am having trouble locking it down. It > looks like the server is not sending back a correct reply for phase > two > > Still not sure though > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 17:40 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Reflasing fixes it!? > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > As an additional note on this wraps(embedded) boxes where reflashed > > The pc versions where upgraded > > > > -Original Message- > > From: alan walters > > Sent: 15 December 2005 16:13 > > To: support@pfsense.com > > Subject: RE: [pfSense Support] ipsec issues > > > > Actually now that you say that the one box that I did reinstall is > fine. > > This is the issue yes > > > > -----Original Message- > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > Sent: 15 December 2005 15:53 > > To: support@pfsense.com > > Subject: Re: [pfSense Support] ipsec issues > > > > You simply upgraded and did not reinstall? > > > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I know I have seen a few reports of ipsec issues recently I can > > > confirm that this problem does seem real to me. > > > > > > Working configuration > > > > > > > > > > > > 0.95.4 tunnel initiator. > > > > > > 0.89 something client > > > > > > 0.94.12 client > > > > > > > > > > > > All worked here > > > > > > > > > > > > As soon as we upgraded a client into 0.95 series ipsec stopped > > working. > > > Clients are a mix of pc and embedded platform > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
Also, on the boxes in question do a uname -a from a shell What is the output? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > Yep it is listening correctly. > The boxes in question can still make tunnels to 0.94.12 boxes > > Only a problem starting at 0.95.4 > I will look again tonight and see if anything else looks > Odd. > > I might try and upgrade my > Initiation side to the latest version as well and see if this fixes it. > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 17:50 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Can you tell me if racoon is listening on * or on the correct ip? > > Do a sockstat from the shell prompt. > > I really don't understand why my firmware upgrades went without a hitch > and yours required a reinstall. > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > Well when I flashed a box clean it is ok. > > > > The other ones I have not done anything with yet. It Seems a like a > > bit of extranious problem. I am having trouble locking it down. It > > looks like the server is not sending back a correct reply for phase > > two > > > > Still not sure though > > > > -----Original Message- > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > Sent: 15 December 2005 17:40 > > To: support@pfsense.com > > Subject: Re: [pfSense Support] ipsec issues > > > > Reflasing fixes it!? > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > As an additional note on this wraps(embedded) boxes where reflashed > > > The pc versions where upgraded > > > > > > -Original Message- > > > From: alan walters > > > Sent: 15 December 2005 16:13 > > > To: support@pfsense.com > > > Subject: RE: [pfSense Support] ipsec issues > > > > > > Actually now that you say that the one box that I did reinstall is > > fine. > > > This is the issue yes > > > > > > -Original Message- > > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > > Sent: 15 December 2005 15:53 > > > To: support@pfsense.com > > > Subject: Re: [pfSense Support] ipsec issues > > > > > > You simply upgraded and did not reinstall? > > > > > > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > I know I have seen a few reports of ipsec issues recently I can > > > > confirm that this problem does seem real to me. > > > > > > > > Working configuration > > > > > > > > > > > > > > > > 0.95.4 tunnel initiator. > > > > > > > > 0.89 something client > > > > > > > > 0.94.12 client > > > > > > > > > > > > > > > > All worked here > > > > > > > > > > > > > > > > As soon as we upgraded a client into 0.95 series ipsec stopped > > > working. > > > > Clients are a mix of pc and embedded platform > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional > > > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional > > > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional > > > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > > > commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
uname -a FreeBSD ballyvaughan.radiowave.net 6.0-RC1 FreeBSD 6.0-RC1 #0: Fri Oct 21 16:30:10 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/pfSense.6 i386 Sockstat USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root racoon 658 4 dgram -> /var/run/logpriv root racoon 658 7 udp6 fe80:8::1:500 *:* root racoon 658 8 udp6 ::1:500 *:* root racoon 658 9 udp4 127.0.0.1:500 *:* root racoon 658 10 udp6 fe80:7::280:c8ff:fe37:6c9a:500*:* root racoon 658 11 udp4 192.168.168.1:500 *:* root racoon 658 12 udp6 fe80:6::210:60ff:fe02:79c1:500*:* root racoon 658 13 udp4 192.168.1.100:500 *:* root racoon 658 14 udp6 fe80:4::240:f4ff:fe65:3d13:500*:* root racoon 658 15 udp4 10.4.230.1:500*:* root racoon 658 16 udp6 fe80:1::2c0:9fff:fe1e:2df8:500*:* root racoon 658 17 udp4 192.168.50.1:500 *:* Yep it is listening on all interfaces. -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 18:12 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues Also, on the boxes in question do a uname -a from a shell What is the output? On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > Yep it is listening correctly. > The boxes in question can still make tunnels to 0.94.12 boxes > > Only a problem starting at 0.95.4 > I will look again tonight and see if anything else looks Odd. > > I might try and upgrade my > Initiation side to the latest version as well and see if this fixes it. > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 17:50 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Can you tell me if racoon is listening on * or on the correct ip? > > Do a sockstat from the shell prompt. > > I really don't understand why my firmware upgrades went without a > hitch and yours required a reinstall. > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > Well when I flashed a box clean it is ok. > > > > The other ones I have not done anything with yet. It Seems a like a > > bit of extranious problem. I am having trouble locking it down. It > > looks like the server is not sending back a correct reply for phase > > two > > > > Still not sure though > > > > -----Original Message- > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > Sent: 15 December 2005 17:40 > > To: support@pfsense.com > > Subject: Re: [pfSense Support] ipsec issues > > > > Reflasing fixes it!? > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > As an additional note on this wraps(embedded) boxes where > > > reflashed The pc versions where upgraded > > > > > > -Original Message- > > > From: alan walters > > > Sent: 15 December 2005 16:13 > > > To: support@pfsense.com > > > Subject: RE: [pfSense Support] ipsec issues > > > > > > Actually now that you say that the one box that I did reinstall is > > fine. > > > This is the issue yes > > > > > > -Original Message- > > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > > Sent: 15 December 2005 15:53 > > > To: support@pfsense.com > > > Subject: Re: [pfSense Support] ipsec issues > > > > > > You simply upgraded and did not reinstall? > > > > > > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > I know I have seen a few reports of ipsec issues recently I can > > > > confirm that this problem does seem real to me. > > > > > > > > Working configuration > > > > > > > > > > > > > > > > 0.95.4 tunnel initiator. > > > > > > > > 0.89 something client > > > > > > > > 0.94.12 client > > > > > > > > > > > > > > > > All worked here > > > > > > > > > > > > > > > > As soon as we upgraded a client into 0.95 series ipsec stopped > > > working. > > > > Clients are a mix of pc and embedded platform > > > > > > -- > > > -- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional > > > > > commands, e-mail: [EMAIL PROTECTED] > > >
Re: [pfSense Support] ipsec issues
On Dec 15, 2005, at 12:49 PM, Scott Ullrich wrote: I really don't understand why my firmware upgrades went without a hitch and yours required a reinstall. FWIW my 0.89.2 -> 0.96.2 upgrade seems to work with fixed address IPsec between two offices. I'll test the mobile client once I get home (snowing here, and school's are letting out early...) I'm not on an embedded platform. smime.p7s Description: S/MIME cryptographic signature
Re: [pfSense Support] ipsec issues
Somethings not correct here. We are well past RC1. Try this... rm -rf /boot/kernel/* (DO NOT REBOOT!) Reinstall the latest firmware update. Reboot. Then show me uname -a On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > uname -a > FreeBSD ballyvaughan.radiowave.net 6.0-RC1 FreeBSD 6.0-RC1 #0: Fri Oct > 21 16:30:10 UTC 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/pfSense.6 i386 > > Sockstat > > USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN > ADDRESS > > root racoon 658 4 dgram -> /var/run/logpriv > root racoon 658 7 udp6 fe80:8::1:500 *:* > root racoon 658 8 udp6 ::1:500 *:* > root racoon 658 9 udp4 127.0.0.1:500 *:* > root racoon 658 10 udp6 fe80:7::280:c8ff:fe37:6c9a:500*:* > root racoon 658 11 udp4 192.168.168.1:500 *:* > root racoon 658 12 udp6 fe80:6::210:60ff:fe02:79c1:500*:* > root racoon 658 13 udp4 192.168.1.100:500 *:* > root racoon 658 14 udp6 fe80:4::240:f4ff:fe65:3d13:500*:* > root racoon 658 15 udp4 10.4.230.1:500*:* > root racoon 658 16 udp6 fe80:1::2c0:9fff:fe1e:2df8:500*:* > root racoon 658 17 udp4 192.168.50.1:500 *:* > > Yep it is listening on all interfaces. > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 18:12 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Also, on the boxes in question do a uname -a from a shell > > What is the output? > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > Yep it is listening correctly. > > The boxes in question can still make tunnels to 0.94.12 boxes > > > > Only a problem starting at 0.95.4 > > I will look again tonight and see if anything else looks Odd. > > > > I might try and upgrade my > > Initiation side to the latest version as well and see if this fixes > it. > > > > -Original Message- > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > Sent: 15 December 2005 17:50 > > To: support@pfsense.com > > Subject: Re: [pfSense Support] ipsec issues > > > > Can you tell me if racoon is listening on * or on the correct ip? > > > > Do a sockstat from the shell prompt. > > > > I really don't understand why my firmware upgrades went without a > > hitch and yours required a reinstall. > > > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > Well when I flashed a box clean it is ok. > > > > > > The other ones I have not done anything with yet. It Seems a like a > > > bit of extranious problem. I am having trouble locking it down. It > > > looks like the server is not sending back a correct reply for phase > > > two > > > > > > Still not sure though > > > > > > -Original Message- > > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > > Sent: 15 December 2005 17:40 > > > To: support@pfsense.com > > > Subject: Re: [pfSense Support] ipsec issues > > > > > > Reflasing fixes it!? > > > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > As an additional note on this wraps(embedded) boxes where > > > > reflashed The pc versions where upgraded > > > > > > > > -----Original Message- > > > > From: alan walters > > > > Sent: 15 December 2005 16:13 > > > > To: support@pfsense.com > > > > Subject: RE: [pfSense Support] ipsec issues > > > > > > > > Actually now that you say that the one box that I did reinstall is > > > fine. > > > > This is the issue yes > > > > > > > > -Original Message- > > > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > > > Sent: 15 December 2005 15:53 > > > > To: support@pfsense.com > > > > Subject: Re: [pfSense Support] ipsec issues > > > > > > > > You simply upgraded and did not reinstall? > > > > > > > > > > > > On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > I know I have seen a few reports of ipsec issues recently I can > > > > > confirm that this problem does seem real to me. > > > > > > > > > > Working configu
Re: [pfSense Support] ipsec issues
On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: Somethings not correct here. We are well past RC1. inneresting... my 0.96.2 upgraded box also has the same uname -a output. A bunch of modules in /boot/kernel are dated december 11, but the kernel file and a bunch of other modules are dated october 22... OH I see it. We now install /boot/kernel.gz (dated december 11) but the loader is picking up the older uncompressed version. Looks like the upgrade should delete the older kernel... I suspect the right thing to do on upgrade is a similar thing that "make installkernel" does to move /boot/kernel to /boot/kernel.old and update some sysctl values to tell the system that's the booted kernel. This way /boot/kernel will be exactly the current kernel no more no less. additionally, /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. /usr/libexec has some older files too. Can these outdated files just be deleted? Seems like they are not used at all. On a normal freebsd install I'd just delete any non- updated files like these. The only risk with deleting old libs from /lib or /usr/lib is that some older packages may be linked against older libc's. smime.p7s Description: S/MIME cryptographic signature
Re: [pfSense Support] ipsec issues
Yep, that's exactly what is going on. Just delete the old kernel file and install the new firmware. In terms of the older files elsewhere, I'd play it safe and not touch them for the time being. If you're really concerned with stale files, a reinstall is the correct answer. Scott On 12/15/05, Vivek Khera <[EMAIL PROTECTED]> wrote: > On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: > > > Somethings not correct here. We are well past RC1. > > inneresting... my 0.96.2 upgraded box also has the same uname -a output. > > A bunch of modules in /boot/kernel are dated december 11, but the > kernel file and a bunch of other modules are dated october 22... > > OH I see it. We now install /boot/kernel.gz (dated december > 11) but the loader is picking up the older uncompressed version. > Looks like the upgrade should delete the older kernel... > > I suspect the right thing to do on upgrade is a similar thing that > "make installkernel" does to move /boot/kernel to /boot/kernel.old > and update some sysctl values to tell the system that's the booted > kernel. This way /boot/kernel will be exactly the current kernel no > more no less. > > > > additionally, > > /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. > /usr/libexec has some older files too. > > Can these outdated files just be deleted? Seems like they are not > used at all. On a normal freebsd install I'd just delete any non- > updated files like these. > > The only risk with deleting old libs from /lib or /usr/lib is that > some older packages may be linked against older libc's. > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
Funny well at least we are getting to the bottom of it. So reinstall fresh seems to be the answer -Original Message- From: Vivek Khera [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 19:44 To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: > Somethings not correct here. We are well past RC1. inneresting... my 0.96.2 upgraded box also has the same uname -a output. A bunch of modules in /boot/kernel are dated december 11, but the kernel file and a bunch of other modules are dated october 22... OH I see it. We now install /boot/kernel.gz (dated december 11) but the loader is picking up the older uncompressed version. Looks like the upgrade should delete the older kernel... I suspect the right thing to do on upgrade is a similar thing that "make installkernel" does to move /boot/kernel to /boot/kernel.old and update some sysctl values to tell the system that's the booted kernel. This way /boot/kernel will be exactly the current kernel no more no less. additionally, /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. /usr/libexec has some older files too. Can these outdated files just be deleted? Seems like they are not used at all. On a normal freebsd install I'd just delete any non- updated files like these. The only risk with deleting old libs from /lib or /usr/lib is that some older packages may be linked against older libc's. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
Either that or delete the files in /boot/kernel/* and upgrade the firmware. On 12/15/05, alan walters <[EMAIL PROTECTED]> wrote: > Funny well at least we are getting to the bottom of it. So reinstall > fresh seems to be the answer > > -Original Message- > From: Vivek Khera [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 19:44 > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: > > > Somethings not correct here. We are well past RC1. > > inneresting... my 0.96.2 upgraded box also has the same uname -a output. > > A bunch of modules in /boot/kernel are dated december 11, but the kernel > file and a bunch of other modules are dated october 22... > > OH I see it. We now install /boot/kernel.gz (dated december > 11) but the loader is picking up the older uncompressed version. > Looks like the upgrade should delete the older kernel... > > I suspect the right thing to do on upgrade is a similar thing that "make > installkernel" does to move /boot/kernel to /boot/kernel.old and update > some sysctl values to tell the system that's the booted kernel. This > way /boot/kernel will be exactly the current kernel no more no less. > > > > additionally, > > /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. > /usr/libexec has some older files too. > > Can these outdated files just be deleted? Seems like they are not used > at all. On a normal freebsd install I'd just delete any non- updated > files like these. > > The only risk with deleting old libs from /lib or /usr/lib is that some > older packages may be linked against older libc's. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
On Dec 15, 2005, at 2:49 PM, alan walters wrote: Funny well at least we are getting to the bottom of it. So reinstall fresh seems to be the answer all i did was rm `find . \! -newer kernel.gz | grep -v kernel.gz` in / boot/kernel and reboot. done. no need to re-install the whole thing. smime.p7s Description: S/MIME cryptographic signature
Re: [pfSense Support] ipsec issues
On Dec 15, 2005, at 2:49 PM, Scott Ullrich wrote: Either that or delete the files in /boot/kernel/* and upgrade the firmware. so any thought on mimicking the make installkernel tricks of moving / boot/kernel to /boot/kernel.old then installing? this will avoid any stale modules ever happening again. smime.p7s Description: S/MIME cryptographic signature
Re: [pfSense Support] ipsec issues
Not really necessary. This all came about because we redid the builder scripts. I don't forsee this happening again as freesbie2 works very well. On 12/15/05, Vivek Khera <[EMAIL PROTECTED]> wrote: > > On Dec 15, 2005, at 2:49 PM, Scott Ullrich wrote: > > > Either that or delete the files in /boot/kernel/* and upgrade the > > firmware. > > so any thought on mimicking the make installkernel tricks of moving / > boot/kernel to /boot/kernel.old then installing? this will avoid any > stale modules ever happening again. > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
We have identified the issue. Please see the prior responses.On 12/15/05, alan walters <[EMAIL PROTECTED] > wrote: Dec 15 10:25:46 racoon: DEBUG: 15503e09 3081b54d 1820e3e8 3256835b 08100501 9641d697 0044 04909587 3d73d865 12ce65fb 37efe8a3 88e4f114 fcbbd77c 56005075 0623b629 206c7c1b fc84f737 Dec 15 10:25:46 racoon: ERROR: ignore information because ISAKMP-SA has not been established yet. Dec 15 10:25:47 racoon: ERROR: 195.218.118.115 give up to get IPsec-SA due to time up to wait. This is the only snip I could find that looks of interest in the client side log
RE: [pfSense Support] ipsec issues
Is this only required if you upgraded? All my installs were a reflash. Thanks John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 2:45 PM To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues Yep, that's exactly what is going on. Just delete the old kernel file and install the new firmware. In terms of the older files elsewhere, I'd play it safe and not touch them for the time being. If you're really concerned with stale files, a reinstall is the correct answer. Scott On 12/15/05, Vivek Khera <[EMAIL PROTECTED]> wrote: > On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: > > > Somethings not correct here. We are well past RC1. > > inneresting... my 0.96.2 upgraded box also has the same uname -a output. > > A bunch of modules in /boot/kernel are dated december 11, but the > kernel file and a bunch of other modules are dated october 22... > > OH I see it. We now install /boot/kernel.gz (dated december > 11) but the loader is picking up the older uncompressed version. > Looks like the upgrade should delete the older kernel... > > I suspect the right thing to do on upgrade is a similar thing that > "make installkernel" does to move /boot/kernel to /boot/kernel.old > and update some sysctl values to tell the system that's the booted > kernel. This way /boot/kernel will be exactly the current kernel no > more no less. > > > > additionally, > > /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. > /usr/libexec has some older files too. > > Can these outdated files just be deleted? Seems like they are not > used at all. On a normal freebsd install I'd just delete any non- > updated files like these. > > The only risk with deleting old libs from /lib or /usr/lib is that > some older packages may be linked against older libc's. > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec issues
Yep, only from 0.95ish + upgrades. On 12/15/05, John Cianfarani <[EMAIL PROTECTED]> wrote: > Is this only required if you upgraded? > All my installs were a reflash. > > Thanks > John > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 15, 2005 2:45 PM > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Yep, that's exactly what is going on. Just delete the old kernel > file and install the new firmware. > > In terms of the older files elsewhere, I'd play it safe and not touch > them for the time being. > > If you're really concerned with stale files, a reinstall is the correct > answer. > > Scott > > On 12/15/05, Vivek Khera <[EMAIL PROTECTED]> wrote: > > On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: > > > > > Somethings not correct here. We are well past RC1. > > > > inneresting... my 0.96.2 upgraded box also has the same uname -a > output. > > > > A bunch of modules in /boot/kernel are dated december 11, but the > > kernel file and a bunch of other modules are dated october 22... > > > > OH I see it. We now install /boot/kernel.gz (dated december > > 11) but the loader is picking up the older uncompressed version. > > Looks like the upgrade should delete the older kernel... > > > > I suspect the right thing to do on upgrade is a similar thing that > > "make installkernel" does to move /boot/kernel to /boot/kernel.old > > and update some sysctl values to tell the system that's the booted > > kernel. This way /boot/kernel will be exactly the current kernel no > > more no less. > > > > > > > > additionally, > > > > /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. > > /usr/libexec has some older files too. > > > > Can these outdated files just be deleted? Seems like they are not > > used at all. On a normal freebsd install I'd just delete any non- > > updated files like these. > > > > The only risk with deleting old libs from /lib or /usr/lib is that > > some older packages may be linked against older libc's. > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
This is very strange. Gar... it seems like my issue is still different than this other one. Since with my mobile client side I'm running 96.2, and the kernel.gz is dated Dec12. Not sure what else to try but to reflash both boxes. Thanks John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 5:26 PM To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues Yep, only from 0.95ish + upgrades. On 12/15/05, John Cianfarani <[EMAIL PROTECTED]> wrote: > Is this only required if you upgraded? > All my installs were a reflash. > > Thanks > John > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 15, 2005 2:45 PM > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Yep, that's exactly what is going on. Just delete the old kernel > file and install the new firmware. > > In terms of the older files elsewhere, I'd play it safe and not touch > them for the time being. > > If you're really concerned with stale files, a reinstall is the correct > answer. > > Scott > > On 12/15/05, Vivek Khera <[EMAIL PROTECTED]> wrote: > > On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: > > > > > Somethings not correct here. We are well past RC1. > > > > inneresting... my 0.96.2 upgraded box also has the same uname -a > output. > > > > A bunch of modules in /boot/kernel are dated december 11, but the > > kernel file and a bunch of other modules are dated october 22... > > > > OH I see it. We now install /boot/kernel.gz (dated december > > 11) but the loader is picking up the older uncompressed version. > > Looks like the upgrade should delete the older kernel... > > > > I suspect the right thing to do on upgrade is a similar thing that > > "make installkernel" does to move /boot/kernel to /boot/kernel.old > > and update some sysctl values to tell the system that's the booted > > kernel. This way /boot/kernel will be exactly the current kernel no > > more no less. > > > > > > > > additionally, > > > > /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. > > /usr/libexec has some older files too. > > > > Can these outdated files just be deleted? Seems like they are not > > used at all. On a normal freebsd install I'd just delete any non- > > updated files like these. > > > > The only risk with deleting old libs from /lib or /usr/lib is that > > some older packages may be linked against older libc's. > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec issues
I agree that even after the kernel there is still an issue here as well. I think that there is a versioning issue with ipsec or something else odd that we cant see. I hope to get time to look at it tomorrow -Original Message- From: John Cianfarani [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 10:39 PM To: support@pfsense.com Subject: RE: [pfSense Support] ipsec issues This is very strange. Gar... it seems like my issue is still different than this other one. Since with my mobile client side I'm running 96.2, and the kernel.gz is dated Dec12. Not sure what else to try but to reflash both boxes. Thanks John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 5:26 PM To: support@pfsense.com Subject: Re: [pfSense Support] ipsec issues Yep, only from 0.95ish + upgrades. On 12/15/05, John Cianfarani <[EMAIL PROTECTED]> wrote: > Is this only required if you upgraded? > All my installs were a reflash. > > Thanks > John > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 15, 2005 2:45 PM > To: support@pfsense.com > Subject: Re: [pfSense Support] ipsec issues > > Yep, that's exactly what is going on. Just delete the old kernel > file and install the new firmware. > > In terms of the older files elsewhere, I'd play it safe and not touch > them for the time being. > > If you're really concerned with stale files, a reinstall is the correct > answer. > > Scott > > On 12/15/05, Vivek Khera <[EMAIL PROTECTED]> wrote: > > On Dec 15, 2005, at 1:29 PM, Scott Ullrich wrote: > > > > > Somethings not correct here. We are well past RC1. > > > > inneresting... my 0.96.2 upgraded box also has the same uname -a > output. > > > > A bunch of modules in /boot/kernel are dated december 11, but the > > kernel file and a bunch of other modules are dated october 22... > > > > OH I see it. We now install /boot/kernel.gz (dated december > > 11) but the loader is picking up the older uncompressed version. > > Looks like the upgrade should delete the older kernel... > > > > I suspect the right thing to do on upgrade is a similar thing that > > "make installkernel" does to move /boot/kernel to /boot/kernel.old > > and update some sysctl values to tell the system that's the booted > > kernel. This way /boot/kernel will be exactly the current kernel no > > more no less. > > > > > > > > additionally, > > > > /usr/bin has some october 22 dated files: yp*, usb*, dig, and host. > > /usr/libexec has some older files too. > > > > Can these outdated files just be deleted? Seems like they are not > > used at all. On a normal freebsd install I'd just delete any non- > > updated files like these. > > > > The only risk with deleting old libs from /lib or /usr/lib is that > > some older packages may be linked against older libc's. > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec Problems
We are waiting for 0.6.5 of IPSEC-Tools due to a bug. Is this the same? http://article.gmane.org/gmane.comp.security.firewalls.m0n0wall/23905 Scott On 1/16/06, Pedro Paulo de Magalhaes Oliveira Junior <[EMAIL PROTECTED]> wrote: > We are facing the same problem. > > And it also happen with non mobile. > > -Mensagem original- > De: John Cianfarani [mailto:[EMAIL PROTECTED] > Enviada em: segunda-feira, 16 de janeiro de 2006 13:58 > Para: support@pfsense.com > Assunto: [pfSense Support] IPSec Problems > > Hey All, > > I have been having some problems again with some of the Mobile Client > IPSec. Not sure if there is any changes/improvements in Beta 2. (All > sites are running Beta 1) > Here is the issue I've been having, Ipsec tunnels seem to bounce quite > frequently while this could be caused by many issues it seems that > sometimes when the tunnel goes down it just won't come back up. > > Setup is a remote-pf site which is the mobile client and the central-pf > host site that has a carp address which is the where the remote site > builds the tunnel to. > I haven't isolated which one the problem is with. When the tunnel gets > in this state I try to do the sourced ping from the remote-pf I also > have tried to restart the box and the tunnel will still not build. (See > below for the ipsec.log after a reboot and a test ping). If I check the > ipsec.log on the central-pf it is empty, as if there was either no > attempt. If I nmap both hosts it shows "500/udp open|filtered isakmp" so > it looks like its bound correctly > > Now just for testing while it is in this state I can build a regular > tunnel on the central-pf to the dynamic ip of the remote site and ping > and the tunnel will come up right away. > > Anything to check or try would be appreciated. > > Thanks > John Cianfarani > > > Log from remote-pf after a reload and ping -c 10 -S LANIP > REMOTELANIP > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > (http://ipsec-tools.sourceforge.net) > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)This product linked OpenSSL > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > Jan 16 10:15:17 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as isakmp > port (fd=8) > Jan 16 10:15:17 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > (fd=9) > Jan 16 10:15:17 gw-remote1 racoon: INFO: 127.0.0.1[500] used as isakmp > port (fd=10) > Jan 16 10:15:17 gw-remote1 racoon: INFO: re.mo.te.ip[500] used as isakmp > port (fd=11) > Jan 16 10:15:17 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c6%sis2[500] used as isakmp port (fd=12) > Jan 16 10:15:17 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c5%sis1[500] used as isakmp port (fd=13) > Jan 16 10:15:17 gw-remote1 racoon: INFO: 192.168.0.1[500] used as isakmp > port (fd=14) > Jan 16 10:15:17 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c4%sis0[500] used as isakmp port (fd=15) > Jan 16 10:15:17 gw-remote1 racoon: INFO: 172.16.10.1[500] used as isakmp > port (fd=16) > Jan 16 10:15:18 gw-remote1 racoon: INFO: caught signal 15 > Jan 16 10:15:19 gw-remote1 racoon: INFO: racoon shutdown > Jan 16 10:15:20 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > (http://ipsec-tools.sourceforge.net) > Jan 16 10:15:20 gw-remote1 racoon: INFO: @(#)This product linked OpenSSL > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > Jan 16 10:15:21 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as isakmp > port (fd=7) > Jan 16 10:15:21 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > (fd=8) > Jan 16 10:15:21 gw-remote1 racoon: INFO: 127.0.0.1[500] used as isakmp > port (fd=9) > Jan 16 10:15:21 gw-remote1 racoon: INFO: re.mo.te.ip[500] used as isakmp > port (fd=10) > Jan 16 10:15:21 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c6%sis2[500] used as isakmp port (fd=11) > Jan 16 10:15:21 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c5%sis1[500] used as isakmp port (fd=12) > Jan 16 10:15:21 gw-remote1 racoon: INFO: 192.168.0.1[500] used as isakmp > port (fd=13) > Jan 16 10:15:21 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c4%sis0[500] used as isakmp port (fd=14) > Jan 16 10:15:21 gw-remote1 racoon: INFO: 172.16.10.1[500] used as isakmp > port (fd=15) > Jan 16 10:15:21 gw-remote1 racoon: ERROR: such policy already exists. > anyway replace it: 172.16.10.0/24[0] 172.16.10.1/32[0] proto=any dir=in > Jan 16 10:15:21 gw-remote1 racoon: ERROR: such policy already exists. > anyway replace it: 172.16.0.0/24[0] 172.16.10.0/24[0] proto=any dir=in > Jan 16 10:15:21 gw-remote1 racoon: ERROR: such policy already exists. > anyway replace it: 172.16.10.1/32[0] 172.16.10.0/24[0] proto=any dir=out > Jan 16 10:15:21 gw-remote1 racoon: ERROR: such policy already exists. > anyway replace it: 172.16.10.0/24[0] 172.16.0.0/24[0] proto=any dir=out > Jan 16 10:16:01 gw-remote1 racoon: INFO: IPsec-SA request for > ce.nt.ral.ip queued due to no phase1 found. > Jan 16 10:16:01 gw-remote1 racoon: INFO: initiate new phase 1 > negotiation: re.mo.te.ip[500]<=>ce.nt.ral.ip[50
RE: [pfSense Support] IPSec Problems
>From the looks of it I don't know if it's exactly related it seems that bug is related to remote address being /32's all of the ones I have are /24's. Strange part is the mobile connection will work part of the time, but when it stops working it just seems to be dead. John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Monday, January 16, 2006 11:07 AM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec Problems We are waiting for 0.6.5 of IPSEC-Tools due to a bug. Is this the same? http://article.gmane.org/gmane.comp.security.firewalls.m0n0wall/23905 Scott On 1/16/06, Pedro Paulo de Magalhaes Oliveira Junior <[EMAIL PROTECTED]> wrote: > We are facing the same problem. > > And it also happen with non mobile. > > -Mensagem original- > De: John Cianfarani [mailto:[EMAIL PROTECTED] > Enviada em: segunda-feira, 16 de janeiro de 2006 13:58 > Para: support@pfsense.com > Assunto: [pfSense Support] IPSec Problems > > Hey All, > > I have been having some problems again with some of the Mobile Client > IPSec. Not sure if there is any changes/improvements in Beta 2. (All > sites are running Beta 1) > Here is the issue I've been having, Ipsec tunnels seem to bounce quite > frequently while this could be caused by many issues it seems that > sometimes when the tunnel goes down it just won't come back up. > > Setup is a remote-pf site which is the mobile client and the central-pf > host site that has a carp address which is the where the remote site > builds the tunnel to. > I haven't isolated which one the problem is with. When the tunnel gets > in this state I try to do the sourced ping from the remote-pf I also > have tried to restart the box and the tunnel will still not build. (See > below for the ipsec.log after a reboot and a test ping). If I check the > ipsec.log on the central-pf it is empty, as if there was either no > attempt. If I nmap both hosts it shows "500/udp open|filtered isakmp" so > it looks like its bound correctly > > Now just for testing while it is in this state I can build a regular > tunnel on the central-pf to the dynamic ip of the remote site and ping > and the tunnel will come up right away. > > Anything to check or try would be appreciated. > > Thanks > John Cianfarani > > > Log from remote-pf after a reload and ping -c 10 -S LANIP > REMOTELANIP > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > (http://ipsec-tools.sourceforge.net) > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)This product linked OpenSSL > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > Jan 16 10:15:17 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as isakmp > port (fd=8) > Jan 16 10:15:17 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > (fd=9) > Jan 16 10:15:17 gw-remote1 racoon: INFO: 127.0.0.1[500] used as isakmp > port (fd=10) > Jan 16 10:15:17 gw-remote1 racoon: INFO: re.mo.te.ip[500] used as isakmp > port (fd=11) > Jan 16 10:15:17 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c6%sis2[500] used as isakmp port (fd=12) > Jan 16 10:15:17 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c5%sis1[500] used as isakmp port (fd=13) > Jan 16 10:15:17 gw-remote1 racoon: INFO: 192.168.0.1[500] used as isakmp > port (fd=14) > Jan 16 10:15:17 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c4%sis0[500] used as isakmp port (fd=15) > Jan 16 10:15:17 gw-remote1 racoon: INFO: 172.16.10.1[500] used as isakmp > port (fd=16) > Jan 16 10:15:18 gw-remote1 racoon: INFO: caught signal 15 > Jan 16 10:15:19 gw-remote1 racoon: INFO: racoon shutdown > Jan 16 10:15:20 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > (http://ipsec-tools.sourceforge.net) > Jan 16 10:15:20 gw-remote1 racoon: INFO: @(#)This product linked OpenSSL > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > Jan 16 10:15:21 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as isakmp > port (fd=7) > Jan 16 10:15:21 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > (fd=8) > Jan 16 10:15:21 gw-remote1 racoon: INFO: 127.0.0.1[500] used as isakmp > port (fd=9) > Jan 16 10:15:21 gw-remote1 racoon: INFO: re.mo.te.ip[500] used as isakmp > port (fd=10) > Jan 16 10:15:21 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c6%sis2[500] used as isakmp port (fd=11) > Jan 16 10:15:21 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c5%sis1[500] used as isakmp port (fd=12) > Jan 16 10:15:21 gw-remote1 racoon: INFO: 192.168.0.1[500] used as isakmp > port (fd=13) > Jan 16 10:15:21 gw-remote1 racoon: INFO: > fe80::20d:b9ff:fe02:c6c4%sis0[500] used as isakmp port (fd=14) > Jan 16 10:15:21 gw-remote1 racoon: INFO: 172.16.10.1[500] used as isakmp > port (fd=15) > Jan 16 10:15:21
Re: [pfSense Support] IPSec Problems
Okay, if for some reason 0.6.5 is not out by the time we go to release I'll back down to 0.6.2. Scott On 1/16/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > From the looks of it I don't know if it's exactly related it seems that > bug is related to remote address being /32's all of the ones I have are > /24's. > > Strange part is the mobile connection will work part of the time, but > when it stops working it just seems to be dead. > > John > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: Monday, January 16, 2006 11:07 AM > To: support@pfsense.com > Subject: Re: [pfSense Support] IPSec Problems > > We are waiting for 0.6.5 of IPSEC-Tools due to a bug. Is this the same? > > http://article.gmane.org/gmane.comp.security.firewalls.m0n0wall/23905 > > Scott > > On 1/16/06, Pedro Paulo de Magalhaes Oliveira Junior > <[EMAIL PROTECTED]> wrote: > > We are facing the same problem. > > > > And it also happen with non mobile. > > > > -Mensagem original- > > De: John Cianfarani [mailto:[EMAIL PROTECTED] > > Enviada em: segunda-feira, 16 de janeiro de 2006 13:58 > > Para: support@pfsense.com > > Assunto: [pfSense Support] IPSec Problems > > > > Hey All, > > > > I have been having some problems again with some of the Mobile Client > > IPSec. Not sure if there is any changes/improvements in Beta 2. (All > > sites are running Beta 1) > > Here is the issue I've been having, Ipsec tunnels seem to bounce quite > > frequently while this could be caused by many issues it seems that > > sometimes when the tunnel goes down it just won't come back up. > > > > Setup is a remote-pf site which is the mobile client and the > central-pf > > host site that has a carp address which is the where the remote site > > builds the tunnel to. > > I haven't isolated which one the problem is with. When the tunnel > gets > > in this state I try to do the sourced ping from the remote-pf I also > > have tried to restart the box and the tunnel will still not build. > (See > > below for the ipsec.log after a reboot and a test ping). If I check > the > > ipsec.log on the central-pf it is empty, as if there was either no > > attempt. If I nmap both hosts it shows "500/udp open|filtered isakmp" > so > > it looks like its bound correctly > > > > Now just for testing while it is in this state I can build a regular > > tunnel on the central-pf to the dynamic ip of the remote site and ping > > and the tunnel will come up right away. > > > > Anything to check or try would be appreciated. > > > > Thanks > > John Cianfarani > > > > > > Log from remote-pf after a reload and ping -c 10 -S LANIP > > REMOTELANIP > > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > > (http://ipsec-tools.sourceforge.net) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)This product linked > OpenSSL > > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as > isakmp > > port (fd=8) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > > (fd=9) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: 127.0.0.1[500] used as isakmp > > port (fd=10) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: re.mo.te.ip[500] used as > isakmp > > port (fd=11) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: > > fe80::20d:b9ff:fe02:c6c6%sis2[500] used as isakmp port (fd=12) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: > > fe80::20d:b9ff:fe02:c6c5%sis1[500] used as isakmp port (fd=13) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: 192.168.0.1[500] used as > isakmp > > port (fd=14) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: > > fe80::20d:b9ff:fe02:c6c4%sis0[500] used as isakmp port (fd=15) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: 172.16.10.1[500] used as > isakmp > > port (fd=16) > > Jan 16 10:15:18 gw-remote1 racoon: INFO: caught signal 15 > > Jan 16 10:15:19 gw-remote1 racoon: INFO: racoon shutdown > > Jan 16 10:15:20 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > > (http://ipsec-tools.sourceforge.net) > > Jan 16 10:15:20 gw-remote1 racoon: INFO: @(#)This product linked > OpenSSL > > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > > Jan 16 10:15:21 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as > isakmp > > port (fd=7) > > Jan 16 10:15:21 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > > (fd=8) > > Jan 16 10:15:21 gw-remote1 racoon: INF
RE: [pfSense Support] IPSec Problems
I have ordered a few more wrap boxes for testing, once they come in maybe later this week (hopefully before I go on vacation) I'll be able to lab this out a little better hopefully to see if I can help pinpoint who is cause of the issue. Is there any way to turn on more debugging for ipsec-tools? Thanks John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Monday, January 16, 2006 11:24 AM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec Problems Okay, if for some reason 0.6.5 is not out by the time we go to release I'll back down to 0.6.2. Scott On 1/16/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > From the looks of it I don't know if it's exactly related it seems that > bug is related to remote address being /32's all of the ones I have are > /24's. > > Strange part is the mobile connection will work part of the time, but > when it stops working it just seems to be dead. > > John > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: Monday, January 16, 2006 11:07 AM > To: support@pfsense.com > Subject: Re: [pfSense Support] IPSec Problems > > We are waiting for 0.6.5 of IPSEC-Tools due to a bug. Is this the same? > > http://article.gmane.org/gmane.comp.security.firewalls.m0n0wall/23905 > > Scott > > On 1/16/06, Pedro Paulo de Magalhaes Oliveira Junior > <[EMAIL PROTECTED]> wrote: > > We are facing the same problem. > > > > And it also happen with non mobile. > > > > -Mensagem original- > > De: John Cianfarani [mailto:[EMAIL PROTECTED] > > Enviada em: segunda-feira, 16 de janeiro de 2006 13:58 > > Para: support@pfsense.com > > Assunto: [pfSense Support] IPSec Problems > > > > Hey All, > > > > I have been having some problems again with some of the Mobile Client > > IPSec. Not sure if there is any changes/improvements in Beta 2. (All > > sites are running Beta 1) > > Here is the issue I've been having, Ipsec tunnels seem to bounce quite > > frequently while this could be caused by many issues it seems that > > sometimes when the tunnel goes down it just won't come back up. > > > > Setup is a remote-pf site which is the mobile client and the > central-pf > > host site that has a carp address which is the where the remote site > > builds the tunnel to. > > I haven't isolated which one the problem is with. When the tunnel > gets > > in this state I try to do the sourced ping from the remote-pf I also > > have tried to restart the box and the tunnel will still not build. > (See > > below for the ipsec.log after a reboot and a test ping). If I check > the > > ipsec.log on the central-pf it is empty, as if there was either no > > attempt. If I nmap both hosts it shows "500/udp open|filtered isakmp" > so > > it looks like its bound correctly > > > > Now just for testing while it is in this state I can build a regular > > tunnel on the central-pf to the dynamic ip of the remote site and ping > > and the tunnel will come up right away. > > > > Anything to check or try would be appreciated. > > > > Thanks > > John Cianfarani > > > > > > Log from remote-pf after a reload and ping -c 10 -S LANIP > > REMOTELANIP > > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > > (http://ipsec-tools.sourceforge.net) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)This product linked > OpenSSL > > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as > isakmp > > port (fd=8) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > > (fd=9) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: 127.0.0.1[500] used as isakmp > > port (fd=10) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: re.mo.te.ip[500] used as > isakmp > > port (fd=11) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: > > fe80::20d:b9ff:fe02:c6c6%sis2[500] used as isakmp port (fd=12) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: > > fe80::20d:b9ff:fe02:c6c5%sis1[500] used as isakmp port (fd=13) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: 192.168.0.1[500] used as > isakmp > > port (fd=14) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: > > fe80::20d:b9ff:fe02:c6c4%sis0[500] used as isakmp port (fd=15) > > Jan 16 10:15:17 gw-remote1 racoon: INFO: 172.16.10.1[500] used as > isakmp > > port (fd=16) > > Jan 16 10:15:18 gw-remote1 racoon: INFO: caught signal 15 > > Jan 16 10:15:19 gw-remote1 racoon: INFO: racoon shutdown > > Jan 16 10:
RE: [pfSense Support] IPSec Problems
When the tunnel is up the traffic is excellent no drops at all. Eg. 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 17.742/22.997/36.222/3.837 ms -Original Message- From: Pedro Paulo de Magalhaes Oliveira Junior [mailto:[EMAIL PROTECTED] Sent: Monday, January 16, 2006 11:28 AM To: support@pfsense.com Subject: RES: [pfSense Support] IPSec Problems My problem is packet loss: C:\Documents and Settings\Administrador>ping -t 192.168.0.252 Sending to 192.168.0.252 with 32 bytes data: Request timeout. Reply from 192.168.0.252: bytes=32 tempo=146ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=72ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=116ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=116ms TTL=126 Request timeout. Request timeout. Reply from 192.168.0.252: bytes=32 tempo=158ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=169ms TTL=126 Request timeout. Request timeout. Reply from 192.168.0.252: bytes=32 tempo=210ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=266ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=63ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=84ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=139ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=131ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=136ms TTL=126 Request timeout. Request timeout. Reply from 192.168.0.252: bytes=32 tempo=234ms TTL=126 Reply from 192.168.0.252: bytes=32 tempo=57ms TTL=126 Request timeout. Request timeout. Reply from 192.168.0.252: bytes=32 tempo=62ms TTL=126 Request timeout. Request timeout. Reply from 192.168.0.252: bytes=32 tempo=84ms TTL=126 Ping to 192.168.0.252: Pacotes: Sent = 28, Received = 17, Lost = 11 (39% loss), Roundtrip: Mínimo = 57ms, Máximo = 266ms, Média = 131ms -Mensagem original- De: John Cianfarani [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 16 de janeiro de 2006 14:21 Para: support@pfsense.com Assunto: RE: [pfSense Support] IPSec Problems >From the looks of it I don't know if it's exactly related it seems that bug is related to remote address being /32's all of the ones I have are /24's. Strange part is the mobile connection will work part of the time, but when it stops working it just seems to be dead. John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Monday, January 16, 2006 11:07 AM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec Problems We are waiting for 0.6.5 of IPSEC-Tools due to a bug. Is this the same? http://article.gmane.org/gmane.comp.security.firewalls.m0n0wall/23905 Scott On 1/16/06, Pedro Paulo de Magalhaes Oliveira Junior <[EMAIL PROTECTED]> wrote: > We are facing the same problem. > > And it also happen with non mobile. > > -Mensagem original- > De: John Cianfarani [mailto:[EMAIL PROTECTED] > Enviada em: segunda-feira, 16 de janeiro de 2006 13:58 > Para: support@pfsense.com > Assunto: [pfSense Support] IPSec Problems > > Hey All, > > I have been having some problems again with some of the Mobile Client > IPSec. Not sure if there is any changes/improvements in Beta 2. (All > sites are running Beta 1) > Here is the issue I've been having, Ipsec tunnels seem to bounce quite > frequently while this could be caused by many issues it seems that > sometimes when the tunnel goes down it just won't come back up. > > Setup is a remote-pf site which is the mobile client and the central-pf > host site that has a carp address which is the where the remote site > builds the tunnel to. > I haven't isolated which one the problem is with. When the tunnel gets > in this state I try to do the sourced ping from the remote-pf I also > have tried to restart the box and the tunnel will still not build. (See > below for the ipsec.log after a reboot and a test ping). If I check the > ipsec.log on the central-pf it is empty, as if there was either no > attempt. If I nmap both hosts it shows "500/udp open|filtered isakmp" so > it looks like its bound correctly > > Now just for testing while it is in this state I can build a regular > tunnel on the central-pf to the dynamic ip of the remote site and ping > and the tunnel will come up right away. > > Anything to check or try would be appreciated. > > Thanks > John Cianfarani > > > Log from remote-pf after a reload and ping -c 10 -S LANIP > REMOTELANIP > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)ipsec-tools 0.6.4 > (http://ipsec-tools.sourceforge.net) > Jan 16 10:15:17 gw-remote1 racoon: INFO: @(#)This product linked OpenSSL > 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) > Jan 16 10:15:17 gw-remote1 racoon: INFO: fe80::1%lo0[500] used as isakmp > port (fd=8) > Jan 16 10:15:17 gw-remote1 racoon: INFO: ::1[500] used as isakmp port > (fd=9) > J
Re: [pfSense Support] IPSec Problems
To increase the logging level, see this commit: http://pfsense.com/cgi-bin/cvsweb.cgi/pfSense/etc/inc/vpn.inc.diff?r1=1.89.2.4;r2=1.89.2.5;only_with_tag=RELENG_1;f=h On 1/16/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > When the tunnel is up the traffic is excellent no drops at all. > > Eg. > 100 packets transmitted, 100 packets received, 0% packet loss > round-trip min/avg/max/stddev = 17.742/22.997/36.222/3.837 ms > > -Original Message- > From: Pedro Paulo de Magalhaes Oliveira Junior [mailto:[EMAIL PROTECTED] > Sent: Monday, January 16, 2006 11:28 AM > To: support@pfsense.com > Subject: RES: [pfSense Support] IPSec Problems > > My problem is packet loss: > > C:\Documents and Settings\Administrador>ping -t 192.168.0.252 > > Sending to 192.168.0.252 with 32 bytes data: > > Request timeout. > Reply from 192.168.0.252: bytes=32 tempo=146ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=72ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=116ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=116ms TTL=126 > Request timeout. > Request timeout. > Reply from 192.168.0.252: bytes=32 tempo=158ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=169ms TTL=126 > Request timeout. > Request timeout. > Reply from 192.168.0.252: bytes=32 tempo=210ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=266ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=63ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=84ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=139ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=131ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=136ms TTL=126 > Request timeout. > Request timeout. > Reply from 192.168.0.252: bytes=32 tempo=234ms TTL=126 > Reply from 192.168.0.252: bytes=32 tempo=57ms TTL=126 > Request timeout. > Request timeout. > Reply from 192.168.0.252: bytes=32 tempo=62ms TTL=126 > Request timeout. > Request timeout. > Reply from 192.168.0.252: bytes=32 tempo=84ms TTL=126 > > Ping to 192.168.0.252: > Pacotes: Sent = 28, Received = 17, Lost = 11 (39% loss), > Roundtrip: > Mínimo = 57ms, Máximo = 266ms, Média = 131ms > > > -----Mensagem original- > De: John Cianfarani [mailto:[EMAIL PROTECTED] > Enviada em: segunda-feira, 16 de janeiro de 2006 14:21 > Para: support@pfsense.com > Assunto: RE: [pfSense Support] IPSec Problems > > From the looks of it I don't know if it's exactly related it seems that > bug is related to remote address being /32's all of the ones I have are > /24's. > > Strange part is the mobile connection will work part of the time, but > when it stops working it just seems to be dead. > > John > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: Monday, January 16, 2006 11:07 AM > To: support@pfsense.com > Subject: Re: [pfSense Support] IPSec Problems > > We are waiting for 0.6.5 of IPSEC-Tools due to a bug. Is this the same? > > http://article.gmane.org/gmane.comp.security.firewalls.m0n0wall/23905 > > Scott > > On 1/16/06, Pedro Paulo de Magalhaes Oliveira Junior > <[EMAIL PROTECTED]> wrote: > > We are facing the same problem. > > > > And it also happen with non mobile. > > > > -Mensagem original- > > De: John Cianfarani [mailto:[EMAIL PROTECTED] > > Enviada em: segunda-feira, 16 de janeiro de 2006 13:58 > > Para: support@pfsense.com > > Assunto: [pfSense Support] IPSec Problems > > > > Hey All, > > > > I have been having some problems again with some of the Mobile Client > > IPSec. Not sure if there is any changes/improvements in Beta 2. (All > > sites are running Beta 1) > > Here is the issue I've been having, Ipsec tunnels seem to bounce quite > > frequently while this could be caused by many issues it seems that > > sometimes when the tunnel goes down it just won't come back up. > > > > Setup is a remote-pf site which is the mobile client and the > central-pf > > host site that has a carp address which is the where the remote site > > builds the tunnel to. > > I haven't isolated which one the problem is with. When the tunnel > gets > > in this state I try to do the sourced ping from the remote-pf I also > > have tried to restart the box and the tunnel will still not build. > (See > > below for the ipsec.log after a reboot and a test ping). If I check > the > > ipsec.log on the central-pf it is empty, as if there was either no > > attempt. If I nmap both hosts it shows "500/udp open|filtered isakmp" > so > > it looks like its bound correctly > > > > Now just for testing
Re: [pfSense Support] IPSec Testing
Not sure if you've tried this, if it'll make a difference, or what exactly it'll do, but try "Prefer old IPsec SAs" in System->Advanced I'm having no problems with my tunnels, pfsense-pfsense and pfsense-nortel contivity, but they're both network tunnel configs with static IPs, not road warrior. --Bill On 2/19/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > > > > Been doing some testing the last little bit to try to nail down what it > isn't working right with IPSec tunnels and I just wanted to give an update > and maybe get some suggestions on what to try next. > > > > I've moved one of the pfsense boxes (running Beta1 Snapshot 2-2-06) into a > colo location to confirm that the internet was not the issue. > > The Colo pfsense is setup for mobile clients and I have 2 boxes (at 2 > different locations) acting as remote client. > > > > One of the clients is another pfsense box running Beta1 and the other is a > Cisco Pix. > > > > Both boxes connect and establish their tunnels (and renegotiate as lifetimes > expires tested over 2-3 days) though after a simulated power outage with the > Cisco Pix it is never able to reconnect after that point. > > The next day the remote pfsense then no longer is able to connect. Trying to > disable/enable ipsec on the colo pfsense seems to have no limited to no > effect. (sometimes it works sometimes it doesn't) > > > > Both remote boxes seem to complain about retransmitting of phase 1 so it > doesn't even seem like IKE listening anymore, even though a netstat shows > it's running. The colo pfsense also doesn't show any log entries while the > box is retrying (even with the extended debug on for raccoon). > > > > My thought at the moment is that somehow the colo pfsense doesn't think the > tunnel has ever gone down and maybe treats the new isakmp requests > differently. > > > > This is what I'm thinking for next tests: > > 1. My thoughts for the next tests are to try to use the pix as the central > site and to try to get pfsense to connect into it. > > 2. Other though is to go back and try 94.x 95.x with ipsec-tools 6.2 to see > if I can replicate it there. > > 3. Try to use the developer ed. and build with ipsec-tools 6.2 > > > > > > Thanks > > John > > > > Here are some logs as well. > > > > z.z.z.z is colo pfsense > > a.a.a.a is remote pfsense > > b.b.b.b is cisco pix > > > > -- Colo Pfsense - netstat -- > > Active Internet connections > > Proto Recv-Q Send-Q Local Address Foreign Address(state) > > udp4 0 0 gw-central2.isakmp *.* > > udp4 0 0 192.168.1.2.isakmp *.* > > udp4 0 0 z.z.z.z.isakmp *.* > > udp4 0 0 localhost.isakmp *.* > > > > > > -- remote pfsense - ipsec log --- > > Feb 19 20:58:00racoon: INFO: initiate new phase 1 negotiation: > a.a.a.a[500]<=>z.z.z.z[500] > > Feb 19 20:58:00racoon: INFO: begin Aggressive mode. > > Feb 19 20:58:31racoon: ERROR: phase2 negotiation failed due to > time up waiting for phase1. ESP z.z.z.z[0]->a.a.a.a[0] > > Feb 19 20:58:31racoon: INFO: delete phase 2 handler. > > Feb 19 20:59:00racoon: INFO: request for establishing IPsec-SA > was queued due to no phase1 found. > > > > > > --- remote cisco pix debug -- > > > > ISAKMP (0): ID payload > > next-payload : 13 > > type : 11 > > protocol : 17 > > port : 500 > > length : 28 > > ISAKMP (0): Total payload length: 32 > > ISAKMP (0): beginning Aggressive Mode exchange > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): deleting SA: src b.b.b.b, dst z.z.z.z > > ISADB: reaper checking SA 0x9e66ec, conn_id = 0 DELETE IT! > > > > VPN Peer:ISAKMP: Peer Info for z.z.z.z/500 not found - peers:0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] IPSec Testing
Hmm somehow I never noticed that option. I will give it a try. Though I must admit I'm a bit confused on what it does. Thanks John -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Sunday, February 19, 2006 10:03 PM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec Testing Not sure if you've tried this, if it'll make a difference, or what exactly it'll do, but try "Prefer old IPsec SAs" in System->Advanced I'm having no problems with my tunnels, pfsense-pfsense and pfsense-nortel contivity, but they're both network tunnel configs with static IPs, not road warrior. --Bill On 2/19/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > > > > Been doing some testing the last little bit to try to nail down what it > isn't working right with IPSec tunnels and I just wanted to give an update > and maybe get some suggestions on what to try next. > > > > I've moved one of the pfsense boxes (running Beta1 Snapshot 2-2-06) into a > colo location to confirm that the internet was not the issue. > > The Colo pfsense is setup for mobile clients and I have 2 boxes (at 2 > different locations) acting as remote client. > > > > One of the clients is another pfsense box running Beta1 and the other is a > Cisco Pix. > > > > Both boxes connect and establish their tunnels (and renegotiate as lifetimes > expires tested over 2-3 days) though after a simulated power outage with the > Cisco Pix it is never able to reconnect after that point. > > The next day the remote pfsense then no longer is able to connect. Trying to > disable/enable ipsec on the colo pfsense seems to have no limited to no > effect. (sometimes it works sometimes it doesn't) > > > > Both remote boxes seem to complain about retransmitting of phase 1 so it > doesn't even seem like IKE listening anymore, even though a netstat shows > it's running. The colo pfsense also doesn't show any log entries while the > box is retrying (even with the extended debug on for raccoon). > > > > My thought at the moment is that somehow the colo pfsense doesn't think the > tunnel has ever gone down and maybe treats the new isakmp requests > differently. > > > > This is what I'm thinking for next tests: > > 1. My thoughts for the next tests are to try to use the pix as the central > site and to try to get pfsense to connect into it. > > 2. Other though is to go back and try 94.x 95.x with ipsec-tools 6.2 to see > if I can replicate it there. > > 3. Try to use the developer ed. and build with ipsec-tools 6.2 > > > > > > Thanks > > John > > > > Here are some logs as well. > > > > z.z.z.z is colo pfsense > > a.a.a.a is remote pfsense > > b.b.b.b is cisco pix > > > > -- Colo Pfsense - netstat -- > > Active Internet connections > > Proto Recv-Q Send-Q Local Address Foreign Address (state) > > udp4 0 0 gw-central2.isakmp *.* > > udp4 0 0 192.168.1.2.isakmp *.* > > udp4 0 0 z.z.z.z.isakmp *.* > > udp4 0 0 localhost.isakmp *.* > > > > > > -- remote pfsense - ipsec log --- > > Feb 19 20:58:00racoon: INFO: initiate new phase 1 negotiation: > a.a.a.a[500]<=>z.z.z.z[500] > > Feb 19 20:58:00racoon: INFO: begin Aggressive mode. > > Feb 19 20:58:31racoon: ERROR: phase2 negotiation failed due to > time up waiting for phase1. ESP z.z.z.z[0]->a.a.a.a[0] > > Feb 19 20:58:31racoon: INFO: delete phase 2 handler. > > Feb 19 20:59:00racoon: INFO: request for establishing IPsec-SA > was queued due to no phase1 found. > > > > > > --- remote cisco pix debug -- > > > > ISAKMP (0): ID payload > > next-payload : 13 > > type : 11 > > protocol : 17 > > port : 500 > > length : 28 > > ISAKMP (0): Total payload length: 32 > > ISAKMP (0): beginning Aggressive Mode exchange > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): deleting SA: src b.b.b.b, dst z.z.z.z > > ISADB: reaper checking SA 0x9e66ec, conn_id = 0 DELETE IT! > > > > VPN Peer:ISAKMP: Peer Info for z.z.z.z/500 not found - peers:0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] IPSec Testing
Holy crap Batman! This might have fixed it. Did a little bit of testing only with the pix as the remote client it comes up after simulated power outages and builds the tunnel again without issue. Tested with long/short SA see how it reacts if SAs are expired and it still comes up. It actually seems pretty stable actually and pretty tough to make the tunnel fail now. Will continue doing some testing to confirm. Thanks for the tip! John -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Sunday, February 19, 2006 10:03 PM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec Testing Not sure if you've tried this, if it'll make a difference, or what exactly it'll do, but try "Prefer old IPsec SAs" in System->Advanced I'm having no problems with my tunnels, pfsense-pfsense and pfsense-nortel contivity, but they're both network tunnel configs with static IPs, not road warrior. --Bill On 2/19/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > > > > Been doing some testing the last little bit to try to nail down what it > isn't working right with IPSec tunnels and I just wanted to give an update > and maybe get some suggestions on what to try next. > > > > I've moved one of the pfsense boxes (running Beta1 Snapshot 2-2-06) into a > colo location to confirm that the internet was not the issue. > > The Colo pfsense is setup for mobile clients and I have 2 boxes (at 2 > different locations) acting as remote client. > > > > One of the clients is another pfsense box running Beta1 and the other is a > Cisco Pix. > > > > Both boxes connect and establish their tunnels (and renegotiate as lifetimes > expires tested over 2-3 days) though after a simulated power outage with the > Cisco Pix it is never able to reconnect after that point. > > The next day the remote pfsense then no longer is able to connect. Trying to > disable/enable ipsec on the colo pfsense seems to have no limited to no > effect. (sometimes it works sometimes it doesn't) > > > > Both remote boxes seem to complain about retransmitting of phase 1 so it > doesn't even seem like IKE listening anymore, even though a netstat shows > it's running. The colo pfsense also doesn't show any log entries while the > box is retrying (even with the extended debug on for raccoon). > > > > My thought at the moment is that somehow the colo pfsense doesn't think the > tunnel has ever gone down and maybe treats the new isakmp requests > differently. > > > > This is what I'm thinking for next tests: > > 1. My thoughts for the next tests are to try to use the pix as the central > site and to try to get pfsense to connect into it. > > 2. Other though is to go back and try 94.x 95.x with ipsec-tools 6.2 to see > if I can replicate it there. > > 3. Try to use the developer ed. and build with ipsec-tools 6.2 > > > > > > Thanks > > John > > > > Here are some logs as well. > > > > z.z.z.z is colo pfsense > > a.a.a.a is remote pfsense > > b.b.b.b is cisco pix > > > > -- Colo Pfsense - netstat -- > > Active Internet connections > > Proto Recv-Q Send-Q Local Address Foreign Address (state) > > udp4 0 0 gw-central2.isakmp *.* > > udp4 0 0 192.168.1.2.isakmp *.* > > udp4 0 0 z.z.z.z.isakmp *.* > > udp4 0 0 localhost.isakmp *.* > > > > > > -- remote pfsense - ipsec log --- > > Feb 19 20:58:00racoon: INFO: initiate new phase 1 negotiation: > a.a.a.a[500]<=>z.z.z.z[500] > > Feb 19 20:58:00racoon: INFO: begin Aggressive mode. > > Feb 19 20:58:31racoon: ERROR: phase2 negotiation failed due to > time up waiting for phase1. ESP z.z.z.z[0]->a.a.a.a[0] > > Feb 19 20:58:31racoon: INFO: delete phase 2 handler. > > Feb 19 20:59:00racoon: INFO: request for establishing IPsec-SA > was queued due to no phase1 found. > > > > > > --- remote cisco pix debug -- > > > > ISAKMP (0): ID payload > > next-payload : 13 > > type : 11 > > protocol : 17 > > port : 500 > > length : 28 > > ISAKMP (0): Total payload length: 32 > > ISAKMP (0): beginning Aggressive Mode exchange > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): deleting SA: src b.b.b.b, dst z.z.z.z > > ISADB: reaper checking SA 0x9e66ec, conn_id = 0 DELETE IT! > > > > VPN Peer:ISAKMP: Peer Info for z.z.z.z/500 not found - peers:0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec Testing
On 2/20/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > Holy crap Batman! This might have fixed it. > Did a little bit of testing only with the pix as the remote client it > comes up after simulated power outages and builds the tunnel again > without issue. > Tested with long/short SA see how it reacts if SAs are expired and it > still comes up. > It actually seems pretty stable actually and pretty tough to make the > tunnel fail now. Good to hear. I just did a little research on that option...surprisingly it does the opposite of what I'd expect it to do. Setting preferred old sa in the web gui, sets the kernel sysctl net.key.preferred_oldsa=0, which means it prefers NEW SA's (which is a good thing). We'll kick it around and see what the best thing to do here is. > Will continue doing some testing to confirm. > > Thanks for the tip! No problem, glad that helped. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] IPSec Testing
That's pretty interesting and the best I could come up with is that it would try to renegotiate an old SA. I would think the default should be to accept any new SA as normally you would want your newest one. Thanks John -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 11:45 AM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec Testing On 2/20/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > Holy crap Batman! This might have fixed it. > Did a little bit of testing only with the pix as the remote client it > comes up after simulated power outages and builds the tunnel again > without issue. > Tested with long/short SA see how it reacts if SAs are expired and it > still comes up. > It actually seems pretty stable actually and pretty tough to make the > tunnel fail now. Good to hear. I just did a little research on that option...surprisingly it does the opposite of what I'd expect it to do. Setting preferred old sa in the web gui, sets the kernel sysctl net.key.preferred_oldsa=0, which means it prefers NEW SA's (which is a good thing). We'll kick it around and see what the best thing to do here is. > Will continue doing some testing to confirm. > > Thanks for the tip! No problem, glad that helped. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPsec Failover
The firewall rules to manage IPsec are being based on the (CARP) address entered in the Failover IPsec dialog irrespective of the setting of the Enable checkbox in the Failover IPsec dialog. The only way to stop it doing this has been to remove all the entries. /Peter -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPsec Failover
Not sure what you mean. Can you show me an example of the rule? On 3/18/06, Peter Curran <[EMAIL PROTECTED]> wrote: > The firewall rules to manage IPsec are being based on the (CARP) address > entered in the Failover IPsec dialog irrespective of the setting of the > Enable checkbox in the Failover IPsec dialog. > > The only way to stop it doing this has been to remove all the entries. > > /Peter > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPsec Failover
Scott Let me explain the chain of events... I set up two pfsense boxes as a high-availability pair. They have a number of CARP addresses configured, the ones on the WAN are mostly passed through to the LAN via 1:1 NAT. One single address is used for the logical firewall itself CARP-FW. I tried to setup an IPsec tunnel from a remote box to the LAN network using the CARP-FW address as the tunnel end-point address. I then set this in the Failover IPsec dialog (along with the LAN address of the peer). I saved this config, but the tunnel failed to come up - Phase 1 not completed. I then decided to just setup a tunnel to the real WAN address of one of the firewalls and test this worked OK, then try the CARP approach again. To do this I disabled the Failover IPsec settings via the tickbox and reconfigured the tunnel endpoint address on both systems. No luck with this config so I checked the firewall logs, and sure enough incoming UDP/500 packets are being rejected between the tunnel endpoints. I then used status.php to look at the firewall config 'in the raw' and saw that the rules are like this... pass out quick on em3 proto udp from x.x.x.235 to y.y.y.153 port = 500 keep state label "IPSEC: Close Consultants - outbound isakmp" pass in quick on em3 proto udp from y.y.y.153 to x.x.x.235 port = 500 keep state label "IPSEC: Close Consultants - inbound isakmp" pass out quick on em3 proto esp from x.x.x.235 to y.y.y.153 keep state label "IPSEC: Close Consultants - outbound esp proto" pass in quick on em3 proto esp from y.y.y.153 to x.x.x.235 keep state label "IPSEC: Close Consultants - inbound esp proto" pass out quick on em3 proto ah from x.x.x.235 to y.y.y.153 keep state label "IPSEC: Close Consultants - outbound ah proto" pass in quick on em3 proto ah from y.y.y.153 to x.x.x.235 keep state label "IPSEC: Close Consultants - inbound ah proto" The x.x.x.235 address is the CARP-FW address (supposedly disabled) not the real FW address. I zeroed all the Failover IPsec boxes and saved the config, the tunnel came up immediately and the firewall rules are just fine. This is BETA-2. Incidentally, this is only one of a small plagure of problems with CARP - I am trying to reproduce some of the problens know so I can document them correctly. Cheers /Peter On Saturday 18 March 2006 18:02, Scott Ullrich wrote: > Not sure what you mean. Can you show me an example of the rule? > > On 3/18/06, Peter Curran <[EMAIL PROTECTED]> wrote: > > The firewall rules to manage IPsec are being based on the (CARP) address > > entered in the Failover IPsec dialog irrespective of the setting of the > > Enable checkbox in the Failover IPsec dialog. > > > > The only way to stop it doing this has been to remove all the entries. > > > > /Peter > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPsec Failover
I am running failover ipsec at home and work with no issues. I am using a public IP as one of the carp ips but I am not running a 1:1. I almost wonder if the 1:1 is stepping on the IPSEC connection. On 3/19/06, Peter Curran <[EMAIL PROTECTED]> wrote: > Scott > > Let me explain the chain of events... > > I set up two pfsense boxes as a high-availability pair. They have a number of > CARP addresses configured, the ones on the WAN are mostly passed through to > the LAN via 1:1 NAT. One single address is used for the logical firewall > itself CARP-FW. > > I tried to setup an IPsec tunnel from a remote box to the LAN network using > the CARP-FW address as the tunnel end-point address. I then set this in the > Failover IPsec dialog (along with the LAN address of the peer). I saved this > config, but the tunnel failed to come up - Phase 1 not completed. > > I then decided to just setup a tunnel to the real WAN address of one of the > firewalls and test this worked OK, then try the CARP approach again. To do > this I disabled the Failover IPsec settings via the tickbox and reconfigured > the tunnel endpoint address on both systems. No luck with this config so I > checked the firewall logs, and sure enough incoming UDP/500 packets are being > rejected between the tunnel endpoints. I then used status.php to look at the > firewall config 'in the raw' and saw that the rules are like this... > > pass out quick on em3 proto udp from x.x.x.235 to y.y.y.153 port = 500 keep > state label "IPSEC: Close Consultants - outbound isakmp" > pass in quick on em3 proto udp from y.y.y.153 to x.x.x.235 port = 500 keep > state label "IPSEC: Close Consultants - inbound isakmp" > pass out quick on em3 proto esp from x.x.x.235 to y.y.y.153 keep state label > "IPSEC: Close Consultants - outbound esp proto" > pass in quick on em3 proto esp from y.y.y.153 to x.x.x.235 keep state label > "IPSEC: Close Consultants - inbound esp proto" > pass out quick on em3 proto ah from x.x.x.235 to y.y.y.153 keep state label > "IPSEC: Close Consultants - outbound ah proto" > pass in quick on em3 proto ah from y.y.y.153 to x.x.x.235 keep state label > "IPSEC: Close Consultants - inbound ah proto" > > The x.x.x.235 address is the CARP-FW address (supposedly disabled) not the > real FW address. > > I zeroed all the Failover IPsec boxes and saved the config, the tunnel came up > immediately and the firewall rules are just fine. > > This is BETA-2. > > Incidentally, this is only one of a small plagure of problems with CARP - I am > trying to reproduce some of the problens know so I can document them > correctly. > > Cheers > > /Peter > > On Saturday 18 March 2006 18:02, Scott Ullrich wrote: > > Not sure what you mean. Can you show me an example of the rule? > > > > On 3/18/06, Peter Curran <[EMAIL PROTECTED]> wrote: > > > The firewall rules to manage IPsec are being based on the (CARP) address > > > entered in the Failover IPsec dialog irrespective of the setting of the > > > Enable checkbox in the Failover IPsec dialog. > > > > > > The only way to stop it doing this has been to remove all the entries. > > > > > > /Peter > > > > > > -- > > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPsec Failover
It is possible. Apart from the problem I reported with the wrong addresses in the IPsec-related rules, the rules look fine. I have used CARP and binat rules in a similar way on OpenBSD without problems, so I doubt that it is a pf problem. I have a /29 and the current allocations for public IPs are as follows: x.x.x.233 Router leading to Internet x.x.x.234 FW1 real IP address x.x.x.235 FW2 real IP address x.x.x.236 CARP-FW address x.x.x.237 CARP-SRV1 NAT 1:1 to LAN 192.168.10.1 x.x.x.238 CARP-SRV2 NAT 1:1 to LAN 192.168.10.11 There are 3 local interfaces, each of which has a CARP IP which is the default route for hosts on the appropriate network - so 6 CARP IPs in total. Unfortunately, the kit is in a datacentre in London (120 miles away) and the FW1 (CARP Master) is now in a crash/reboot/crash cycle. This is a CARP related problem as FW1 will start and run stable if FW2 is not online when it starts up. As I can no longer see both systems running simultaneously I will have to wait until I get back to the datacenter to debug further. Only debug clue I have is that I have log entries for a bad hash on carp5 coming up on a regular basis. Also, when I looked at the Status | CARP screen when both systems where last running the info for carp5 was not displaying correctly. (From memory there was no status and the interface name was missing). Sorry to be vague - I hope to be back in London next Wednesday and will try and collect some proper information then. I am not sure if this is a pfSense problem or just a dumb configuration mistake by me. Either way, it would be good to figure out what is going wrong, if only for the FAQ. /Peter On Sunday 19 March 2006 17:47, Scott Ullrich wrote: > I am running failover ipsec at home and work with no issues. I am > using a public IP as one of the carp ips but I am not running a 1:1. > I almost wonder if the 1:1 is stepping on the IPSEC connection. > > On 3/19/06, Peter Curran <[EMAIL PROTECTED]> wrote: > > Scott > > > > Let me explain the chain of events... > > > > I set up two pfsense boxes as a high-availability pair. They have a > > number of CARP addresses configured, the ones on the WAN are mostly > > passed through to the LAN via 1:1 NAT. One single address is used for > > the logical firewall itself CARP-FW. > > > > I tried to setup an IPsec tunnel from a remote box to the LAN network > > using the CARP-FW address as the tunnel end-point address. I then set > > this in the Failover IPsec dialog (along with the LAN address of the > > peer). I saved this config, but the tunnel failed to come up - Phase 1 > > not completed. > > > > I then decided to just setup a tunnel to the real WAN address of one of > > the firewalls and test this worked OK, then try the CARP approach again. > > To do this I disabled the Failover IPsec settings via the tickbox and > > reconfigured the tunnel endpoint address on both systems. No luck with > > this config so I checked the firewall logs, and sure enough incoming > > UDP/500 packets are being rejected between the tunnel endpoints. I then > > used status.php to look at the firewall config 'in the raw' and saw that > > the rules are like this... > > > > pass out quick on em3 proto udp from x.x.x.235 to y.y.y.153 port = 500 > > keep state label "IPSEC: Close Consultants - outbound isakmp" > > pass in quick on em3 proto udp from y.y.y.153 to x.x.x.235 port = 500 > > keep state label "IPSEC: Close Consultants - inbound isakmp" > > pass out quick on em3 proto esp from x.x.x.235 to y.y.y.153 keep state > > label "IPSEC: Close Consultants - outbound esp proto" > > pass in quick on em3 proto esp from y.y.y.153 to x.x.x.235 keep state > > label "IPSEC: Close Consultants - inbound esp proto" > > pass out quick on em3 proto ah from x.x.x.235 to y.y.y.153 keep state > > label "IPSEC: Close Consultants - outbound ah proto" > > pass in quick on em3 proto ah from y.y.y.153 to x.x.x.235 keep state > > label "IPSEC: Close Consultants - inbound ah proto" > > > > The x.x.x.235 address is the CARP-FW address (supposedly disabled) not > > the real FW address. > > > > I zeroed all the Failover IPsec boxes and saved the config, the tunnel > > came up immediately and the firewall rules are just fine. > > > > This is BETA-2. > > > > Incidentally, this is only one of a small plagure of problems with CARP - > > I am trying to reproduce some of the problens know so I can document them > > correctly. > > > > Cheers > > > > /Peter > > > > On Saturday 18 March 2006 18:02, Scott Ullrich wrote: > > > Not sure what you mean. Can you show me an example of the rule? > > > > > > On 3/18/06, Peter Curran <[EMAIL PROTECTED]> wrote: > > > > The firewall rules to manage IPsec are being based on the (CARP) > > > > address entered in the Failover IPsec dialog irrespective of the > > > > setting of the Enable checkbox in the Failover IPsec dialog.
Re: [pfSense Support] IPSEC questions
On 7/12/06, Quirino Santilli <[EMAIL PROTECTED]> wrote: Hi guys, my head is crashing again with the connection problem between my pfSense branch office firewall and my main Microsoft ISA 2004 trough IPSEC. Yesterday in the microsoft docs i found informations about establishing an IPSEC connection between ISA 2004 and smoothwall, a linux based firewall with a Freeswan implementation. The first thing i noticed in this howto is that on the smoothwall side the 'Compression' checkbox in the IPSEC policies is not flagged. In pfSense there are no settings regarding the 3des compression, but debugging pfSense's SA Proposal I noticed the '3des-cbc' value. So the questions are: 1) does pfSense use a compressed 3des ipsec policy? Looks like this is in my racoon.conf: compression_algorithm deflate; 2) is it possible it deactivate it? Not at this time. 3) does pfSense automatically understand that the other side is offering a non compressed 3des policy? Not sure, I think so. You can try removing the compression line from /var/etc/racoon.conf and rerunning racoon with this command pkill - 9 racoon && /usr/local/sbin/racoon -f /var/etc/racoon.conf Use Diagnostics->Edit File and Diagnostics->Command if you aren't comfortable with a unix shell. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC Question
Quirino Santilli wrote: Hi, I searched the internet many times and the I found this http://cvstrac.pfsense.com/chngview?cn=17328 Will it never be added as a default option? I think it is going to solve the pfSense <--> ISA Server 2004/6 IPSEC incompatibility. The diff you pointed to doesn't look complete enough to support compression. When a policy is created, the protocols need to be specified as both ESP|AH+IPCOMP for racoon to generate the appropriate proposals for phase2 negotiation. I am not familiar with the ISA Server product line but I would venture to guess that this will not be the answer to your problem. Vendor implementations of IPCOMP are notoriously incompatible with other implementations. Using it tends to cause more problems than it solves. -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC error
Jaye Mathisen wrote: I'm getting this trying to set up a tunnel between two fixed IP's. Dec 22 22:59:36 ithcprtr1 racoon: INFO: 68.185.9.206[500] used as isakmp port (fd=20) Dec 22 22:59:36 ithcprtr1 racoon: INFO: unsupported PF_KEY message REGISTER racoon.conf looks OK, but I haven't set up IPSEC in ages... IT's kind of just always worked, and I never have to mess with i. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] did you ever fix this? this where my tunnel hangs up -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec woes
On Thu, May 8, 2008 at 1:24 PM, Jure Pečar <[EMAIL PROTECTED]> wrote: > I inherited three pfsense setups at three locations of the same company. > pfSense itself is working perfectly well, only the ipsec is causing the > troubles. What version of pfSense? > office1 to office2: works most of the time, unless when it doesn't - it > goes blank for minutes at a time and then comes back. What do you mean "goes blank"? > office1 to servers: works, but typing 'dmesg' or something else with lots > of output freezes the ssh session over it. It never freezes if left idle. > Sshing to the same machine over public ip does not exhibit this problem. Is there any packet loss on the VPN between office1 and servers? > home to office1: doesn't work at all. Going to need logs. Probably a VPN configuration error with either the remote/local net or VPN ids, or PSK. I would also suggest trying main mode instead of aggressive mode for the negotiation mode. -Dave
Re: [pfSense Support] ipsec woes
On Thu, 8 May 2008 16:23:28 -0700 "David Rees" <[EMAIL PROTECTED]> wrote: > What version of pfSense? 1.2 everywhere. > What do you mean "goes blank"? 100% packet loss. > Going to need logs. Of course. Let's debug one by one. This is office1->office2): on office1 i see: May 9 10:30:20 racoon: [tunel 11 -> 111 mv]: INFO: initiate new phase 2 negotiation: May 9 10:30:20 racoon: [tunel 11 -> 111 mv]: INFO: IPsec-SA established: ESP/Tunnel 84.255.245.212[0]->77.234.135.134[0] spi=143114727(0x887c1e7) May 9 10:30:20 racoon: [tunel 11 -> 111 mv]: INFO: IPsec-SA established: ESP/Tunnel 77.234.135.134[0]->84.255.245.212[0] spi=207960073(0xc653809) May 9 10:30:20 racoon: INFO: purged IPsec-SA proto_id=ESP spi=265358510. May 9 10:30:20 racoon: [tunel 11 -> 111 mv]: INFO: initiate new phase 2 negotiation: May 9 10:30:21 racoon: [tunel 11 -> 111 mv]: INFO: IPsec-SA established: ESP/Tunnel 84.255.245.212[0]->77.234.135.134[0] spi=66013813(0x3ef4a75) May 9 10:30:21 racoon: [tunel 11 -> 111 mv]: INFO: IPsec-SA established: ESP/Tunnel 77.234.135.134[0]->84.255.245.212[0] spi=30759723(0x1d55b2b) May 9 10:30:21 racoon: INFO: purged IPsec-SA proto_id=ESP spi=207960073. May 9 10:31:02 racoon: [tunel 11 -> 111 mv]: INFO: initiate new phase 2 negotiation: May 9 10:31:02 racoon: [tunel 11 -> 111 mv]: INFO: IPsec-SA established: ESP/Tunnel 84.255.245.212[0]->77.234.135.134[0] spi=31393894(0x1df0866) May 9 10:31:02 racoon: [tunel 11 -> 111 mv]: INFO: IPsec-SA established: ESP/Tunnel 77.234.135.134[0]->84.255.245.212[0] spi=10754697(0xa41a89) May 9 10:31:03 racoon: INFO: purged IPsec-SA proto_id=ESP spi=30759723. May 9 10:31:03 racoon: [tunel 11 -> 111 mv]: INFO: initiate new phase 2 negotiation: ... and on office2 side i see: May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: INFO: respond new phase 2 negotiation: 84.255.245.212[0]<=>77.234.135.134[0] May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: INFO: Update the generated policy : 192.168.1.0/24[0] 192.168.111.0/24[0] proto=any dir=in May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: INFO: IPsec-SA established: ESP/Tunnel 77.234.135.134[0]->84.255.245.212[0] spi=30759723(0x1d55b2b) May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: INFO: IPsec-SA established: ESP/Tunnel 84.255.245.212[0]->77.234.135.134[0] spi=66013813(0x3ef4a75) May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does not already exist: "192.168.1.0/24[0] 192.168.111.0/24[0] proto=any dir=in" May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does not already exist: "192.168.111.0/24[0] 192.168.1.0/24[0] proto=any dir=out" May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: ERROR: pfkey DELETE received: ESP 84.255.245.212[0]->77.234.135.134[0] spi=143114727(0x887c1e7) May 9 10:31:02 racoon: [Unknown Gateway/Dynamic]: INFO: respond new phase 2 negotiation: 84.255.245.212[0]<=>77.234.135.134[0] May 9 10:31:02 racoon: [Unknown Gateway/Dynamic]: INFO: Update the generated policy : 192.168.11.0/24[0] 192.168.111.0/24[0] proto=any dir=in May 9 10:31:02 racoon: [Unknown Gateway/Dynamic]: INFO: IPsec-SA established: ESP/Tunnel 77.234.135.134[0]->84.255.245.212[0] spi=10754697(0xa41a89) May 9 10:31:02 racoon: [Unknown Gateway/Dynamic]: INFO: IPsec-SA established: ESP/Tunnel 84.255.245.212[0]->77.234.135.134[0] spi=31393894(0x1df0866) May 9 10:31:02 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does not already exist: "192.168.11.0/24[0] 192.168.111.0/24[0] proto=any dir=in" May 9 10:31:02 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does not already exist: "192.168.111.0/24[0] 192.168.11.0/24[0] proto=any dir=out" May 9 10:31:03 racoon: [Unknown Gateway/Dynamic]: ERROR: pfkey DELETE received: ESP 84.255.245.212[0]->77.234.135.134[0] spi=66013813(0x3ef4a75) May 9 10:31:03 racoon: [Unknown Gateway/Dynamic]: INFO: respond new phase 2 negotiation: 84.255.245.212[0]<=>77.234.135.134[0] ... and so on. This is repeating at a fairly higher frequency that I'd expect. While this is going on, tunnel mostly works but dissapears every now and then. What could be the reason for this? Lifetimes for phase1 and phase2 are set to 28800s on both sides. -- Jure Pečar http://jure.pecar.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec woes
On Fri, May 9, 2008 at 2:01 AM, Jure Pečar <[EMAIL PROTECTED]> wrote: > Of course. Let's debug one by one. This is office1->office2): > > on office1 i see: Looks fairly normal. > ... and on office2 side i see: > > May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does > not already exist: "192.168.1.0/24[0] 192.168.111.0/24[0] proto=any dir=in" > May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does > not already exist: "192.168.111.0/24[0] 192.168.1.0/24[0] proto=any dir=out" Oops. Loks like you have some sort of VPN definition error here. Are you sure that the local/remote nets match on both ends? Also make sure that you do not have any duplicate local/remote nets across all VPN connectons defined on each firewall. -Dave
Re: [pfSense Support] ipsec woes
On Fri, 9 May 2008 12:31:41 -0700 "David Rees" <[EMAIL PROTECTED]> wrote: > On Fri, May 9, 2008 at 2:01 AM, Jure Pečar <[EMAIL PROTECTED]> wrote: > > May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does > > not already exist: "192.168.1.0/24[0] 192.168.111.0/24[0] proto=any dir=in" > > May 9 10:30:20 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy does > > not already exist: "192.168.111.0/24[0] 192.168.1.0/24[0] proto=any dir=out" > > Oops. Loks like you have some sort of VPN definition error here. Are > you sure that the local/remote nets match on both ends? Also make sure > that you do not have any duplicate local/remote nets across all VPN > connectons defined on each firewall. This is what makes it interesting to me - office2 has no tunnels defined, just "allow mobile clients" enabled and all settings underneath as on office1. No subnets overlap, so things should "just work". I'll try to set up a tunnel at office2 back to office1 and see what I get. -- Jure Pečar http://jure.pecar.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec woes
On Mon, 12 May 2008 11:14:20 +0200 Jure Pečar <[EMAIL PROTECTED]> wrote: > I'll try to set up a tunnel at office2 back to office1 and see what > I get. Nothing really - I just figured out that what I see in pfsense gui is not always what is in the config files. But after I manually fixed racoon.conf and psk.txt, I still couldn't get the tunnels up. So I declared ipsec as not useable and set up openvpn. It works from the firewall, but not from the clients on the LAN, which I is weird, becaure route exists in the routing table and there are no rules to block the traffic. Fun ... -- Jure Pečar http://jure.pecar.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec woes
On Tue, May 13, 2008 at 6:47 AM, Jure Pečar <[EMAIL PROTECTED]> wrote: > > > I solved office1 to office2 with openvpn, now I want to figure out the > problem between office1 and servers. > > I monitored the ipsec logs on both pfsenses at the time when ssh session > freezes and nothing shows up in the logs. The interesting thing is that > sometimes it freezes and never recovers, while at other times it recovers > after a minute or so and spits out the remaining text of dmesg output. > > Any ideas? > FreeBSD (hence pfSense) creates PMTUD black holes with IPsec. Hence large packets just disappear and you see things like SSH sessions freeze. Work around with current pfSense releases is to lower the MTU of your hosts to 1400 or so. There will be a real fix for it available for 1.2.1, now that FreeBSD has fixed the issue.
Re: [pfSense Support] ipsec woes
On Thu, 8 May 2008 16:23:28 -0700 "David Rees" <[EMAIL PROTECTED]> wrote: > > office1 to servers: works, but typing 'dmesg' or something else with lots > > of output freezes the ssh session over it. It never freezes if left idle. > > Sshing to the same machine over public ip does not exhibit this problem. I solved office1 to office2 with openvpn, now I want to figure out the problem between office1 and servers. I monitored the ipsec logs on both pfsenses at the time when ssh session freezes and nothing shows up in the logs. The interesting thing is that sometimes it freezes and never recovers, while at other times it recovers after a minute or so and spits out the remaining text of dmesg output. Any ideas? -- Jure Pečar http://jure.pecar.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec crl
On 8/17/2011 4:56 PM, Fuchs, Martin wrote: > Hi, > Does the IPSec config make use of crl's defined in the certified-Manager ? > I cannot See any references To used crl in the cert-Manager when a crl is d= > efined there, neither can i Chose a crl in the IPSec-config.=20 > This is a Security-Risk i think, that should Be fixed 2.0 leaves the door = > or am i mistaken ? The IPsec config doesn't currently hook into the CRLs from the system. It's been discussed on the forum a bit. http://forum.pfsense.org/index.php?topic=35872.0 is the thread I was thinking of specifically. The way racoon wants the crl written out and named wasn't very easy to work with. It's not that dangerous to run without a CRL unless you need to revoke access, then you can always just switch up the CA and certs for both ends if it's custom. Jim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] ipsec more info
On 8/2/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > Is it possible to route all traffic from opt1 across an ipsec vpn. > > I think there's somebody doing this with m0n0wall. I recall it being discussed on the list in the past. I believe how they accomplished it was adding a site to site VPN, then adding a static route on the LAN for 0.0.0.0/0 (i.e. everything; this route wasn't possible in the GUI without changing the code, not sure if that's been changed here or not) pointing to the other end LAN side of the VPN tunnel. I could be way off on that though, it's been a while. Worth a shot at least, might also want to google with site:m0n0.ch to see if you come up with anything. -cmb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec more info
Ok I have made a bit of progress with this one. I have setup a vpn by editing the xml file in the vpn section The local vpn is configured like so The remote subnet becomes 0.0.0.0/0. At the remote end I made a outbout nat rule for my local subnet And added firewall rules to allow those out my remote LAN. the traceroute to www.google.ie completes in a lot less hops than it would via our route 14 instead of 22. I checks the firewall on the remote end and it seems to be gatewaying the traffic as well. The problem seems to now be that out of the fourteen hops on the new route 9 of them seem to time out. Would love some insight into this. I am now going to look into the static route bit as well. And see if trying to tie the gateway down better helps. I believe one of two issues would now apply. Either the nat on the far end is causing a problem. Or something that I just don't understand Regards alan I think there's somebody doing this with m0n0wall. I recall it being discussed on the list in the past. I believe how they accomplished it was adding a site to site VPN, then adding a static route on the LAN for 0.0.0.0/0 (i.e. everything; this route wasn't possible in the GUI without changing the code, not sure if that's been changed here or not) pointing to the other end LAN side of the VPN tunnel. I could be way off on that though, it's been a while. Worth a shot at least, might also want to google with site:m0n0.ch to see if you come up with anything. > > Is it possible to route all traffic from opt1 across an ipsec vpn. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec more info
I would to help with this but I have to admit that this is a new prospect for me. Let me know how it turns out and it would be nice if we could document this behavior. On 8/3/05, alan walters <[EMAIL PROTECTED]> wrote: > Ok I have made a bit of progress with this one. > I have setup a vpn by editing the xml file in the vpn section > > The local vpn is configured like so > The remote subnet becomes 0.0.0.0/0. > > At the remote end I made a outbout nat rule for my local subnet > And added firewall rules to allow those out my remote LAN. > > the traceroute to www.google.ie completes in a lot less hops than it > would via our route 14 instead of 22. I checks the firewall on the > remote end and it seems to be gatewaying the traffic as well. > > The problem seems to now be that out of the fourteen hops on the new > route > 9 of them seem to time out. Would love some insight into this. > > I am now going to look into the static route bit as well. And see if > trying to tie the gateway down better helps. > > I believe one of two issues would now apply. Either the nat on the far > end is causing a problem. Or something that I just don't understand > > > Regards alan > > > > > I think there's somebody doing this with m0n0wall. I recall it being > discussed on the list in the past. I believe how they accomplished it > was adding a site to site VPN, then adding a static route on the LAN > for 0.0.0.0/0 (i.e. everything; this route wasn't possible in the GUI > without changing the code, not sure if that's been changed here or > not) pointing to the other end LAN side of the VPN tunnel. I could be > way off on that though, it's been a while. > > Worth a shot at least, might also want to google with site:m0n0.ch to > see if you come up with anything. > > > > Is it possible to route all traffic from opt1 across an ipsec vpn. > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec tunnel errors ...
And then finally I get this in the system log racoon: ERROR: x.x.x.x give up to get IPsec-SA due to time up to wait. I get these errors when trying to nail up a tunnel: racoon: ERROR: pfkey ADD failed: Invalid argument racoon: ERROR: pfkey ADD failed: Invalid argument racoon: ERROR: pfkey UPDATE failed: Invalid argument kernel: WARNING: pseudo-random number generator used for IPsec processing racoon: INFO: initiate new phase 2 negotiation: x.x.x.x[0]<=>x.x.x.x[0] racoon: INFO: ISAKMP-SA established x.x.x.x[500]-x.x.x.x[500] spi:jgyhujtg5e2e23df8:63234fda353b0ebb racoon: INFO: begin Identity Protection mode I had the tunnel up and running fine under the 74.8 version, but after an update to 76.2 I started getting these errors and the tunnel never comes up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec and 0.77
I am running IPSEC point to point, not mobile and don't seem to be having any problems connecting to a m0n0wall box. Roy -Original Message- From: alan walters [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 2:30 PM To: Scott Ullrich Cc: support@pfsense.com Subject: [pfSense Support] ipsec and 0.77 I don't know about this I still am seeing problems with ipsec Auto generated rules being wrong and an empty tunnel still being made with 0.77. I know this is nothing to do with the above problem but 0.77 is problematic with ipsec mobile clients and no tunnels created. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec and 0.77
Is this a fresh configuration? On 8/18/05, alan walters <[EMAIL PROTECTED]> wrote: > > I don't know about this I still am seeing problems with ipsec > Auto generated rules being wrong and an empty tunnel still being made > with 0.77. > > I know this is nothing to do with the above problem but 0.77 is > problematic with ipsec mobile clients and no tunnels created. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] ipsec and 0.77
An upgrade from 0.48 Had to change the ipsec part of the xml file to delete the crap from the upgrade. But whenever you save a new rule it adds a blank tunnel again. And creates rubbish rules. > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: 18 August 2005 20:42 > To: alan walters > Cc: support@pfsense.com > Subject: Re: [pfSense Support] ipsec and 0.77 > > Is this a fresh configuration? > > On 8/18/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > I don't know about this I still am seeing problems with ipsec > > Auto generated rules being wrong and an empty tunnel still being made > > with 0.77. > > > > I know this is nothing to do with the above problem but 0.77 is > > problematic with ipsec mobile clients and no tunnels created. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec and 0.77
You have to zap the entire ipsec section after upgrading or this can continue to be a problem On 8/18/05, alan walters <[EMAIL PROTECTED]> wrote: > An upgrade from 0.48 > > Had to change the ipsec part of the xml file to delete the crap from the > upgrade. > > But whenever you save a new rule it adds a blank tunnel again. > And creates rubbish rules. > > > -Original Message- > > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > > Sent: 18 August 2005 20:42 > > To: alan walters > > Cc: support@pfsense.com > > Subject: Re: [pfSense Support] ipsec and 0.77 > > > > Is this a fresh configuration? > > > > On 8/18/05, alan walters <[EMAIL PROTECTED]> wrote: > > > > > > I don't know about this I still am seeing problems with ipsec > > > Auto generated rules being wrong and an empty tunnel still being > made > > > with 0.77. > > > > > > I know this is nothing to do with the above problem but 0.77 is > > > problematic with ipsec mobile clients and no tunnels created. > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] ipsec and tracert
alan walters wrote: Just wondering if someone can give the low down on wheather it is possible to over come this problem. Have a ipsec tunnel from remote location to lan of pfsense then using routing allow traffic out the wan interface of pfsense. Client --Remote pfsense Lan(pfsense vpn)wan- internetgateway internet tunnel when I tracert to the internet I get reply for remote pfsense timeout reply from internet gateway and then the rest I want to try and get rid of the timeout at the pfsense vpn. Any great ideas or is it just not possble from what I've seen, it's just not possible. This has always been an issue in m0n0wall too. One thing I'd try that I can't recall if I've tried or not is to add a static route on the remote side, as described here: http://doc.m0n0.ch/handbook/faq-snmpovervpn.html be interested in hearing what you find out if you try it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Ipsec issues update
On Dec 18, 2005, at 6:34 AM, alan walters wrote:I found that in the mobile clients section that I needed to change my identifier to a fqdn. Where before it was an ip.I have never gotten mobile clients to work using IP as identifier. I'm surprised it worked for you before.
RE: [pfSense Support] Ipsec issues update
Title: Ipsec issues update What version are you running that works for you? Thanks John From: alan walters [mailto:[EMAIL PROTECTED] Sent: Sunday, December 18, 2005 6:35 AM To: support@pfsense.com Subject: [pfSense Support] Ipsec issues update Well I have got all my tunnels working again. I found that in the mobile clients section that I needed to change my identifier to a fqdn. Where before it was an ip. Once this was done all my tunnels worked fine again. All sites are on static ip addresses. Alan Walters Aillweecave Company Limited Ballyvaughan Co Clare Ph: 00 353 65 7077 036 Fax: 00 353 65 7077 107
RE: [pfSense Support] Ipsec issues update
Title: Ipsec issues update 0.96.4 but it took some fiddling. From: John Cianfarani [mailto:[EMAIL PROTECTED] Sent: Monday, December 19, 2005 7:18 PM To: support@pfsense.com Subject: RE: [pfSense Support] Ipsec issues update What version are you running that works for you? Thanks John From: alan walters [mailto:[EMAIL PROTECTED] Sent: Sunday, December 18, 2005 6:35 AM To: support@pfsense.com Subject: [pfSense Support] Ipsec issues update Well I have got all my tunnels working again. I found that in the mobile clients section that I needed to change my identifier to a fqdn. Where before it was an ip. Once this was done all my tunnels worked fine again. All sites are on static ip addresses. Alan Walters Aillweecave Company Limited Ballyvaughan Co Clare Ph: 00 353 65 7077 036 Fax: 00 353 65 7077 107
Re: [pfSense Support] IPSec BugValidation 5
We didnt change anything but ok. Scott On 1/18/06, Pedro Paulo de Magalhaes Oliveira Junior <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > IPSec issue has been fixed in BugValidation 5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] IPSec BugValidation 5
I will see if I can test something tonight. Pedro what problem do you see fixed? Establishment/Bouncing? John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 11:45 AM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec BugValidation 5 We didnt change anything but ok. Scott On 1/18/06, Pedro Paulo de Magalhaes Oliveira Junior <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > IPSec issue has been fixed in BugValidation 5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec BugValidation 5
ISP issues? We really didn't change anything. On 1/18/06, Pedro Paulo de Magalhaes Oliveira Junior <[EMAIL PROTECTED]> wrote: > Yes. The bouncing stoped. > > -Mensagem original- > De: John Cianfarani [mailto:[EMAIL PROTECTED] > Enviada em: quarta-feira, 18 de janeiro de 2006 16:19 > Para: support@pfsense.com > Assunto: RE: [pfSense Support] IPSec BugValidation 5 > > I will see if I can test something tonight. > Pedro what problem do you see fixed? Establishment/Bouncing? > > John > > -Original Message- > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 18, 2006 11:45 AM > To: support@pfsense.com > Subject: Re: [pfSense Support] IPSec BugValidation 5 > > We didnt change anything but ok. > > Scott > > On 1/18/06, Pedro Paulo de Magalhaes Oliveira Junior > <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, > > > > > > > > IPSec issue has been fixed in BugValidation 5. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 267.14.20/233 - Release Date: 18/1/2006 > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
On 1/25/06, David Strout <[EMAIL PROTECTED]> wrote: > Are there any plans to expand IPSec to support > more VPN/phase 1 and 2 options ... like say: > > Compression > & > IKE Encryption: > AES 256 > Twofish 256 > Serpent 256 > & > ESP Encryption: > AES 256 > Twofish 256 > Serpent 256 > & > IKE Integrity: > SHA2 512/256 > & > Higher DH key group .. eg: > 1536 bit > & > Higher PFS key group .. eg: > 1536 bit > > Not sure if the current IPSec-tools/FreeBSD is > capable of these advanced features, but it would > be nice to explore for future releases as an > enhancement to a great VPN product already. Care to do the research for us? --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
Then my question to you is this why haven't they been implemented? You've / we've all spent a lot of time on the product to make it ( and I quote) a business class product which "provides all the important features of commercial firewall boxes" (BTW, it IS a great product, just be open to suggestions for improvments). I think not, as most of the commercial products out there, [Cisco, NetScreen, CheckPoint] to name a few, support most if not all of the features I mentioned below, before getting flamed as a FUD writer (look in the mirror before pitching stones, and do so real research on something other than BSD). I'm not sure what FUD means, but I can make an educated guess, and I'm not sure that there needs to be this level of inappropriate and offensive communications/responses, especially from a member of the core dev team (certainly not very professional). In short ... take of your BSD blinders and look around before accusing someone of NOT doing their research, certainly when someone make a concerted effort to apologize for the noise ... then you still feel the need to flame. BO BTW Google is a great tool! -- David L. Strout Engineering Systems Plus, LLC - Original Message - Subject: Re: Re: [pfSense Support] IPSec enhancements ??s From: [EMAIL PROTECTED] To: support@pfsense.com Date: 01-25-2006 11:44 pm > I did your research for you because I was curious. I'd suggest you > look a little harder before spreading FUD. If you aren't going to > bother spending five minutes doing correct research, I'm certainly not > going to go out of my way implementing uninteresting features which I > don't need or use. http://ipsec-tools.sourceforge.net/ (which we use) > certainly does support everything you asked for (as you can see here: > http://netbsd.gw.com/cgi-bin/man-cgi?racoon.conf+5+NetBSD-current) > except for Serpent. We haven't implemented them as the old racoon > likely didn't support them. Besides, most commercial vendors don't > support anything outside of DES/3DES/AES/Blowfish and MD5/SHA1 - let > alone DH groups outside of 1,2,5. > > --Bill > > On 1/25/06, David Strout <[EMAIL PROTECTED]> wrote: > > Ah no ... it appears that there is NOT the same > > level(s) of VPN crypts/hashes/features for the > > xBSD realm as there are for say the Linux realm. > > > > Again appologies for the noise !! > > > > -- > > David L. Strout > > Engineering Systems Plus, LLC > > > > - Original Message - > > Subject: Re: [pfSense Support] IPSec enhancements > > ??s > > From: [EMAIL PROTECTED] > > To: support@pfsense.com > > Date: 01-25-2006 9:57 pm > > > > > > > On 1/25/06, David Strout <[EMAIL PROTECTED]> > > wrote: > > > > Are there any plans to expand IPSec to support > > > > more VPN/phase 1 and 2 options ... like say: > > > > > > > > Compression > > > > & > > > > IKE Encryption: > > > > AES 256 > > > > Twofish 256 > > > > Serpent 256 > > > > & > > > > ESP Encryption: > > > > AES 256 > > > > Twofish 256 > > > > Serpent 256 > > > > & > > > > IKE Integrity: > > > > SHA2 512/256 > > > > & > > > > Higher DH key group .. eg: > 1536 bit > > > > & > > > > Higher PFS key group .. eg: > 1536 bit > > > > > > > > Not sure if the current IPSec-tools/FreeBSD is > > > > capable of these advanced features, but it > > would > > > > be nice to explore for future releases as an > > > > enhancement to a great VPN product already. > > > > > > Care to do the research for us? > > > > > > --Bill > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
On 1/26/06, David Strout <[EMAIL PROTECTED]> wrote: > Then my question to you is this why haven't > they been implemented? Because nobody has submitted patches? > You've / we've all spent a lot of time on the > product to make it ( and I quote) a business class > product which "provides all the important features > of commercial firewall boxes" (BTW, it IS a great > product, just be open to suggestions for > improvments). I think not, as most of the > commercial products out there, [Cisco, NetScreen, > CheckPoint] to name a few, support most if not all > of the features I mentioned below, before getting > flamed as a FUD writer (look in the mirror before > pitching stones, and do so real research on > something other than BSD). I'm not sure what FUD > means, but I can make an educated guess, and I'm > not sure that there needs to be this level of > inappropriate and offensive > communications/responses, especially from a member > of the core dev team (certainly not very > professional). > > In short ... take of your BSD blinders and look > around before accusing someone of NOT doing their > research, certainly when someone make a concerted > effort to apologize for the noise ... then you > still feel the need to flame. > > BO BTW Google is a great tool! David, I think you have lost sight that we are all volunteers. We do not get paid for sitting here fielding 100 questions a day. Please do not forget this. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
On 1/26/06, David Strout <[EMAIL PROTECTED]> wrote: > Then my question to you is this why haven't > they been implemented? It doesn't interest me. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
David, You have to understand that this project is a labor of love and since everyone is doing this as a volunteer basis, adding features that aren't interesting, that up until now, nobody has asked for, especially when they're working very hard to get 1.0 released is pretty unrewarding. It's pretty unreasonable to make a request like this and expect the core developers (like Billm) to drop everything and work on it. Especially when, as has been pointed out, its not an interesting feature. -Gary David Strout wrote: Case-in-point -- David L. Strout Engineering Systems Plus, LLC - Original Message ----- Subject: Re: [pfSense Support] IPSec enhancements ??s From: [EMAIL PROTECTED] To: support@pfsense.com Date: 01-26-2006 3:46 pm On 1/26/06, David Strout <[EMAIL PROTECTED]> wrote: Then my question to you is this why haven't they been implemented? It doesn't interest me. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
Long time listener, first time caller. Bearded, black-wearing, anti-social, White Zombie & Otep-listening security professional. I'm not going to quote the precise statement because it's not worth repeating, but it's rather obvious that you're not making much headway with your suggestion because of your rather abrasive response to being at least temporarily shot down. Good example of how not to approach getting other people to do something you want done. RB - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
I wasn't planning on responding any further to this thread, but after a little thought decided it would be good FAQ entry (I'll let someone else submit it, I'm too tired tonight). The developers that work on pfSense do so because it interests them. Making it perfect for everyone isn't necessarily interesting to us, making it perfect for ourselves is. Along those lines, features get implemented because we want them or think it might be useful to us down the road, not because it's interesting or useful to anyone else. This might come across as being an ass, but it's our time, we'll make use of it as we see fit. How do I get missing feature X implemented in pfSense? Option 1: Suggest it, maybe it'll peak the interest of a developer who hadn't thought of it. If it doesn't, you're still left with options 2 and 3 Option 2: Implement it yourself and submit a patch. Option 3: Make it interesting to someone to implement it. Note: option 1 and 3 aren't necessarily going to happen overnight either, just because it's interesting, doesn't mean it's a priority. Here's things that _I'm_ interested in: http://wiki.pfsense.com/wikka.php?wakka=BillM if you don't see your feature on there, option 2 and 3 are the only remaining options for me. I won't speak for GeekGod, but here's some of the things he's interested in: http://wiki.pfsense.com/wikka.php?wakka=GeekGod And naturally, the MOST interesting thing to all of us right now is 1.0. Most open source development works the same way. Developers work on stuff that interests them, people learn how to change the stuff they want, or they try and get someone interested in doing it for them (that usually amounts to some form of payment). Remember we're not in this to make YOUR life easier, we're in it to make ours easier or more enjoyable in some way. We also work day jobs, this certainly doesn't pay the bills, if anything, it makes our bills more expensive. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSec enhancements ??s
http://faq.pfsense.com/index.php?action=artikel&cat=1&id=126&artlang=en On 1/27/06, Bill Marquette <[EMAIL PROTECTED]> wrote: > I wasn't planning on responding any further to this thread, but after > a little thought decided it would be good FAQ entry (I'll let someone > else submit it, I'm too tired tonight). The developers that work on > pfSense do so because it interests them. Making it perfect for > everyone isn't necessarily interesting to us, making it perfect for > ourselves is. Along those lines, features get implemented because we > want them or think it might be useful to us down the road, not because > it's interesting or useful to anyone else. This might come across as > being an ass, but it's our time, we'll make use of it as we see fit. > > How do I get missing feature X implemented in pfSense? > > Option 1: Suggest it, maybe it'll peak the interest of a developer who > hadn't thought of it. If it doesn't, you're still left with options 2 > and 3 > Option 2: Implement it yourself and submit a patch. > Option 3: Make it interesting to someone to implement it. > > Note: option 1 and 3 aren't necessarily going to happen overnight > either, just because it's interesting, doesn't mean it's a priority. > > Here's things that _I'm_ interested in: > http://wiki.pfsense.com/wikka.php?wakka=BillM > if you don't see your feature on there, option 2 and 3 are the only > remaining options for me. > > I won't speak for GeekGod, but here's some of the things he's > interested in: http://wiki.pfsense.com/wikka.php?wakka=GeekGod > > And naturally, the MOST interesting thing to all of us right now is 1.0. > > Most open source development works the same way. Developers work on > stuff that interests them, people learn how to change the stuff they > want, or they try and get someone interested in doing it for them > (that usually amounts to some form of payment). Remember we're not in > this to make YOUR life easier, we're in it to make ours easier or more > enjoyable in some way. We also work day jobs, this certainly doesn't > pay the bills, if anything, it makes our bills more expensive. > > --Bill > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC Firewall Rules
Not sure that we enable tunnel to tunnel routing. Not sure if there's an option either, but that's what I'd look for. --Bill On 6/7/06, Brad Bendy <[EMAIL PROTECTED]> wrote: Hello, I have a setup as follows: Core-Firewall - - - - -- Remote-Site-1 Remote-Site-2 From the Core I can ping both remote sites, no problems. But I cannot get traffic (ICMP or TCP/UDP) from remote-site-2 to remote-site-1. All 3 firewalls have the default LAN rules as allow all from LAN subnet, to all others. On the Core firewall, I also added a rule where the source is subnet is allowed to all other subnets. Any clue what causes this, something else that I am missing? Any help would be great. Thanks! Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] IPSEC Firewall Rules
You need parallel tunnels for both connections to work (explanation why at the bottom): At remote Site 1: Tunnel1 to corefirewall: local subnet: LAN remote subnet: LAN subnet of Corefirewall Tunnel2 to corefirewall: local subnet: LAN remote subnet: LAN of Remote Site 2 (!) --- Same for remote Site 2: Tunnel1 to corefirewall: local subnet: LAN remote subnet: LAN subnet of Corefirewall Tunnel2 to corefirewall: local subnet: LAN remote subnet: LAN of Remote Site 1 (!) Corefirewall: Tunnel1 to remote Site 1: local subnet: LAN remote subnet: LAN subnet of remote Site 1 Tunnel2 to remote Site 1: local subnet: LAN of remote Site 2 (!) remote subnet: LAN of Remote Site 1 Tunnel 3 to remote Site 2: local subnet: LAN remote subnet: LAN subnet of remote Site 2 Tunnel4 to remote Site 2: local subnet: LAN of remote Site 1 (!) remote subnet: LAN of remote Site 2 To be able to divide the parallel Tunnels as they run between the same public IPs you need to work with unique Identifiers for the tunnels. Create a set of preshared keys for the tunnels. Btw, this doesn't work for a mobile Client setup as you can't set more than one local subnet at the static end. So why is it complicated like this? Traffic with destination to remote site 2 doesn't match the tunneldefinition you have between remote site 1 and corefirewall, so the traffic won't be encapsulated into the tunnel but goes out your real WAN. Static routes can't fix this. Will this change in an upcoming version of pfSense? I hope that but for version 1.0 it has to be done this way. Holger > -Original Message- > From: Bill Marquette [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 7:56 PM > To: support@pfsense.com > Subject: Re: [pfSense Support] IPSEC Firewall Rules > > > Not sure that we enable tunnel to tunnel routing. Not sure if there's > an option either, but that's what I'd look for. > > --Bill > > On 6/7/06, Brad Bendy <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I have a setup as follows: > > Core-Firewall > >- - > > - - > >-- > > Remote-Site-1 Remote-Site-2 > > > > From the Core I can ping both remote sites, no problems. > But I cannot get > > traffic (ICMP or TCP/UDP) from remote-site-2 to remote-site-1. All 3 > > firewalls have the default LAN rules as allow all from LAN > subnet, to all > > others. On the Core firewall, I also added a rule where the > source is subnet > > is allowed to all other subnets. > > > > Any clue what causes this, something else that I am missing? > > > > Any help would be great. > > > > Thanks! > > Brad > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Virus checked by G DATA AntiVirusKit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] Ipsec Tunnels In
You usually should have no problems but as the packetfilter/natting is completely different from m0n0 and pfSense at the backend you should evaluate this setup. However I expect it to just work out of the box if you configure it the same way like with m0n0. First try this with a single WAN before you switch to dual WAN. Maybe loadbalancing is not a good option for this kind of setup but policybased routing (throwing half of the customers to WAN1 and the other half to WAN2 should work fine). Only keep in mind that there are some limitations when it comes to trafficshaping when using multiwan setups. Holger > -Original Message- > From: Justin Wilson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 11:02 PM > To: support@pfsense.com > Subject: [pfSense Support] Ipsec Tunnels In > > > I have been doing a 1:1 Nat with customers on M0n0wall. > VPN has been > working fine. I just give them a public IP and 1:1 Nat that > to their inside > IP. > > We are getting ready to go to a Dual Wan Pfsense box. > Will I need to do > anything different than I am used to have VPNs work? > > Thanks in advance, > Justin > -- > Justin S. Wilson <[EMAIL PROTECTED]> > --- > MTIN.NET High Speed Wireless > Phone: 765.762.2851 > Web : www.mtin.net > AOLIM: j2sw > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Virus checked by G DATA AntiVirusKit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC Firewall Rules
doh, great explanation Holger...I totally forgot about the security association issue ;) --Bill On 6/7/06, Holger Bauer <[EMAIL PROTECTED]> wrote: You need parallel tunnels for both connections to work (explanation why at the bottom): At remote Site 1: Tunnel1 to corefirewall: local subnet: LAN remote subnet: LAN subnet of Corefirewall Tunnel2 to corefirewall: local subnet: LAN remote subnet: LAN of Remote Site 2 (!) --- Same for remote Site 2: Tunnel1 to corefirewall: local subnet: LAN remote subnet: LAN subnet of Corefirewall Tunnel2 to corefirewall: local subnet: LAN remote subnet: LAN of Remote Site 1 (!) Corefirewall: Tunnel1 to remote Site 1: local subnet: LAN remote subnet: LAN subnet of remote Site 1 Tunnel2 to remote Site 1: local subnet: LAN of remote Site 2 (!) remote subnet: LAN of Remote Site 1 Tunnel 3 to remote Site 2: local subnet: LAN remote subnet: LAN subnet of remote Site 2 Tunnel4 to remote Site 2: local subnet: LAN of remote Site 1 (!) remote subnet: LAN of remote Site 2 To be able to divide the parallel Tunnels as they run between the same public IPs you need to work with unique Identifiers for the tunnels. Create a set of preshared keys for the tunnels. Btw, this doesn't work for a mobile Client setup as you can't set more than one local subnet at the static end. So why is it complicated like this? Traffic with destination to remote site 2 doesn't match the tunneldefinition you have between remote site 1 and corefirewall, so the traffic won't be encapsulated into the tunnel but goes out your real WAN. Static routes can't fix this. Will this change in an upcoming version of pfSense? I hope that but for version 1.0 it has to be done this way. Holger > -Original Message- > From: Bill Marquette [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 7:56 PM > To: support@pfsense.com > Subject: Re: [pfSense Support] IPSEC Firewall Rules > > > Not sure that we enable tunnel to tunnel routing. Not sure if there's > an option either, but that's what I'd look for. > > --Bill > > On 6/7/06, Brad Bendy <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I have a setup as follows: > > Core-Firewall > >- - > > - - > >-- > > Remote-Site-1 Remote-Site-2 > > > > From the Core I can ping both remote sites, no problems. > But I cannot get > > traffic (ICMP or TCP/UDP) from remote-site-2 to remote-site-1. All 3 > > firewalls have the default LAN rules as allow all from LAN > subnet, to all > > others. On the Core firewall, I also added a rule where the > source is subnet > > is allowed to all other subnets. > > > > Any clue what causes this, something else that I am missing? > > > > Any help would be great. > > > > Thanks! > > Brad > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Virus checked by G DATA AntiVirusKit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC Firewall Rules
Wow, quite a long setup, but after thinking thru this, it all makes sense! Thanks for the reply Brad On Wednesday 07 June 2006 15:57, Holger Bauer wrote: > You need parallel tunnels for both connections to work (explanation why at > the bottom): > > At remote Site 1: > > Tunnel1 to corefirewall: > local subnet: LAN > remote subnet: LAN subnet of Corefirewall > > Tunnel2 to corefirewall: > local subnet: LAN > remote subnet: LAN of Remote Site 2 (!) > > --- > Same for remote Site 2: > > Tunnel1 to corefirewall: > local subnet: LAN > remote subnet: LAN subnet of Corefirewall > > Tunnel2 to corefirewall: > local subnet: LAN > remote subnet: LAN of Remote Site 1 (!) > > > Corefirewall: > > Tunnel1 to remote Site 1: > local subnet: LAN > remote subnet: LAN subnet of remote Site 1 > > Tunnel2 to remote Site 1: > local subnet: LAN of remote Site 2 (!) > remote subnet: LAN of Remote Site 1 > > Tunnel 3 to remote Site 2: > local subnet: LAN > remote subnet: LAN subnet of remote Site 2 > > Tunnel4 to remote Site 2: > local subnet: LAN of remote Site 1 (!) > remote subnet: LAN of remote Site 2 > > > > To be able to divide the parallel Tunnels as they run between the same > public IPs you need to work with unique Identifiers for the tunnels. Create > a set of preshared keys for the tunnels. > > Btw, this doesn't work for a mobile Client setup as you can't set more than > one local subnet at the static end. > > So why is it complicated like this? Traffic with destination to remote site > 2 doesn't match the tunneldefinition you have between remote site 1 and > corefirewall, so the traffic won't be encapsulated into the tunnel but goes > out your real WAN. Static routes can't fix this. > > Will this change in an upcoming version of pfSense? I hope that but for > version 1.0 it has to be done this way. > > > Holger > > > -Original Message- > > From: Bill Marquette [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 07, 2006 7:56 PM > > To: support@pfsense.com > > Subject: Re: [pfSense Support] IPSEC Firewall Rules > > > > > > Not sure that we enable tunnel to tunnel routing. Not sure if there's > > an option either, but that's what I'd look for. > > > > --Bill > > > > On 6/7/06, Brad Bendy <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > > > I have a setup as follows: > > > Core-Firewall > > >- - > > > - - > > >-- > > > Remote-Site-1 Remote-Site-2 > > > > > > From the Core I can ping both remote sites, no problems. > > > > But I cannot get > > > > > traffic (ICMP or TCP/UDP) from remote-site-2 to remote-site-1. All 3 > > > firewalls have the default LAN rules as allow all from LAN > > > > subnet, to all > > > > > others. On the Core firewall, I also added a rule where the > > > > source is subnet > > > > > is allowed to all other subnets. > > > > > > Any clue what causes this, something else that I am missing? > > > > > > Any help would be great. > > > > > > Thanks! > > > Brad > > > > - > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > Virus checked by G DATA AntiVirusKit > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC behind Firewall
On 9/12/06, Alvaro Pietrobono <[EMAIL PROTECTED]> wrote: Hi, It's possible to configure a vpn lan-to-lan with ipsec and pfSense behind firewall? I'm trying some different configurations but unsuccessful. Thanx in advance. pfSense does not have nat traversal support for IPSEC. Doubt it will work. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC behind Firewall
I'm sorry Scott, but I don't explained the problem very well. Pfsense is behind a firewall and I'm trying to establish vpn lan-to-lan with an Ipsec compliant (Cisco Concentrator in this case) with a public ip. Few minutes ago I found the solution and now it's working but I have to ping an host behind the other peer because after few minutes connection goes down. In pfSense if I disable and than enable ipsec, connection goes up again. What do you think about? regards ~A - Original Message - From: "Scott Ullrich" <[EMAIL PROTECTED]> To: Sent: Tuesday, September 12, 2006 5:17 PM Subject: Re: [pfSense Support] IPSEC behind Firewall On 9/12/06, Alvaro Pietrobono <[EMAIL PROTECTED]> wrote: Hi, It's possible to configure a vpn lan-to-lan with ipsec and pfSense behind firewall? I'm trying some different configurations but unsuccessful. Thanx in advance. pfSense does not have nat traversal support for IPSEC. Doubt it will work. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ((( Internet Email Confidentiality Footer ))) This e-mail, including any attachments, may contain information that is protected by law as privileged and confidential, and is transmitted for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited. If you have received this e-mail in error, please notify immediately the sender by telephone or reply by e-mail, and permanently delete this e-mail from your computer system. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of List Group S.p.A. Besides, the contents of this message shall be understood as neither given nor endorsed by List Group S.p.A. List Group S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC behind Firewall
On 9/12/06, Alvaro Pietrobono <[EMAIL PROTECTED]> wrote: I'm sorry Scott, but I don't explained the problem very well. Pfsense is behind a firewall and I'm trying to establish vpn lan-to-lan with an Ipsec compliant (Cisco Concentrator in this case) with a public ip. Few minutes ago I found the solution and now it's working but I have to ping an host behind the other peer because after few minutes connection goes down. In pfSense if I disable and than enable ipsec, connection goes up again. What do you think about? I would say your MTU is too high. Try changing to 1300 on both pfSense WAN interfaces and see if the situation improves. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
