Question

I observed some strange behaviour while trying to create ipsec connection. I configured ipsec between cisco asa and my Linux box and it works as expected. But when I restart the network service on my Linux box or restart the port on the cisco side, the tunnel stops working but tunnel status is up:

/etc/init.d/ipsec status
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
IPsec running  - pluto pid: 2684
pluto pid 2684
1 tunnels up
some eroutes exist

When I try to connect to the other side (telnet, ping, ssh), the connection doesn't work.

My /etc/ipsec.conf looks like this:

# /etc/ipsec.conf - Openswan IPsec configuration file
#
# Manual:     ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        # plutodebug="control parsing"
        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
        protostack=netkey
        nat_traversal=yes
        virtual_private=
        oe=off
        # Enable this if you see "failed to find any available worker"
        nhelpers=0

#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and uncomment this.
include /etc/ipsec.d/*.conf

And my /etc/ipsec.d/myvpn.conf looks like this:

conn myvpn
        authby=secret                # Key exchange method
        left=server-ip                     # Public Internet IP address of the
                                     # LEFT VPN device
        leftsubnet=server-ip/32            # Subnet protected by the LEFT VPN device
        leftnexthop=%defaultroute    # correct in many situations
        right=asa-ip                 # Public Internet IP address of
                                     # the RIGHT VPN device
        rightsubnet=network/16       # Subnet protected by the RIGHT VPN device
        rightnexthop=asa-ip          # correct in many situations
        auto=start                   # authorizes and starts this connection
                                     # on booting
        auth=esp
        esp=aes-sha1
        compress=no

When I restart the openswan service everything starts working, but i think there should be some logic that does this automatically. has anyone an idea what i am missing?

Était-ce utile?

La solution

You probably want to enable dead peer detection if available on both sides. Dead peer detection notices when the tunnel isn't actually working anymore and disconnects or resets it.

If not available, you can also try changing your session renegotiation time down very low; your tunnel will create new keys frequently and set up new tunnels to replace the old ones on a regular basis effectively recreating the tunnel after that timeout when the session has gone down.

For PPP sessions on Linux myself, I simply have a "service ipsec restart" in /etc/ppp/ip-up.local to restart all tunnels whenever the PPP device comes back online.

YMMV.

Autres conseils

Just try DPD, but not work.

So I just learned from mikebabcock.

add the following line in my /etc/ppp/ip-down

service ipsec restart

With this workaround, now L2TP/IPSec worked like a charm.

I don't like the idea restarting ipsec every time you lose connection. Actually /usr/libexec/ipsec/_updown is ran on different actions in ipsec. The same script can be run on leftupdown/rightupdown. But the problem is that it doesn't perform any actual command when the remote client connects back to your host. To fix this issue you need add doroute replace after up-client) in /usr/libexec/ipsec/_updown.netkey (if you use Netkey of course):

# ...skipped...
#
up-client)
# connection to my client subnet coming up
# If you are doing a custom version, firewall commands go here.
    doroute replace
#
# ...skipped...

But be aware, this file will be overwritten, if you update your packages, so just put it somewhere else, and then add the following commands to your connection config:

rightupdown="/usr/local/libexec/ipsec/_updown"
leftupdown="/usr/local/libexec/ipsec/_updown"

Now the routes will be restored as soon as the remote connects back to your server.

Also to me, for strange reasons DPD not work properly in every situation. I use this script to check every minute the status. The scripts runs on the Peer (e.g. the Firewall):

C=$(ipsec auto --status | grep "established" | wc -l)
if [ $C -eq 0 ]
then
 echo "Tunnel is down... Restarting"
 ipsec restart
else
 echo "Tunnel is up...Bye!"
fi


this could happen because of iptables rules.
Be sure to have enabled the udp port 500 and the esp protocol towards the remote public ip address.

Example:

    iptables -A OUTPUT -p udp -d 1.2.3.4 --dport 500 -j ACCEPT
    iptables -A OUTPUT -p esp -d 1.2.3.4 -j ACCEPT

Bye

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top