All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Dorau <daniel.dorau@alumni.tu-berlin.de>
To: netfilter@lists.netfilter.org
Subject: decrypted ipsec packets lost, last seen in INPUT chain
Date: Sat, 20 Nov 2004 14:52:21 +0100	[thread overview]
Message-ID: <1100958740.3687.11.camel@haktar> (raw)

Hello list,
I have a problem with decrypted ipsec packets lost. I'm not sure if this
is netfilter related, maybe someone has any idea.

I have a local interface with both 192.168.178.2 (unencrypted) and
192.168.202.5 assigned to it. Packets directed to the private network
are routed to local address 192.168.202.5 which is the local ipsec
tunnel endpoint.
Now if I ping a machine within the VPN, a ICMP echo request is sent
encrypted via 192.168.202.5 into the tunnel. An encrypted ICMP echo
reply is sent back, can be seen with ethereal and in netfilter's INPUT
chain. That echo reply is decrypted and can be seen again in ethereal
(now decrypted) as well as in the INPUT chain.

INPUT chain has policy ACCEPT and doesn't contain any rule except
logging every packet for debugging.

So, basically ipsec works as I get the echo reply decrypted to my INPUT
chain.
But then the packet is lost, ping itself never receives it (strace shows
-EAGAIN as result of recvmsg).
Same for TCP connections. I can see the SYN,ACK in the INPUT chain but
the application never gets it.

Does anybody has an idea where and/or why packets can get lost after
travelling through INPUT chain? (POLICY ACCEPT s.above)
IP adresses and packets itself as inspected within ethereal look
perfectly ok.

Any ideas? I'm completely lost. :-/

Thank you,
Daniel

-- 
Daniel Dorau




                 reply	other threads:[~2004-11-20 13:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1100958740.3687.11.camel@haktar \
    --to=daniel.dorau@alumni.tu-berlin.de \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.