1

There is an IPsec Tunnel created with OpenSwan that works perfectly well packets going through answers received etc until at some point in time traffic stops.

I can regenerate the tunnel doing

ipsec auto --down tunnelName
ipsec auto --up tunnelName

But eventually it will collapse again, sometimes after hours sometimes after days. I am not able to find any error messages for example in pluto.log that indicate that the tunnel collapsed, the last lines found are the ones reporting Quick_Mode entry.

Our side: Ubuntu 14.04.4 LTS, Linux Openswan U2.6.38/K3.13.0-91-generic (netkey)

Other side: SAP Router and unknown firewall

I tapped this using tcpdump while the tunnel was not doing its job:

10:30:53.357186 IP us.isakmp > them.isakmp: isakmp: phase 1 I ident
10:30:53.384168 IP them.isakmp > us.isakmp: isakmp: phase 1 R ident
10:30:53.384880 IP us.isakmp > them.isakmp: isakmp: phase 1 I ident
10:30:53.425034 IP them.isakmp > us.isakmp: isakmp: phase 1 R ident
10:30:53.425770 IP us.isakmp > them.isakmp: isakmp: phase 1 I ident[E]
10:30:53.451727 IP them.isakmp > us.isakmp: isakmp: phase 1 R ident[E]

10:32:01.089957 IP us > them: ESP(spi=0x6e51327d,seq=0x14b), length 100
10:32:02.089097 IP us > them: ESP(spi=0x6e51327d,seq=0x14c), length 100

First part seems to be a succesful tunnel rekey negotiation second part two failing requests, or not?

Netstat says that requests sent into the tunnel reach nothing more than SYN_SENT and then time out.

Are there any other logs I could search as I am not allowed to debug the other end of the tunnel?

Improve this question
6
  • Please update the post telling us the OS and versions in both points if possible and the version of openswan.
    – Rui F Ribeiro
    Commented Jul 4, 2016 at 13:49
  • Of course. Sorry I forgot. Stage fright :-)
    – Björn
    Commented Jul 4, 2016 at 14:15
  • Do you have any ideia how long it takes to collapse? Could it be due to timeouts of inactivity on the firewall on their side after a fixed allotted time? Could it be some parameter that is missing in the ipsec config? have a look at /var/syslog too. (I am using strongswan here with charon)
    – Rui F Ribeiro
    Commented Jul 4, 2016 at 15:20
  • As I updated above the time the tunnel takes to collapse is highly variable. I will have a look at syslog. To be honest I simply hope I can find some evidence so I can force the owner of the other side to do their job :-/
    – Björn
    Commented Jul 5, 2016 at 9:41
  • Of course I am not allowed to ping :-( However I will try to create some kind of keep-alive. Could you post this idea as an answer so that I can acknowledge your efforts?
    – Björn
    Commented Jul 5, 2016 at 10:18

1 Answer 1

Reset to default
0

Have a look at /var/log/syslog, usually there is a trove of logs to be found there relating to ipsec.

There used to be a (very) old bug talking with Windows on the other side due to inactivity...a simple ping in the background fixed that, or a patch); cannot remember the specifics though.

Nevertheless, most firewalls have a default timeout rule where if the connection is inactive more than a certain time they will tear down the connection. However, it is supposed to be negotiated again, except if some parameter is off, or due to some odd compatibility problem.

Improve this answer
3
  • I was just wanting to accept the answer, when the tunnel came tumbling down again. I will take another tour of syslog as you suggested. The good thing is that the I know now far better when the tunnel ceased to operate -.-
    – Björn
    Commented Jul 6, 2016 at 7:52
  • Collect some and send to the other team. It might be interesting to cross reference time logs (or not). Back in here, I have a central syslog collector with logs over a year to peruse when debugging a problem.
    – Rui F Ribeiro
    Commented Jul 6, 2016 at 7:54
  • 1
    The human solution :-) The keep alive requests annoyed the IT on the other side so much, that they fixed the problem. I will post the solution here if I can get them to tell me.
    – Björn
    Commented Jul 13, 2016 at 8:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .