[pfSense Support] ipsec

[alan walters]

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)
  
 


 

[pfSense Support] ipsec

[alan walters]

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:

 

Localnet    192.168.1.1/24   remotegateway: public
address

Remotenet    0.0.0.0/0   

 

But this works :

 

Localnet    0.0.0.0/0       remotegateway: public
address

Remotenet    192.168.1.1/24

 

Regards.

 

Hope you can help me with this.

[pfSense Support] IPSec

[René Hoppe]

Hi. I try to establish an IPSec Link between pfSense and an Netgear VPN Router.

My pfSense BOX has 1 LAN, 1 WAN and 8 optional Interfaces, when I setup the 
tunnel with the LAN subnet behind everything is working fine, but when I setup 
the tunnel with one of the optional interfaces subnet's behind the tunnel is 
not working (pfSense don't "try" to send the packets in the tunnel)

 

What can I do?

 

Thanx Rene

 

 

[pfSense Support] IPSEC

[Richard Sperry]

Has anyone had any luck in making a IPSEC connection from an PFsense to ISA 
2004?  I need to do this for 6 branches in a few weeks, and advice would be 
nice.


Richard Sperry
Director of Operations
WrinkleBrain, Inc.
[EMAIL PROTECTED]
206.729.4799 x13

MCP - Small Business Specialist
WOT - Thawte Notary
InfraGard - US Homeland Security

CONFIDENTIALITY NOTICE: The information in this electronic mail transmission is 
legally privileged and confidential information intended only for the use of 
the individual or entity named above.  If the reader of this message is not the 
intended recipient, you are hereby notified that any dissemination, 
distribution or copying of the transmission is strictly prohibited. If you have 
received this transmission in error, please delete the message and immediately 
notify us by telephone at 206.729.4799 or by responding to this email.  If this 
email is signed or encrypted you may not forward to another party with out 
written permission in a signed email.

Recycle Notice:  This email was sent using recycled electrons.







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[pfSense Support] IPSEC

[Anil Garg]

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

[Scott Ullrich]

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]

[pfSense Support] IPSec Problem

[Brian]

I had been trying to set up mobile IPSec to use from my laptop, but was 
having issues, so I decided to just try straight IPSec from my office to 
home (both on pfSense 0.74.6).  Both are on dynamic IPs, but for the 
purposes of this exercise, I set the home pfSense to be the 'static' 
side.  This leads me to a question though:


Could the IPSec tunnel setup be changed to allow a DNS name to be used 
for the remote gateway?  Even if pfSense just resolved the name for you 
each time the tunnel was established that would allow people to use 
dyndns names for the endpoints without needing to edit the tunnel each time.


As I said, for now I just pretended that my home IP was static and set 
up the tunnel using Holger's tutorial as a guide.  When I try to 
establish the tunnel from work to home, I get the following entries in 
my IPSec log.  I know it must be something silly since others have many 
tunnels working, but I can't get this sorted out.


Are there any ports I need to forward or open for this to work?

Is is possible that Verizon (my ISP for work and home) blocks ports for 
IPSec?


Thanks for any help you can provide.  I'm also on IRC as DungaBee if 
anyone wants to chat real time.


Thanks much,
Brian

Here are the log entries:
Aug 10 08:50:54 racoon: ERROR: no address could be bound.
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address 
192.168.100.1[500] (Address already in use).
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%dc0[500] (Address already in use).
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:7078%dc1[500] (Address already in use).
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address 127.0.0.1[500] 
(Address already in use).
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address ::1[500] 
(Address already in use).
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address 
fe80::1%lo0[500] (Address already in use).
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address 
70.17.189.123[500] (Address already in use).
Aug 10 08:50:54 	racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%ng0[500] (Address already in use).

