Hot answers tagged

3

The cause of the issue was that the version of racoon in CentOS (ipsec-tools-0.6.5) appeared to have a bug with regards to properly re-keying. I compiled the latest ipsec-tools from source and the problem has not recurred as a result. TL;DR - Upgrade ipsec-tools first before banging your head repeatedly on the wall.


3

For anyone looking for resolution try this reference: http://forum.pfsense.org/index.php?topic=44895.0 "To resolve this issue disable NAT-T (when pfsense holds the public IP). If that still does not help disable DPD and set 'Negotiation Mode' in Phase 1 to main"


2

If you didn't tweak MTU, you may have post-fragmentation issues (fragmentation occuring after encryption) that is well explained in this documentation: http://www.cisco.com/c/en/us/td/docs/interfaces_modules/services_modules/vspa/configuration/guide/ivmsw_book/ivmvpnb.html#wp2047965 You should try to reduce MTU inside the tunnel by 82 bytes (GRE + IPSec ...


2

I found it... The phase1-up.sh script contains at the end the following lines: 44 # 45 # XXX This is a workaround for Linux forward policies problem. 46 # Someone familiar with forward policies please fix this properly. 47 # 48 echo " 49 spddelete 0.0.0.0/0[any] ${INTERNAL_ADDR4}[any] any 50 -P fwd ipsec esp/tunnel/${REMOTE}-${LOCAL}/require; 51 " | ...


1

It is probably the security associations going out of sync due little hiccups in the internet connection. Next time it happens, have a look at "status > ipsec > sad". Start pinging the other host, if it is timing out and there are more than 2 (one for each side) then try deleting the dead "data" SAD's, and see if your pings start again. This was very common ...


1

Most likely, the 10.3.5.0/24 network doesn't know who you are and how to get to you. You need to add the route for 10.8.0.0/24 with gateway 10.7.8.129 to the router for the 10.3.5.0/24 network. You may also need to add an IPSEC rule to encrypt traffic destined for 10.8.0.0/24. Additional routes may also be required, depending on your network topology.


1

You have to configure openvpn to push the IPSEC routes to openvpn clients. in your "server.conf" file add on line like this for each network you want to make accessible: push "route w.x.y.z 255.255.255.0" disclaimer: the w.x.y.z and the network mask must be adapted to your configuration. Also note that this way the packets from your laptop will go to the ...


1

You could auto-start IPSEC tunnel before any traffic starts to flow (usually those first dropped packets initiate the IKE negotiation). Here is how to do that with StrongSwan: auto = ignore | add | route | start what operation, if any, should be done automatically at IPsec startup; currently-accepted values are add, route, ...


1

You need the corresponding policy on the server as well. Just replace the in and out on the client policy, put it on the server and it should work fine even with remote anonymous.


1

Racoon is probably regenerating your conf every time it is restarted and eventually reads it from /var/lib/racoon/racoon.fr To change this behaviour, on Ubuntu, modify your /etc/default/racoon to CONFIG_MODE="direct" (rather than CONFIG_MODE="racoon-tool" ). Then, restart racoon.


Only top voted, non community-wiki answers of a minimum length are eligible