Sorry if these are very basic steps.

You say 192.168.2.1 is the local end pfsense. Is this a virtual IP on a relevant interface? Is the network mask 24 bit, or something else?

I assume 192.168.3.1 is the remote end pfsense. Is this a virtual IP on a relevant interface? Is the network mask 24 bit? Replace 192.168.3.1 with whatever 192.168.3.x IP the remote end pfsense uses, if different.

When the tunnel is up, try ping from the shell on local end pfsense.

ping -c 1 192.168.2.1
ping -c 1 -S 192.168.2.1 192.168.3.1

Same from remote end shell:
ping -c 1 192.168.3.1
ping -c 1 -S 192.168.3.1 192.168.2.1

The responses from ping could be informative. "Communication prohibited by filter" is logical if the packets leave via the WAN interface, and this interface blocks private networks.

I still have this issue. IPSec tunnel is totally unreliable  :o :-[ :-
[img]http://www.knebb.de/files/pdcdisk.png

Still no one a clue why this happens?

I can post loads of logfiles- but for what do I have to look at?

Thanks

Christian

Yes… just assign the MAC an IP on the DHCP page. The other way to do it is to look at the connected clients (not sure the page) and click on the add icon next to the MAC - takes you directory to the static assignment add page to create an assignment for the MAC.

Thanks for the post. I have done that without any luck

Hy guys, I have 2.1.4-RELEASE (i386)  with ipsec setup using this article https://sites.google.com/a/vorkbaard.nl/dekapitein/tech-1/how-to-set-up-ipsec-tunneling-in-pfsense-2-0-release-for-road-warriors and we have multi wan running ok there's no problem with this.

But we tried to setup the IPSEC for mobile users on both WAN links (interfaces) and we got the same error "Aug 19 21:53:13 racoon: ERROR: phase1 negotiation failed due to time up. 5b96ad517895d3ae:c63d8ac780cdb551"

LAN–----[PFSENSE]–-WAN1(adsl1)---router1------INTERNET
                            ---WAN2(adsl2)---router2------INTERNET

the NAT for UDP port 500 is published on each ADSL router (router1 and router2) sending it to the WAN1, WAN2 interface on the PFSENSE

racoon is on debug mode

Aug 19 21:52:53 racoon: DEBUG: resend phase1 packet 5b96ad517895d3ae:c63d8ac780cdb551
Aug 19 21:53:03 racoon: DEBUG: 388 bytes from 192.168.3.4[500] to 187.21.17.63[500]
Aug 19 21:53:03 racoon: DEBUG: sockname 192.168.3.4[500]
Aug 19 21:53:03 racoon: DEBUG: send packet from 192.168.3.4[500]
Aug 19 21:53:03 racoon: DEBUG: send packet to 187.21.17.63[500]
Aug 19 21:53:03 racoon: DEBUG: 1 times of 388 bytes message will be sent to 187.21.17.63[500]
Aug 19 21:53:03 racoon: DEBUG: 5b96ad51 7895d3ae c63d8ac7 80cdb551 01100400 00000000 00000184 0400003c 00000001 00000001 00000030 01010001 00000028 01010000 80010007 800e0100 80020002 80040002 80030001 800b0001 000c0004 00000e10 0a000084 43b9ab3a 7139d265 84b43c8e 19ce563c 2ac8b945 a989b5ee 295c9eef e37b4ba3 a17746ec 156c2d89 ad5d9858 6148a581 89749a26 065cd632 caf28793 3eadaa47 91e0f90a ea6955ae cdbe5391 42834c26 9dab7264 4099d8cb 8ebbbcc6 d56f72c3 7c41db68 dfd5c715 d69fd0a4 2e60dfb5 ceb5125b 4bec8a75 b025e671 224f5fb3 05000014 e6f8f329 40140f5e 67b43a8a cd642e81 0800000c 011101f4 c0a80304 0d000018 b8a84d9f 9a793eef a6550d5b c89c77b4 f9dcdc24 0d000014 12f5f28c 457168a9 702d9fe2 74cc0100 14000014 4a131c81 07035845 5c5728f2 0e95452f 14000018 7678a363 66455471 f460485d ca10c2d3 b6b78480 0d000018 7678a363 66455471 f460485d ca10c2d3 b6b78480 00000018 4048b7d5 6ebce885 25e7de7f 00d6c2d3 80000000
Aug 19 21:53:03 racoon: DEBUG: resend phase1 packet 5b96ad517895d3ae:c63d8ac780cdb551
Aug 19 21:53:13 racoon: ERROR: phase1 negotiation failed due to time up. 5b96ad517895d3ae:c63d8ac780cdb551
Aug 19 21:53:13 racoon: DEBUG: IV freed

dump capture is

22:05:47.295295 IP 187.21.17.63.500 > 192.168.3.4.500: isakmp: phase 1 I agg
22:05:47.303331 IP 192.168.3.4.500 > 187.21.17.63.500: isakmp: phase 1 R agg
22:05:57.306604 IP 192.168.3.4.500 > 187.21.17.63.500: isakmp: phase 1 R agg
22:06:07.336766 IP 192.168.3.4.500 > 187.21.17.63.500: isakmp: phase 1 R agg
22:06:17.361490 IP 192.168.3.4.500 > 187.21.17.63.500: isakmp: phase 1 R agg
22:06:27.385014 IP 192.168.3.4.500 > 187.21.17.63.500: isakmp: phase 1 R agg

regards,

Thiago

the "pfSsh.php playback svc start racoon" works for me, if I execute it from shell (PuTTY from my pc)

when I issue this command, I can see in the system log: "php: pfSsh.php: Forcefully reloading IPsec racoon daemon" and after 3-4 lost pings, it pings again.

Can you post your script, because I have the same problem with ipsec, and trying to solve it. But I'm really rookie in scripting.  ::)

Thank you very much!  :)

Finally found the answer:  Set NAT Traversal to Force

Thanks to Vorkbaard:  https://forum.pfsense.org/index.php?topic=46917.0

Dials out?

If a VPN tunnel isn't up already, it is triggered by the traffic destined for the other site.

You do need to have a known WAN address on your home router, either a static ip or a DDNS-updated hostname if you're on a dynamic ip (DHCP).

Right so I figured out why it was sometimes working and sometimes not.

When I do confguration changes to ipsec - pfsense removes my static host route and replaces it with own.
i.e after I do configuration changes to ipsec i have to:
make a new static route
delete the static route pfsense automatically added.

In case of just restarting ipsec pfsense does not delete my static route
i.e after restarting racoon i just need to purge the route pfsense added during the racoon restart.

Ok workaround for my test setup, but it would be preferable if possible to define a gateway e.g. in the phase1 configuration.

Cheers / Thor

Thanks breakaway for your reply.

It looks like you are correct.
The problem seems to be that racoon does not accept wildcards(ran racoon with verbose and debug in a terminal) regarding incoming connections when matching with the PSK(running PSK during tests).

There is a simple patch for allowing wildcards, but once I compile it, it won't start on pfSense due to something missing.
It looks like I will need to get a older FreeBSD that matches pfSense 2.1.4 and try to compile on that.

Performance depends on the CPU that it has available.

Stability would be more up to the Sonicwall sides than pfSense.

We've had people running 300+ tunnels on pfSense before without issue (I believe they were almost entirely Draytek routers on the other side). It's not a problem with pfSense in general, but might be with your specific implementation.