Aug 10 08:50:54 last message repeated 2 times
Aug 10 08:50:54 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 10 08:50:54 	racoon: INFO: @(#)This product linked OpenSSL 0.9.7e 25 
Oct 2004 (http://www.openssl.org/)
Aug 10 08:50:54 	racoon: INFO: @(#)ipsec-tools 0.6 
(http://ipsec-tools.sourceforge.net)

Aug 10 08:50:54 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 10 08:50:06 racoon: ERROR: no address could be bound.
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address 
192.168.100.1[500] (Address already in use).
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%dc0[500] (Address already in use).
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:7078%dc1[500] (Address already in use).
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address 127.0.0.1[500] 
(Address already in use).
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address ::1[500] 
(Address already in use).
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address 
fe80::1%lo0[500] (Address already in use).
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address 
70.17.189.123[500] (Address already in use).
Aug 10 08:50:06 	racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%ng0[500] (Address already in use).

Aug 10 08:50:06 last message repeated 2 times

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [pfSense Support] ipsec

[Scott Ullrich]

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

[alan walters]

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

[alan walters]

> 
> 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

[jonathan gonzalez]

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

[alan walters]

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

[jonathan gonzalez]

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

[alan walters]

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

[Scott Ullrich]

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]

[pfSense Support] ipsec issues

[alan walters]

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

[pfSense Support] ipsec issues

[alan walters]

 
  
  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

[pfSense Support] IPSec Problems

[John Cianfarani]

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[500]
Jan 16 10:16:01 gw-remote1 racoon: INFO: begin Aggressive mode.
Jan 16 10:16:32 gw-remote1 racoon: ERROR: phase2 negotiation failed due
to time up waiting for phase1. ESP ce.nt.ral.ip[0]->re.mo.te.ip[0] 
Jan 16 10:16:32 gw-remote1 racoon: INFO: delete phase 2 handler.
Jan 16 10:17:00 gw-remote1 racoon: INFO: request for establishing
IPsec-SA was queued due to no phase1 found.
Jan 16 10:17:01 gw-remote1 racoon: ERROR: phase1 negotiation failed due
to time up. ea11cee6415ca5ef:
Jan 16 10:17:31 gw-remote1 racoon: ERROR: phase2 negotiation failed due
to time up waiting for phase1. ESP ce.nt.ral.ip[0]->re.mo.te.ip[0] 
Jan 16 10:17:31 gw-remote1 racoon: INFO: delete p

[pfSense Support] IPSec Problem

[Pedro Paulo de Magalhaes Oliveira Junior]

Here is the results of my IPSec from previous e-mail

It seems that SAD are “floating”

Is it related with with 0.6.4?

 

# echo "dump;" | setkey -c

The result of line 1: No SAD entries.

# echo "dump;" | setkey -c

The result of line 1: No SAD entries.

# echo "dump;" | setkey -c

The result of line 1: No SAD entries.

# echo "dump;" | setkey -c

200.204.120.145 200.179.214.104

    esp
mode=tunnel spi=79729560(0x04c09398) reqid=20453(0x4fe5)

    E:
3des-cbc  a900049a 63eb4212 2c83625a 2b3c6ba2 47adc0b4 af9f1aa7

    A:
hmac-sha1  8b8c2148 dda1ea67 871b9b4a 3cd6b70c eba51f0c

   
seq=0x0004 replay=4 flags=0x state=mature

    created:
Jan 17 16:06:56 2006   current: Jan 17 16:07:05 2006

    diff:
9(s)  hard: 86400(s)  soft: 69120(s)

    last: Jan
17 16:07:04 2006  hard:
0(s)  soft: 0(s)

    current:
448(bytes) hard: 0(bytes)  soft: 0(bytes)

    allocated:
4    hard: 0 soft: 0

    sadb_seq=1
pid=87725 refcnt=2

200.179.214.104 200.204.120.145

    esp
mode=tunnel spi=141064572(0x0868797c) reqid=20454(0x4fe6)

    E:
3des-cbc  83d26e28 43b9bdfa 5dd5fef9 7a4dd104 8ee8edaa cf32eefb

    A:
hmac-sha1  0dbf4b06 568b1312 d05bfa35 de71d991 bd701e6d

    seq=0x
replay=4 flags=0x state=mature

    created:
Jan 17 16:06:56 2006   current: Jan 17 16:07:05 2006

    diff:
9(s)  hard: 86400(s)  soft: 69120(s)

    last: Jan
17 16:07:04 2006  hard:
0(s)  soft: 0(s)

    current:
240(bytes) hard: 0(bytes)  soft: 0(bytes)

    allocated:
3    hard: 0 soft: 0

    sadb_seq=0
pid=87725 refcnt=1

# echo "dump;" | setkey -c

# echo "dump;" | setkey -c

200.204.120.145 200.179.214.104

    esp
mode=tunnel spi=207500804(0x0c5e3604) reqid=20455(0x4fe7)

    E:
3des-cbc  515a79d0 22fc55d5 fa4c619c 7e603b35 8533b85e d87e658a

    A:
hmac-sha1  2aa06e6d 796b1e8c ec5147f3 d36ea746 ab676688

    seq=0x0001
replay=4 flags=0x state=mature

    created:
Jan 17 16:07:13 2006   current: Jan 17 16:07:18 2006

    diff:
5(s)  hard: 86400(s)  soft: 69120(s)

    last: Jan
17 16:07:18 2006  hard:
0(s)  soft: 0(s)

    current:
112(bytes) hard: 0(bytes)  soft: 0(bytes)

    allocated:
1    hard: 0 soft: 0

    sadb_seq=1
pid=88013 refcnt=2

200.179.214.104 200.204.120.145

    esp mode=tunnel
spi=125972949(0x078231d5) reqid=20456(0x4fe8)

    E:
3des-cbc  65f17755 dbb290ec eb71744d ad09f2b2 35d4765b c0b8c41c

    A:
hmac-sha1  4937f2d8 4a449373 d7016d9d 230ef1a8 98b08fd1

   
seq=0x replay=4 flags=0x state=mature

    created:
Jan 17 16:07:13 2006   current: Jan 17 16:07:18 2006

    diff:
5(s)  hard: 86400(s)  soft: 69120(s)

   
last:  
hard: 0(s)  soft: 0(s)

    current:
0(bytes)   hard: 0(bytes)  soft: 0(bytes)

    allocated:
0    hard: 0 soft: 0

    sadb_seq=0
pid=88013 refcnt=1

# echo "dump;" | setkey -c

200.204.120.145 200.179.214.104

    esp
mode=tunnel spi=8108862(0x007bbb3e) reqid=20459(0x4feb)

    E:
3des-cbc  b4d9ac9e 2ed6fed8 73352152 b263db7c b8972025 10c9a4af

    A:
hmac-sha1  a75d45ec 88c3f948 8701b8cd 59f8cb7a 93a4cf34

   
seq=0x replay=4 flags=0x state=mature

    created:
Jan 17 16:07:44 2006   current: Jan 17 16:07:46 2006

    diff:
2(s)  hard: 86400(s)  soft: 69120(s)

   
last:  
hard: 0(s)  soft: 0(s)

    current:
0(bytes)   hard: 0(bytes)  soft:
0(bytes)

    allocated:
0    hard: 0 soft: 0

    sadb_seq=1
pid=88591 refcnt=1

200.179.214.104 200.204.120.145

    esp
mode=tunnel spi=1917404(0x001d41dc) reqid=20460(0x4fec)

    E:
3des-cbc  5096d8e0 0fd681bb 4f423656 fe2e1713 8533d150 38c06245

    A:
hmac-sha1  f1325d52 bdd5ff9c 18e49ee2 a241c177 729b9086

    seq=0x
replay=4 flags=0x state=mature

    created:
Jan 17 16:07:44 2006   current: Jan 17 16:07:46 2006

    diff:
2(s)  hard: 86400(s)  soft: 69120(s)

   
last:  
hard: 0(s)  soft: 0(s)

    current:
0(bytes)   hard: 0(bytes)  soft:
0(bytes)

    allocated:
0    hard: 0 soft: 0

    sadb_seq=0
pid=88591 refcnt=1

# echo "dump;" | setkey -c

The result of line 1: No SAD entries.

# echo "dump;" | setkey -c

The result of line 1: No SAD entries.

# echo "dump;" | setkey -c

The result of line 1: No SAD entries.

# echo "dump;" | setkey -c

The result of line 1: No SAD entries.

# echo "dump;" | setkey -c

200.204.120.145 200.179.214.104

    esp
mode=tunnel spi=263104984(0x0faea9d8) reqid=20463(0x4fef)

    E:
3des-cbc  e0d2bd58 c63dc210 ed18ad1e 58f77eb2 0ffaa5ff 04917dab

    A:
hmac-sha1  bc719ae0 58892e01 54792ad1 69409e2e e26be914

    seq=0x0007
replay=4 flags=0x state=mature

    created:
Jan 17 1

[pfSense Support] IPSec Testing

[John Cianfarani]

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:00    racoon:
INFO: initiate new phase 1 negotiation: a.a.a.a[500]<=>z.z.z.z[500]

Feb 19 20:58:00    racoon:
INFO: begin Aggressive mode.

Feb 19 20:58:31    racoon:
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:31    racoon:
INFO: delete phase 2 handler.

Feb 19 20:59:00    racoon:
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

[pfSense Support] IPSEC questions

[Quirino Santilli]

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?

2) is it possible it deactivate it?

3) does pfSense automatically understand that the other side is offering
a non compressed 3des policy?

I hope this will help in troubleshooting.

Rino

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[pfSense Support] IPSEC VPN

[Craig Wiltshire]

I need to configure IPSEC VPN on OPT interfaces as well as WAN, currently no
matter what interface I set in the VPN rules all the ipsec negotiations go
out via the WAN interface thereby causing the VPN setup to fail.

 

Is there a way around this? Also how do I specify multiple networks for a VPN
in many instances I will need to bind multiple networks to VPN tunnels on
both endpoints

 

Cheers

 

Craig Wiltshire

IT Manager

Lochard Ltd

 

* TEL +61 395084917

* CEL +61 439348814

* FAX +61 395001191

* [EMAIL PROTECTED]  

* Craig Wiltshire via Skype  

 

-- 
This email and any attachment(s) is intended only for the use of the
intended recipient(s) and may contain information that is confidential and
privileged. If you are not the intended recipient(s), you are hereby
notified that any dissemination, distribution or copying of this email is
strictly prohibited and may be unlawful. If you have received this email in
error, please notify the sender immediately by return email, 
and destroy the original message together with any copies made of it, 
electronic or printed.



Message  protected by MailGuard: e-mail anti-virus, anti-spam and content 
filtering.
http://www.mailguard.com.au/mg

[pfSense Support] IPSEC Question

[Quirino Santilli]

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.

 

Regards

[pfSense Support] IPSEC VPN

[Anil Garg]

Can anyone help with IPSEC VPN on 1.2 Beta1

I am getting following error and I never got any such error say in last two 
months on this release or on 1.0 earlier...

 There were error(s) loading the rules: pfctl: upper-limit larger than 
interface bandwidth/tmp/rules.debug:27: errors in queue definition pfctl: 
Syntax error in config file: pf rules not loaded - The line in question reads [ 
upper-limit larger than interface bandwidth /tmp/rules.debug]:



No changes have been made to my config file over last 10 months.

Thanks Much
Anil Garg

[pfSense Support] IPSEC error

[Jaye Mathisen]

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]

