From: Stephan Mending <list@md5collisions.eu>
To: development@lists.ipfire.org
Subject: Re: Incoming ESP Packets disappear
Date: Wed, 13 May 2020 15:13:25 +0200 [thread overview]
Message-ID: <20200513131325.GA68638@hellisempty.reich.home.arpa> (raw)
In-Reply-To: <DF9C2BC1-0F57-4B23-9810-17004E6CA60A@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
On Mon, May 04, 2020 at 04:03:13PM +0100, Michael Tremer wrote:
> Hi Stephan,
>
> What is the output of “ipsec statusall” on both systems?
>
> Best,
> -Michael
>
> > On 30 Apr 2020, at 22:28, Stephan Mending <list(a)md5collisions.eu> wrote:
> >
> > Hello,
> >
> > I have a situation. ;)
> >
> > It looks like the following:
> >
> >
> > (SRV-01) ----------- (IPFIRE) -------orange------- (SRV-02)
> >
> > public-IP 192.168.0.100
> >
> >
> > SRV-01 is hooked up to the ipfire via a roadwarrior IPsec connection. Establishment of the tunnel works as one would expect it.
> >
> > ping from SRV-02 to SRV-01 works fine and passes through the tunnel. So far, so good.
> >
> > ping from SRV-01 to SRV-02 does not.
> >
> >
> > Iptables is blocking ? No, I did check that. Nothing.
> >
> > IPS ? No, neither.
> >
> >
> > So what's the matter ? When watching the interface using tcpdump I can see ESP packets and afterwards its unencrypted icmp echo request content (both on ppp0). That is the end.
> >
> > And the packet has never been seen any after.
> >
> > Anyone an idea?
> >
> >
> > (Yes the SRV-02 accepts incoming icmp type 8 and outgoing type 0)
> >
> >
> > Best regards,
> >
> > Stephan
> >
> >
>
Hi Micheal,
thanks for your reply. I have done some changes to the setup. Just out of logical issues it had.
So the Situation changed but a Problem persists.
Maybe this "Problem" is intentionally that way. I'll explain.
One has to know: The machine (SRV-01) in the datacenter is running OpenBSD using iked(8) to connect to the strongswan
ipsec daemon.
That works for far pretty fine. DPD and rekeying is not a problem either.
But there seem to exist an issue on IPFire's site. Because from SRV-01 I cannot reach SRV-02 via icmp or tcp ...
So to make sure that this isn't an issue with the packet filter or routing table on SRV-01 I checked via tcpdump that
the packets I am sending to SRV-02 really reach the firewall. They do.
Though as soon as I have pinged or reached out once to SRV-01 from SRV-02. It works the other way around as well.
That's one thing. There are way to work around it. (-> They're ugly but they exist)
***
Next issue I was granted to be witness. After a few hours of the connection being established (And being restablished
due to rekeying etc) the strongswan just stops answering. Log on SRV-01 says: Retransmit 1 IKE_SA_INIT ...
And it keeps trying to retransmit 'til eternity (and is unsuccesful at it). So again. I check if those retransmits reach the ipfire box. And yes
they do. I can see the packets raining in on the ppp0 interface.
To resolve this issue I have to restart the connection from the ipfire webui (by clicking the restart button).
Options for the connection on ipfire are: DPD -> clear and Connection type: Wait for initiation.
I really hope you can help me here. I'd really appreciate it alot.
Thanks !
Best regards,
Stephan
prev parent reply other threads:[~2020-05-13 13:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <de3b625a-dae3-b5bb-96d3-cf084f911b85@md5collisions.eu>
2020-05-04 15:03 ` Michael Tremer
2020-05-13 13:13 ` Stephan Mending [this message]
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=20200513131325.GA68638@hellisempty.reich.home.arpa \
--to=list@md5collisions.eu \
--cc=development@lists.ipfire.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox