O…....thx!!!! when i use my IP address, is ok!!!!!!!
thank you very much

The IPSEC Rule Tab controls all incoming ipsec traffic, the LAN Rule Tab controls all outgoing traffic from LAN to WAN/IPSEC or anything else, so if pfsense doesn´t reply your ping request from the netgear vpn you a need a rule at the ipsec tab, allow all for example from "netgears lan" to "pfsense lan"….

@hoba:

Please provide more info on your settings for the tunnel.

I ment NAT-T. This is a thing wich ist normally only interessting for Client behind a nating router but that is not the point.

I also tried aggressiv mode but the other side (GreenGate VPN) does not support the aggressiv mode.

The IP keepalive settings are filled with an IP Address out of the remote network. That works, but i get a lot of errors in the LOG:

–-
Apr 26 08:59:43 racoon: [ITXTRA]: NOTIFY: the packet is retransmitted by 217.5.211.238[500].
Apr 26 08:59:34 racoon: [ITXTRA]: INFO: phase2 sa deleted 80.135.97.34-217.5.211.238
Apr 26 08:59:33 racoon: INFO: received Vendor ID: DPD
Apr 26 08:59:33 racoon: INFO: begin Identity Protection mode.
Apr 26 08:59:33 racoon: [ITXTRA]: INFO: initiate new phase 1 negotiation: 80.135.97.34[500]<=>217.5.211.238[500]
Apr 26 08:59:33 racoon: [ITXTRA]: INFO: IPsec-SA request for 217.5.211.238 queued due to no phase1 found.
Apr 26 08:59:33 racoon: [ITXTRA]: INFO: phase2 sa expired 80.135.97.34-217.5.211.238
Apr 26 08:59:10 racoon: [ITXTRA]: INFO: phase2 sa deleted 80.135.97.34-217.5.211.238
Apr 26 08:59:09 racoon: ERROR: phase1 negotiation failed due to time up. e63213fe82189065:86f78315af7fd679
Apr 26 08:59:09 racoon: INFO: request for establishing IPsec-SA was queued due to no phase1 found.
Apr 26 08:59:09 racoon: [ITXTRA]: INFO: phase2 sa expired 80.135.97.34-217.5.211.238
Apr 26 08:58:48 racoon: [ITXTRA]: NOTIFY: the packet is retransmitted by 217.5.211.238[500].
Apr 26 08:58:45 racoon: [ITXTRA]: INFO: phase2 sa deleted 80.135.97.34-217.5.211.238
Apr 26 08:58:44 racoon: INFO: request for establishing IPsec-SA was queued due to no phase1 found.
Apr 26 08:58:44 racoon: [ITXTRA]: INFO: phase2 sa expired 80.135.97.34-217.5.211.238
Apr 26 08:58:28 racoon: [ITXTRA]: NOTIFY: the packet is retransmitted by 217.5.211.238[500].
Apr 26 08:58:20 racoon: [ITXTRA]: INFO: phase2 sa deleted 80.135.97.34-217.5.211.238
Apr 26 08:58:19 racoon: INFO: received Vendor ID: DPD
Apr 26 08:58:19 racoon: INFO: begin Identity Protection mode.
Apr 26 08:58:19 racoon: [ITXTRA]: INFO: initiate new phase 1 negotiation: 80.135.97.34[500]<=>217.5.211.238[500]
Apr 26 08:58:19 racoon: [ITXTRA]: INFO: IPsec-SA request for 217.5.211.238 queued due to no phase1 found.
Apr 26 08:58:19 racoon: [ITXTRA]: INFO: phase2 sa expired 80.135.97.34-217.5.211.238
Apr 26 08:57:57 racoon: [ITXTRA]: INFO: phase2 sa deleted 80.135.97.34-217.5.211.238
Apr 26 08:57:57 racoon: ERROR: phase1 negotiation failed due to time up. 8c6ed753b3823d42:86f78315af7fd679
Apr 26 08:57:56 racoon: INFO: request for establishing IPsec-SA was queued due to no phase1 found.
Apr 26 08:57:56 racoon: [ITXTRA]: INFO: phase2 sa expired 80.135.x.x-217.5.x.x
Apr 26 08:57:36 racoon: [ITXTRA]: NOTIFY: the packet is retransmitted by 217.5.x.x[500].
Apr 26 08:57:33 racoon: [Self]: INFO: 192.168.13.126[500] used as isakmp port (fd=23)
Apr 26 08:57:33 racoon: INFO: fe80::20d:b9ff:fe12:a388%vr0[500] used as isakmp port (fd=22)
Apr 26 08:57:33 racoon: INFO: fe80::20d:b9ff:fe12:a389%vr1[500] used as isakmp port (fd=21)
Apr 26 08:57:33 racoon: [Self]: INFO: 10.0.0.254[500] used as isakmp port (fd=20)
Apr 26 08:57:33 racoon: INFO: fe80::20d:b9ff:fe12:a38a%vr2[500] used as isakmp port (fd=19)
Apr 26 08:57:33 racoon: [Self]: INFO: 127.0.0.1[500] used as isakmp port (fd=18)
Apr 26 08:57:33 racoon: INFO: ::1[500] used as isakmp port (fd=17)
Apr 26 08:57:33 racoon: INFO: fe80::1%lo0[500] used as isakmp port (fd=16)
Apr 26 08:57:33 racoon: INFO: fe80::20d:b9ff:fe12:a388%ng0[500] used as isakmp port (fd=15)
Apr 26 08:57:33 racoon: [Self]: INFO: 80.135.x.x[500] used as isakmp port (fd=14)
–-

@80.135.x.x:57306 #612939: probable authentication (preshared secret) failure: malformed payload in packet Apr 26 07:01:50 authpriv.warn Pluto[299]: "94:85"
@80.135.x.x:57306 #612939: next payload type of ISAKMP Identification Payload has an unknown value: 215 Apr 26 07:01:50 authpriv.warn Pluto[299]: "94:85"
@80.135.x.x:57306 #612939: probable authentication (preshared secret) failure: malformed payload in packet Apr 26 07:01:55 authpriv.warn Pluto[299]: "94:85"
@80.135.x.x:57306 #612929: max number of retransmissions (2) reached STATE_MAIN_R2 Apr 26 07:02:00 authpriv.warn Pluto[299]: "94:85"
@80.135.x.x:57306 #612939: next payload type of ISAKMP Identification Payload has an unknown value: 215 Apr 26 07:02:00 authpriv.warn Pluto[299]: "94:85"
@80.135.x.x:57306 #612939: probable authentication (preshared secret) failure: malformed payload in packet

–-

As alternativ a little script on the pFsense box would work very well, that would check the WAN ip in a regulary interval an if the IP changes the script only has to change on of my interface to LAN save, apply the settings and switch it directly back to wan save it and apply it.

These are the steps i do right know and it works.

Not sure how you test this but make sure that you test the connectivity from behind the pfSense. The pfSense itself can't make use of the tunnel unless you add some fake static route.

Good to hear, thanks  :)

I don't think so. Maybe with the pfflowd package and something external but not with pfSense built in features.

I have an update on this.  it seems that my remote subnet entry was /16, while the actual remote subnet was /22…

the debugging on the cisco was way more helpful in determining the problem at the end of the day.  for those in a similar situation you will need to run the following on a PIX/ASA to see what you need.
debug crypto isakmp

THEN.  i got a ping ready on pfsene, to ping the inside address of the remote endpoint (after creating firewall rules) and did the following
terminal monitor
-execute ping on pfsense now.
-after you see the Group = xxxx  entry in the logs and think you have what you need
terminal no monitor

this will keep it from scrolling off your buffer until you can figure our what it going on.

damned you are right, so blind I am. Thanks a lot Hoba, I was looking for somehting more difficult than it is…