AW: [pfSense Support] IPSEC

[Fuchs, Martin]

So then go on and use OpenVPN site-to-site... it works woth 2 dynamic
IPs...

 

Dynamic IPs for IPSec will be in 1.3... 

 

Regards,

 

Martin

 

Von: Anil Garg [mailto:[EMAIL PROTECTED] 
Gesendet: Donnerstag, 28. Februar 2008 04:51
An: support@pfsense.com
Betreff: [pfSense Support] IPSEC

 

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

[Matthew Grooms]

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

[Anil Garg]

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

[Bryan Derman]

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

[Anil Garg]

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

[Anil Garg]

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

[Bryan Derman]

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

[Matthew Grooms]

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

[Paul M]

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]

[pfSense Support] ipsec woes

[Jure Pečar]

Helo,

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.

Description:

office1 - two modern PCs, 20/20mbit link, carp setup
office2 - two older PCs, 60/20 link, carp setup
servers - two modern 1U machines, gigabit backbone, carp setup
for comparison, my home really old pc on 2mbit link

All these four locations are attached to different ISPs.

Office1 needs ipsec tunnel to servers and to subnet in office2. I have
tunnels from home to servers and to office1.

All ipsec tunnels are set up in the same way: aggresive negotiation, AES
encryption, preshared key, sha1 hash, dh key group 5, lifetime >=6h. Yet
all behave differently:

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.

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.

home to servers: no problems whatsoever.
home to office1: doesn't work at all.

Before I dive into ipsec docs and logs, I'd like to ask if there is
anything I should check between ISPs to see if they're somehow interfering
with our tunnels. I find it confusing that different tunnels, set up in the
same way, behave differently.


-- 

Jure Pečar
http://jure.pecar.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[pfSense Support] IPSec crl

[Fuchs, Martin]

von unterwegs gesendet ...

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org

[pfSense Support] IPSec crl

[Fuchs, Martin]

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 ?

Regards, Martin=

[pfSense Support] ipsec more info

[alan walters]

Is it possible to route all
traffic from opt1 across an ipsec vpn.

 

Or is there anyway to encapsulate
traffic somehow else.

 

 

What I am trying to achieve is
routing some remote sites we have back into our primary backbone.

We are having problems with DOS
attacks on these sites. So we where planning to route them to our primary 100 mbps
backbone

And mask them with our public
IP addresses there. This would consolidate our services much better and allow for
easier management as our 

Primary upstream is far more supportive.

 

I know it is way off topic but
I would love some feedback

AW: [pfSense Support] IPSec Problem

[Holger Bauer]

>From what I can tell from the log something is missconfigured as there are 
>loopbackadresses and it has problems to use an Interface for the outgoing 
>connection (only had a very very quick look, not much time atm). Maybe you can 
>post your ipsec-config and your local networks of both sides.

