L2TP on its own is only an unencrypted tunneling protocol.

For your applications, TINC is better - But a pfsense openvpn client with a TAP interface can do it. I really only use openvpn for "road warrior" type configurations on end clients. I think thats what it does best. But it is flexible and if you handle routing correctly you can get what you want from it.

Logs? Look at the gateway and gateway monitoring on both sides of the tunnel, apinger might be an issue–-

maybe, somebody have manual on connect freebsd (pfsense) to ipsec+xl2tpd (l2tp) server as client? i have server host, username, password and pks key

Yes should be possible. on the pfsense side it should work, I don't know the TL-R600VPN router. I have the somewhat the same setup, only the other end is a computer.

Froussy can you please show some screenshots of how you configured this? I think I might be having a similar problem with my site-to-site vpn… thanks

Is this bug fixed as of 2.1.4? I have one IPSEC tunnel that always seems to go down after a while, and nothing short of fully rebooting the router gets it running again.  This is an APU2 router in our office that's running 2.1.4, tunneling into our DC which also runs pfSense.  The DC router has 5 IPsec tunnels set up on it, all configured the same way - only this one seems problematic.

skyebrenzo, did you set up appropriate phase2 entries? I.e., at site1, you'll want a phase 2 with local = road warrior IP range, remote = site2 IP range, and at site2 the other way around (local = site2 range, remote = road warrior range).

Thanks, Thor! The tunnels have remained pretty stable for the past few days since I relaxed DPD's tolerances, so I'm keeping my fingers crossed.  However, if they start to flake out on me again, that is my next step  :)

Maybe this post can help you: https://forum.pfsense.org/index.php?topic=69771.msg437477#msg437477

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