Hello, The service is up and running after I setup the WAN interfaces. Was my mistake. It was for the first time when I had to setup a VPN. Noe I know what I did wrong!  ;) The VPN now is running. Thank you!

Lucian

There are two pfSenses. This morning I succeed to configure the VPN. Was my mistake. I try to configure the VPN with both pfsenses on the same switch. I used a crossover LAN cable and everything is ok. I didn' had tho switches. Thank you  all of you for your help. This was my first time when I setup an IPSEC VPN.

Lucian

@Stoney32:

this is the syslog for pfsense

racoon: ERROR: phase1 negotiation failed due to time up. f4a68900f9a99c27:42b5b53ba608ead3
racoon: ERROR: fatal INVALID-ID-INFORMATION notify messsage, phase1 should be deleted.
racoon: INFO: received Vendor ID: CISCO-UNITY
racoon: INFO: received Vendor ID: DPD
racoon: INFO: received broken Microsoft ID: FRAGMENTATION
racoon: INFO: received Vendor ID: RFC 3947
racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
racoon: INFO: begin Aggressive mode.
racoon: [Unknown Gateway/Dynamic]: INFO: respond new phase 1 negotiation: 192.168.10.1[500]<=>192.168.10.254[500]

Can you try that from a different WAN? Looks like you have some mtu issues there. Maybe try lowering the mtu at interfaces>wan at the box that your client is behind.

You don't have to setup firewallrules for IPSEC to work. This is done behind the scenes when enabling IPSEC. However, you have to setup rules for traffic coming through the tunnel (firewall>rules, ipsec tab) but that'S the next step. This wouldn't prevent the tunnel from being established but block traffic that is coming though the tunnel once it is establiched.

Try a traceroute from your lan to the customers lan to see if the packets go through the tunnel. If you don't see the gateway of your ISP there it goes through the tunnel (diagnostics>states should show you that as well). Maybe your customer has his firewallrules not set up correctly and though the tunnel is established you are blocked at their end.

I woke up this morning (afternoon actually) after beating my head against the wall last night and tunnels were working…

Turns out that raccoon crashed (there was a core dump in the root directory, which I didn't even think about and deleted), which most likely corrupted the IPSec state entries.  Normally rebooting would have fixed this, however since I had pfSync on, the two boxes just passed the bad entries back and forth... :)

Had I thought to reset the state tables, it probably would have started working immediately.  Luckily the IPSec timer was only 6 hours so after sleeping all was good.

Roy

(I know this is old, but it is exactly the problem I am having.)

I am running pfSense 1.2.  Connecting to a Netgear fvs124.  The connection works perfectly until the SA times out.  Basically, the exact same problem that was described above.  A reboot of pfSense takes care of the problem.

Any other suggestions?  (checked the firewall logs.  UDP 500 and ESP are getting through fine.)

EDIT-

Semi-resolved.  Turns out the problem is the netgear firewall.  Will be replacing it with pfSense on Satuday.  OpenVPN is far superior.

Thought so.

Thanks for the input.

This is not enough information to even make a guess what'sw going wrong. Please provide what you tried to setup, maybe some screenshots from the webguis of both devices and logs.

I'll give this a shot!!!  Update…  That worked perfect!

Awesome!!!

@heiko:

One Option
You need for example two tunnels

LAN –> LAN  --> with phase 1 = User FQDN => lan@ipsec.de (any fantasy FQDN)
LAN --> DMZ --> with pahse 1 = User FQDN => dmz@ipsec.de (any fantasy FQDN)

But, this runs for me not in the main mode only aggressive....

Greetings
Heiko
P.S. thx hoba

if you have a vista client, then you need the latest shrew beta version, the last stable didn´t run on vista and ends with a BSOD….

Greetings
Heiko

the only difference with the new location was 1.2 release version.  I have just downgraded to 1.2 rc2 to get things rolling. tunnel is up and running 
thanks for all the help, and I do apologize for switching it out. I needed to get it going.