DynDNS.Names should already be usable for both endpoints (was implemented 
several versions ago). Have you tried it or only assumed that it is not 
possible?

Holger

-Ursprüngliche Nachricht-
Von: Brian [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 10. August 2005 15:18
An: support@pfsense.com
Betreff: [pfSense Support] IPSec Problem


I had been trying to set up mobile IPSec to use from my laptop, but was 
having issues, so I decided to just try straight IPSec from my office to 
home (both on pfSense 0.74.6).  Both are on dynamic IPs, but for the 
purposes of this exercise, I set the home pfSense to be the 'static' 
side.  This leads me to a question though:

Could the IPSec tunnel setup be changed to allow a DNS name to be used 
for the remote gateway?  Even if pfSense just resolved the name for you 
each time the tunnel was established that would allow people to use 
dyndns names for the endpoints without needing to edit the tunnel each time.

As I said, for now I just pretended that my home IP was static and set 
up the tunnel using Holger's tutorial as a guide.  When I try to 
establish the tunnel from work to home, I get the following entries in 
my IPSec log.  I know it must be something silly since others have many 
tunnels working, but I can't get this sorted out.

Are there any ports I need to forward or open for this to work?

Is is possible that Verizon (my ISP for work and home) blocks ports for 
IPSec?

Thanks for any help you can provide.  I'm also on IRC as DungaBee if 
anyone wants to chat real time.

Thanks much,
Brian

Here are the log entries:
Aug 10 08:50:54 racoon: ERROR: no address could be bound.
Aug 10 08:50:54 racoon: ERROR: failed to bind to address 
192.168.100.1[500] (Address already in use).
Aug 10 08:50:54 racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%dc0[500] (Address already in use).
Aug 10 08:50:54 racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:7078%dc1[500] (Address already in use).
Aug 10 08:50:54 racoon: ERROR: failed to bind to address 127.0.0.1[500] 
(Address already in use).
Aug 10 08:50:54 racoon: ERROR: failed to bind to address ::1[500] 
(Address already in use).
Aug 10 08:50:54 racoon: ERROR: failed to bind to address 
fe80::1%lo0[500] (Address already in use).
Aug 10 08:50:54 racoon: ERROR: failed to bind to address 
70.17.189.123[500] (Address already in use).
Aug 10 08:50:54 racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%ng0[500] (Address already in use).
Aug 10 08:50:54 last message repeated 2 times
Aug 10 08:50:54 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 10 08:50:54 racoon: INFO: @(#)This product linked OpenSSL 0.9.7e 25 
Oct 2004 (http://www.openssl.org/)
Aug 10 08:50:54 racoon: INFO: @(#)ipsec-tools 0.6 
(http://ipsec-tools.sourceforge.net)
Aug 10 08:50:54 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 10 08:50:06 racoon: ERROR: no address could be bound.
Aug 10 08:50:06 racoon: ERROR: failed to bind to address 
192.168.100.1[500] (Address already in use).
Aug 10 08:50:06 racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%dc0[500] (Address already in use).
Aug 10 08:50:06 racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:7078%dc1[500] (Address already in use).
Aug 10 08:50:06 racoon: ERROR: failed to bind to address 127.0.0.1[500] 
(Address already in use).
Aug 10 08:50:06 racoon: ERROR: failed to bind to address ::1[500] 
(Address already in use).
Aug 10 08:50:06 racoon: ERROR: failed to bind to address 
fe80::1%lo0[500] (Address already in use).
Aug 10 08:50:06 racoon: ERROR: failed to bind to address 
70.17.189.123[500] (Address already in use).
Aug 10 08:50:06 racoon: ERROR: failed to bind to address 
fe80::2a0:ccff:fe53:70cd%ng0[500] (Address already in use).
Aug 10 08:50:06 last message repeated 2 times

-
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]

[pfSense Support] IPSec tunnel errors ...

[DLStrout]

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]

[pfSense Support] ipsec and 0.77

[alan walters]

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]

[pfSense Support] ipsec and tracert

[alan walters]

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

[pfSense Support] ipsec and roadwarrior

[alan walters]

I was just following up some threads about traceroute and
ipsec.

Se below

 

http://www.freeswan.org/freeswan_trees/freeswan-2.04/doc/HowTo.html#no_trace

 

 

this caused me to look a bit further at ‘fastroute’
(is this available in pf, seems to be in mono). It seems that this could 

stop the ttl decrementing and maybe resolve the issue
described in the above article which

is what I have been experiencing on tests.

 

I know that this is only a cosmetic error, but it looks a
little ugly and I would really like to be rid of it.

 

Regards

 

Alan walters

[pfSense Support] IPsec Auto establish

[John Cianfarani]

Been playing around with creating IPSec tunnels to another
pfSense box and I noticed that I can’t seem to get the “Automatically
establish this tunnel” to work at all.

The connection will come up quite quickly as soon as I push
some traffic over the tunnel but never wants to auto establish.

Side A is configured for mobile clients and is a PC with .86
and Side B is a wrap running .90. 

 

If you need any information to help troubleshoot please let
me know what you would need.

 

Thanks

John

Re: [pfSense Support] ipsec issues

[Scott Ullrich]

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

[alan walters]

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

[alan walters]

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

[John Cianfarani]

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

[alan walters]

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

[Scott Ullrich]

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

[alan walters]

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

[Scott Ullrich]

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

[alan walters]

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

[Scott Ullrich]

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

[alan walters]

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

[Vivek Khera]

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

[Scott Ullrich]

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

[Vivek Khera]

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

[Scott Ullrich]

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

[alan walters]

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

[Scott Ullrich]

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

[Vivek Khera]

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

[Vivek Khera]

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

[Scott Ullrich]

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

[Scott Ullrich]

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

[John Cianfarani]

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

[Scott Ullrich]

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

[John Cianfarani]

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

[alan walters]

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]

[pfSense Support] Ipsec issues update

[alan walters]

Title: 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

RES: [pfSense Support] IPSec Problems

[Pedro Paulo de Magalhaes Oliveira Junior]

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[500]
Jan 16 10:16:01 gw-remote1 racoon: INFO: begin Aggressive mode.
Jan 16 10:16:32 gw-remote1 racoon: ERROR: phase2 negotiation failed due
to time up waiting for phase1. ESP ce.nt.ral.ip[0]->re.mo.te.ip[0] 
Jan 16 10:16:32 gw-remote1 racoon: INFO: delete phase 2 handler.
Jan 16 10:17:00 gw-remote1 racoon: INFO: request for establishing
IPsec-SA was queued due to no phase1 found.

Re: [pfSense Support] IPSec Problems

[Scott Ullrich]

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 p

RES: [pfSense Support] IPSec Problems

[Pedro Paulo de Magalhaes Oliveira Junior]

Is the same problem. Racoon is dead.

-Mensagem original-
De: Scott Ullrich [mailto:[EMAIL PROTECTED] 
Enviada em: segunda-feira, 16 de janeiro de 2006 14:07
Para: support@pfsense.com
Assunto: 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] 1

RES: [pfSense Support] IPSec Problems

[Pedro Paulo de Magalhaes Oliveira Junior]

It seems that 0.6.2 is the last working version.

-Mensagem original-
De: Pedro Paulo de Magalhaes Oliveira Junior [mailto:[EMAIL PROTECTED] 
Enviada em: segunda-feira, 16 de janeiro de 2006 14:19
Para: support@pfsense.com
Assunto: RES: [pfSense Support] IPSec Problems

Is the same problem. Racoon is dead.

-Mensagem original-
De: Scott Ullrich [mailto:[EMAIL PROTECTED] 
Enviada em: segunda-feira, 16 de janeiro de 2006 14:07
Para: support@pfsense.com
Assunto: 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 

RE: [pfSense Support] IPSec Problems

[John Cianfarani]

>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

[Scott Ullrich]

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

RES: [pfSense Support] IPSec Problems

[Pedro Paulo de Magalhaes Oliveira Junior]

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)
> 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

RE: [pfSense Support] IPSec Problems

[John Cianfarani]

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

[John Cianfarani]

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

[Scott Ullrich]

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 

RES: [pfSense Support] IPSec Problems

[Pedro Paulo de Magalhaes Oliveira Junior]

I'm experiencing some problems with this IPSEC version.

My tunnel opens lasts sometimes and closes. 

My IPSEC section in both sides:

Side 1: 200.204.120.145
Side 2: 200.179.214.104

Side 1:





wan

lan

192.168.0.0/24
200.179.214.104

aggressive



 
3des
sha1
2
86400
supersecret



 
pre_shared_key


esp
 
3des
 
blowfish
 
cast128
 
rijndael
 
hmac_sha1
 
hmac_md5
0
86400

NetfilterRJ




Side 2:





wan

lan

192.168.1.0/24
200.204.120.145

aggressive



 
3des
sha1
2
86400
bqnsepc



 
pre_shared_key


esp
 
3des
 
blowfish
 
cast128
 
rijndael
 
hmac_sha1
 
hmac_md5
0
86400

Netfilter SP



-Mensagem original-
De: Scott Ullrich [mailto:[EMAIL PROTECTED] 
Enviada em: segunda-feira, 16 de janeiro de 2006 14:24
Para: support@pfsense.com
Assunto: 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 "50

RES: [pfSense Support] IPSec Problems

[Pedro Paulo de Magalhaes Oliveira Junior]

Regarding this e-mail: the shared keys are the same

-Mensagem original-
De: Pedro Paulo de Magalhaes Oliveira Junior [mailto:[EMAIL PROTECTED] 
Enviada em: terça-feira, 17 de janeiro de 2006 15:12
Para: support@pfsense.com
Assunto: RES: [pfSense Support] IPSec Problems

I'm experiencing some problems with this IPSEC version.

My tunnel opens lasts sometimes and closes. 

My IPSEC section in both sides:

Side 1: 200.204.120.145
Side 2: 200.179.214.104

Side 1:





wan

lan

192.168.0.0/24
200.179.214.104

aggressive



 
3des
sha1
2
86400
supersecret



 
pre_shared_key


esp
 
3des
 
blowfish
 
cast128
 
rijndael
 
hmac_sha1
 
hmac_md5
0
86400

NetfilterRJ




Side 2:





wan

lan

192.168.1.0/24
200.204.120.145

aggressive



 
3des
sha1
2
86400
 supersecret




 
pre_shared_key


esp
 
3des
 
blowfish
 
cast128
 
rijndael
 
hmac_sha1
 
hmac_md5
0
86400

Netfilter SP



-Mensagem original-
De: Scott Ullrich [mailto:[EMAIL PROTECTED] 
Enviada em: segunda-feira, 16 de janeiro de 2006 14:24
Para: support@pfsense.com
Assunto: 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 res

[pfSense Support] IPSec BugValidation 5

[Pedro Paulo de Magalhaes Oliveira Junior]

Hi,

 

IPSec issue has been fixed in BugValidation 5.

[pfSense Support] IPSec enhancements ??s

[David Strout]

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.

--
David L. Strout
Engineering Systems Plus, LLC




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [pfSense Support] IPSec Testing

[Bill Marquette]

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

[John Cianfarani]

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

[John Cianfarani]

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

[Bill Marquette]

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

[John Cianfarani]

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

[Peter Curran]

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

[Scott Ullrich]

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

[Peter Curran]

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

[Scott Ullrich]

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

[Peter Curran]

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.

[pfSense Support] IPSEC Firewall Rules

[Brad Bendy]

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]

[pfSense Support] Ipsec Tunnels In

[Justin Wilson]

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]

Re: [pfSense Support] IPSEC questions

[Bill Marquette]

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]

[pfSense Support] IPSEC behind Firewall

[Alvaro Pietrobono]

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.
 
~A
 
 
 
A.PietrobonoList Spa - 
ITALYemail: [EMAIL PROTECTED]web: www.list.it

[pfSense Support] ipsec tunnels & gif

[Eric Masson]

Hello,

From :
http://linux.softpedia.com/get/System/Operating-Systems/Linux-Distributions/pfSense-5550.shtml
PFSense is advertised to support "gif ipsec interface option for 
expanded routing"

I can't find this in the feature list on the following page :
http://pfsense.com/index.php?id=26

Is this feature supported or not ?
Is it is supported :
- Is it an implementation of IIPTran (http://rfc.net/rfc3884.html) ?
- Is it available in embedded image or only in the LiveCD version ?
- Is there any doc (even a sparse one) that could help me getting started ?

Regards

Eric Masson


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[pfSense Support] IPSec - Certificate & Key

[Kelvin Chiang]

I have some problem getting the mobile client to connect to pfsense
using certificate and keys. Can pfsense support self-signed certificate?
 
Kelvin